Identity Providers (EntraID, Okta, Keycloak)

Blackridge consumes the identity you already have. Any OIDC-compliant IdP works — the gateway validates tokens against your IdP's published keys (JWKS via the standard well-known endpoint) and turns claims into graded, per-request attribution. There is no Blackridge user directory to maintain.

Two integration points use the IdP:

1. Request attribution (who/what owns each model call) — gateway-side, this page.
2. Viewer access to reports and role-based views — investigation API-side, below.

Request attribution via IdP tokens

Use IdP tokens when the caller already has validated enterprise identity at the application, proxy, or service boundary. Blackridge turns those claims into per-request attribution with evidence provenance, so ownership can be resolved without changing every model call site.

Per-IdP claim notes

EntraID, Okta, and Keycloak all work through standard OIDC claims, but each organization chooses different claim names for teams, groups, roles, and applications. Customer docs include the provider-specific mapping notes and common gotchas.

No token at the app layer? Use your proxy

If the application does not hold a user token when it calls a model, use the identity your ingress, auth proxy, or service mesh already validated. The important boundary is trust: proxy-supplied identity must come from infrastructure you control.

Viewer access and roles

The investigation UI has role-oriented views (Engineer, FinOps, and more). In production these should be assigned by the IdP, not chosen by the user:

• The investigation API validates the viewer's bearer token against the same issuer/audience configuration.
• IdP groups/roles map to Blackridge personas via configuration (e.g. brg-finops → finops, brg-engineering → engineer).
• The UI hides the persona toggle when the server supplies a role, and shows a "signed in as" badge instead.

Persona is presentation. Authorization is enforced in the API — tenant scoping and export rights derive from validated claims, never from what the browser asks for.

What Vault is (and isn't) here

HashiCorp Vault is not a human-login IdP for the viewer. Where it fits: holding the gateway's OIDC client secrets and signing keys, and machine identity for service-to-service calls. Point Vault's OIDC auth at your IdP; point Blackridge at the same IdP directly.