Multi-Tenant Access Control

Overview#

Multi-tenant attribute-based access control that keeps every organisation's data isolated on a shared platform, enforcing organisation identity, secrecy clearance, and role scope independently at the policy layer and the database layer.

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 row-level security inside the relational database itself, which silently filters rows for any session that does not hold the matching organisation identifier. No proprietary security gateway product is used. This enforcement now operates as a layered model: a platform-wide deny-by-default guard inspects every API request for foreign organisation identifiers before any handler runs, explicit permission gates authorise the operation itself, and database-level row isolation filters what can ever be returned, with the service proving at start-up that database enforcement is active and refusing to serve if that proof fails.

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 row-level security policy that filters rows using an organisation identifier bound to the database session from the authenticated JWT claim.

• Secrecy Level Policy: Resources carry an integer secrecy level on a five-level 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 holding full administrative permission for their own tenant can manage that 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.

• Database Row-Level Security Enforcement: All tenant-scoped tables have row-level security enabled and forced. The organisation identifier is bound to the database session from the JWT claim at connection time. These policies silently filter rows, meaning a misconfigured query that omits the organisation filter receives empty results rather than cross-tenant data. The row-level 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 supports interoperability and oversight requirements for classified data handling.

• Deny-by-Default Object-Level Authorisation: A central enforcement layer runs on every API request, scanning arguments, including nested inputs and lists, for organisation and tenant identifiers. Any identifier outside the caller's server-derived access set is denied fail-closed and audited with who attempted it, what operation, and which identifiers were tried. This closes the classic change-the-identifier-in-the-request attack class across the whole API at once rather than endpoint by endpoint. Cross-tenant access requires server-verified privileged roles with a recorded justification, a reviewed allowlist covers the intentionally public citizen-facing municipal surface, and a release gate prevents new API surfaces from regressing the protection.

• Boot-Time Isolation Verification: Tenant context is bound to the same database connection and transaction as each statement, so pooled connections can never leak a stale organisation scope between requests, and a no-tenant state can never carry over. Row-level isolation is enrolled on all multi-tenant tables, including sharing ledgers, incident shares, and voice configuration, with an automatic backstop that stamps tenant context on every transaction and an optional strict mode that rejects tenant-less writes outright. At start-up the service probes that the runtime database role cannot bypass row security and, in required-enforcement mode, refuses to serve if the probe fails.

• Server-Side Tenant Derivation Everywhere: Every query, mutation, statistic, scheduled job, and edge service derives the owning organisation from the caller's verified identity, never from anything the client sends. Principals without a verifiable organisation are rejected outright rather than mapped to a shared context, background jobs filter their work by tenant so no organisation's automation ever runs against another's data, and edge services bind their data scope to verified service token claims rather than client-supplied headers.

• Uniform Permission Gates with Separation of Duties: Every root-level API operation is gated by an explicit permission check and fails closed when no authenticated user is present, so a newly added API surface cannot ship without authorisation. Sensitive investigation access grants enforce separation of duties: the person granting access cannot be its beneficiary. Administrative full access within a tenant is verified never to equal platform-wide administration, and superuser accounts do not bypass row-level read protections on scientific reference data.

• Tenant-Scoped Realtime, Caching, and Offline Data: Client-side stores obey the same boundary. Live subscriptions, including defence sensor, telemetry, and command-centre feeds, stay inactive until the tenant is known from the verified session; tenant filtering on data queries is default-deny, so newly added operations inherit scoping automatically; cached operational pictures are keyed per tenant and per user, with caching skipped entirely when the signed-in principal cannot be resolved; and mobile offline snapshots refuse to fall back to a shared bucket when the tenant is unknown.

• Continuous Adversarial Review: A sustained internal security review programme exercises the case, evidence, intelligence, export, collaboration, and dispatch surfaces and closes authorisation, validation, and abuse-resistance gaps fail-closed. Recent outcomes include consistent case-level access checks on consent records, hearings, and destruction orders, minimised directory listings for non-administrators, rate limiting applied before authorisation work on recording and realtime endpoints, stricter identifier validation at the API boundary, and bounded resource usage on expensive export operations.

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. Auditors can additionally point to database-enforced isolation with a start-up proof, rather than relying on application code review alone.
• Shared National Infrastructure: Many agencies operate safely on the same deployment because tenant separation is enforced at the API, scheduled-job, and edge-service layers, not just in the user interface, and even aggregate statistics derive their scope from the verified caller.
• Four-Eyes Access Grants: Separation of duties on sensitive investigation access grants means the person authorising access can never be its beneficiary, supporting four-eyes principles on the most sensitive material.

Integration#

• Authentication Service: JWT claims supply the subject attributes (organisation ID, clearance level, role) consumed by the XACML PDP.
• Database Client: Binds the organisation identifier and clearance level from the validated JWT to the database session at connection acquisition time.
• API Layer: Every workflow handler carries an explicit permission requirement backed by the XACML policy evaluation before delegating to the data access 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. Sharing paths require a verified active agreement and fail closed when the check cannot complete.
• Edge Services: Dispatch, retrieval-augmented search, SIEM query and archive, tactical sync, and state coordination services bind their data scope to the verified service token claim rather than to client-supplied headers.
• Realtime and Offline Clients: Browser and mobile clients resolve their tenant from the verified session before opening live subscriptions, populating caches, or writing offline snapshots, and backend relays authenticate callers before trusting any relayed tenant identity, rejecting mismatched tenant claims.

Open Standards#

All access control is achieved through OASIS XACML 3.0 declarations, database-enforced row-level security, and standard JWT claims.

Last Reviewed: 2026-07-16 Last Updated: 2026-07-16