Skip to main content
Version: Latest

Trust & Identity

PBAC doesn't store passwords or manage user accounts. It federates with your existing identity providers and lets policy decide who to trust, how to route authentication, and what identity context flows into every access decision.

Trust & Identity is about establishing who — who is the user, which IdP vouches for them, and whether that IdP is trusted for the requested resource. These decisions happen before any token is issued.

Identity Providers​

An Identity Provider (IdP) is any OpenID Connect issuer that PBAC federates with — Entra ID, Okta, Keycloak, or any OIDC-compliant system. PBAC does not replace your IdP. It sits between your IdPs and your applications, adding a policy layer to the authentication flow.

Each IdP registration includes:

FieldPurpose
provider_keyUnique identifier used in policy rules (e.g., entra-prod)
issuerOIDC issuer URL
client_id / client_secretCredentials PBAC uses to authenticate with the IdP
scopesWhat PBAC requests from the IdP (e.g., openid profile email)
OIDC endpointsAuthorization, token, userinfo, JWKS URLs

When a user-interactive flow begins (/authorize), OPA selects which IdP to redirect to. This selection is driven by policy data — not hardcoded. Different resources can require different IdPs. A healthcare record might require a clinical IdP with MFA, while an internal dashboard accepts a corporate SSO.

Subjects​

A subject is a user as known to PBAC — identified by the combination of a subject_id (the sub claim from the IdP) and the identity provider they authenticated with. The same human authenticating through two different IdPs produces two distinct subjects.

Subjects are created when a user first authenticates through PBAC. They carry no permissions directly — what a subject can access is determined by policy at evaluation time, not by attributes stored on the subject record.

Subjects can own resources. When a resource has an ownerSubject, OPA can evaluate owner-based access rules — for example, allowing a patient to share their own health record with a specific provider.

Workload Identity (SPIFFE)​

For machine-to-machine scenarios, PBAC supports SPIFFE workload identity. Instead of pre-registering clients with shared secrets, agent workloads present JWT-SVIDs — short-lived, cryptographically signed identity documents issued by SPIRE.

SPIFFE IDs follow a structured format: spiffe://trust-domain/path. PBAC uses the trust domain for validation and the path for policy-driven resource grants. A vulnerability scanner at spiffe://corp.example.com/agent/vuln-scanner gets different access than a data exporter at spiffe://corp.example.com/agent/data-export — determined by OPA policy, not by the agent's self-declared claims.

Trust configuration​

Three policy data keys control the trust boundary:

Trusted issuers​

The trust.trusted_issuers data key lists which JWT issuers PBAC accepts for software statement verification. When a client registers via DCR with a signed software statement, the AS checks that the statement's issuer is in this list before forwarding it to OPA.

This is the foundation of federated trust: if you trust an issuer, you trust the software statements they sign — and OPA decides what permissions those statements grant.

IdP routing​

The user.idp_selection data key controls which IdP is selected for authorization flows. Routing can be based on the requested resource type, specific resource server, or ACR value. OPA evaluates this data to select the appropriate IdP for each authorization request.

Denylists​

The denylists data key blocks specific clients or subjects from accessing the system, regardless of what their software statement or IdP claims would otherwise allow. Denylists are checked early in policy evaluation — a denied client cannot obtain any token, and a denied subject cannot authenticate through any flow.

How identity flows into decisions​

At every OPA evaluation, the identity context is available as part of input:

{
  "input": {
    "subject": {
      "sub": "user-123",
      "idp": "entra-prod",
      "acr": "urn:mace:incommon:iap:silver",
      "claims": {
        "email": "user@example.com",
        "roles": ["clinician"]
      }
    },
    "context": {
      "client": {
        "client_id": "emr-app",
        "software_statement": { "..." }
      }
    }
  }
}

Policy rules can use any of this: the subject's IdP, their ACR level, specific claims, or the combination of subject + client + resource. The trust configuration (denylists, IdP routing, trusted issuers) shapes which identity context reaches OPA. The policy rules decide what to do with it.

Next steps​