Multi-Tenant Access Control

Overview#

Operating an intelligence platform across multiple organisations simultaneously introduces a fundamental challenge: every analyst, administrator, and automated process must see exactly the data their organisation owns and nothing more, while the platform itself must remain operationally coherent across tenants. When a classified resource carries a secrecy designation, only users whose clearance meets that designation may access it regardless of which organisation they belong to. These two requirements together define multi-tenant attribute-based access control, and getting either wrong is a security incident.

Argus enforces multi-tenant isolation using OASIS XACML 3.0 (eXtensible Access Control Markup Language), an open standard for attribute-based access control published by OASIS Open. Every access request is evaluated against a policy set that checks organisation identity, secrecy clearance, and role scope before a database query is ever issued. Enforcement at the data layer is delegated to PostgreSQL Row Level Security, an open-source capability built into PostgreSQL that silently filters rows for any session that does not hold the matching organisation identifier. No proprietary security gateway product is used.

Last Reviewed: 2026-04-14 Last Updated: 2026-04-14

Key Features#

• OASIS XACML 3.0 Policy Declarations: Access control rules are declared as XACML 3.0 policies with explicit subject, resource, and action attribute matching. Each policy carries an obligation element that fires an audit log entry on every permit or deny decision. The policy set uses the XACML deny-overrides combining algorithm: any DENY result overrides all PERMIT results, so a cross-tenant request is rejected even if another policy would otherwise grant it.

• Organisation Isolation Policy: The primary tenant boundary enforces that the subject's organisation identifier must exactly match the resource's organisation identifier. If either attribute is absent, access is denied by default (fail-closed). This policy is simultaneously enforced at the application layer by the XACML PDP and at the database layer by a PostgreSQL RLS policy that filters rows using the app.organization_id session parameter set from the authenticated JWT claim.

• Secrecy Level Policy: Resources carry an integer secrecy level on the NATO/EDF classification scale (0 = UNCLASSIFIED through 4 = TOP_SECRET). A subject's clearance level, also derived from their JWT claim, must meet or exceed the resource's secrecy level. If it does not, the DENY policy fires before any database query is issued. This provides pre-query enforcement that does not rely on the caller correctly filtering classified rows.

• Tenant Admin Scope Policy: Administrative operations are PERMIT-gated to the subject's own organisation. An administrator with admin:full-access permission can manage their own tenant's users, settings, and resources, but cannot target resources owned by another organisation. There is no global admin bypass for tenant-level administrators; only the platform-level SUPERUSER role carries cross-tenant access, and every SUPERUSER access fires a mandatory audit obligation.

• PostgreSQL Row Level Security Enforcement: All tenant-scoped tables have RLS enabled and forced. The session parameter app.organization_id is set from the JWT claim at connection time by the database client. RLS policies silently filter rows, meaning a misconfigured query that omits the organisation filter receives empty results rather than cross-tenant data. The RLS policies are documented alongside their corresponding XACML declarations.

• Audit Trail on Every Decision: Every XACML policy decision fires an obligation that logs the access decision to the immutable audit trail with user ID, organisation ID, action, resource identifier, secrecy level, and timestamp. This satisfies EDF and PESCO interoperability requirements for classified data handling.

Use Cases#

Multi-Tenant Access Control is used across defence and security agencies, law enforcement, and critical national infrastructure sectors.

• Multi-National Coalition Operations: Analysts from different national organisations work on the same platform instance without any risk of one nation's intelligence being visible to another. Organisation isolation is enforced at the policy and data layers independently.
• Classified Resource Protection: Documents, profiles, and case records marked at SECRET or above are only returned to analysts whose JWT clearance claim meets the classification level. A CONFIDENTIAL-cleared analyst querying the same endpoint receives a filtered result set.
• Tenant Admin Delegation: Organisation administrators can manage their own users and settings without the platform needing to grant them cross-tenant privileges. Administrative endpoints verify tenant ownership before executing any operation.
• Audit-Ready Compliance: Every data access event is recorded with the decision reason, enabling retrospective review of who accessed what classified data and under which policy authorisation.

Integration#

• Authentication Service: JWT claims supply the subject attributes (organisation ID, clearance level, role) consumed by the XACML PDP.
• PostgreSQL Client: Sets the app.organization_id and app.clearance_level session parameters from the validated JWT at connection acquisition time.
• GraphQL Resolvers: Every resolver uses permission_classes or require_permission enforcement backed by the XACML policy evaluation before delegating to the repository layer.
• Audit Service: Receives obligation-fired audit events from the XACML PDP and writes them to the immutable audit trail table.
• COI (Community of Interest): Cross-organisation data sharing for federated operations is handled exclusively through explicit COI membership, not by relaxing organisation isolation.

Open Standards#

All access control is achieved through OASIS XACML 3.0 declarations, open-source PostgreSQL RLS, and standard JWT claims.