Skip to content

PATTERN Cited by 1 source

IdP-group-mapped authorization

Intent

Eliminate per-system user lifecycle management (create-user, edit- ACL, remove-user) by making the Identity Provider the single source of truth for group membership and teaching each downstream system to consume IdP group claims as its authorization input. The downstream system stores only group → permission rules; user membership is dynamic and inherited from IdP tokens.

Canonical framing

From the Redpanda 26.1 launch post:

"With 26.1, we're introducing Group-Based Access Control (GBAC). Instead of micromanaging permissions for every single 'Bob' and 'Alice' in your organization in each cluster, you can now map roles or permissions to groups provided centrally by an Identity Provider (IdP). Access control that automatically absorbs your organization's changes delivers a 'set it and forget it' model for authorization that finally brings sanity to enterprise-scale streaming security."

See concepts/group-based-access-control for the underlying authorization model.

Mechanism

                      ┌───────────────────┐
                      │  Identity         │
                      │  Provider         │  (Okta / AzureAD /
                      │                   │   Google Workspace)
                      └──────┬────────────┘
                             │
                             │  Token with group claims:
                             │  { sub: "alice",
                             │    groups: ["payments-team",
                             │              "engineering"] }
                             ▼
                      ┌───────────────────┐
                      │  Streaming        │
                      │  cluster /        │
                      │  service fleet    │
                      │                   │
                      │  Policy:          │
                      │  payments-team    │
                      │     → READ orders │
                      │  engineering      │
                      │     → READ *      │
                      └───────────────────┘
  1. IdP issues token with group claims embedded.
  2. Client presents token to the downstream system.
  3. System validates token, extracts group claims.
  4. System evaluates policy: group(s) → permission(s).
  5. Request allowed / denied based on the policy lookup.

Scaling properties

  • Onboarding: add user to an IdP group once → access propagates to every system that trusts the IdP on next token refresh.
  • Offboarding: remove user from IdP group once → access evaporates on next token refresh. No per-system sweep.
  • Team-change: move user between IdP groups once → access re-shapes across all systems.
  • Policy maintenance: N groups × M systems rules, independent of user count. Typical enterprise: ~50 groups × ~20 systems = 1000 rules, vs ~10000 users × 20 systems = 200000 per-user ACLs.

Offboarding posture

The offboarding argument is the load-bearing security benefit. Terminated employees who retain system-local accounts are a common audit finding. With IdP-group-mapped authorization:

  • Revoke the IdP group membership at HR offboarding.
  • Next token refresh (typically minutes to hours) removes access globally.
  • System-local audit still shows the token-bound access for audit trail, but subsequent requests fail.

No "walk every system and remove alice's ACL" task.

When to use

  • Organisation already runs an IdP (Okta, Azure AD, Google Workspace, PingFederate). If the IdP doesn't exist, the pattern is premature — build the IdP first.
  • N systems × M users problem is expensive — multi-cluster streaming, multi-service API gateways, multi-tool SaaS fleet.
  • Audit requirements demand centralised offboarding — regulated environments, compliance-gated SaaS, M&A-heavy portfolios where employee churn is high.

When to avoid

  • Single-system deployments — the pattern's benefit is amortised across many systems; one-off clusters may not justify the IdP integration.
  • Systems that can't consume IdP tokens — legacy systems with hardcoded user-store expectations; would need an adapter layer.
  • Ultra-low-latency paths that can't afford IdP round-trips — but this is typically solvable by caching short-lived tokens locally.

Trade-offs

  • IdP availability becomes the authz availability ceiling — if the IdP is down, new token minting stops. Mitigate with token caching + fail-closed on stale-beyond-threshold.
  • IdP group explosion — teams sometimes end up creating many niche groups (payments-team-on-call-weekdays). The IdP's group model should be kept shallow and role-shaped, not permission-shaped.
  • Fine-grained access — IdP groups are coarser-grained than per-resource ACLs. Some systems still need per-resource overrides on top of group defaults.

Canonical instance

Redpanda GBAC (26.1) — Redpanda's first-party implementation of this pattern on a streaming broker. Groups from the customer's IdP map to roles / permissions in the Redpanda cluster. Documented at docs.redpanda.com/current/manage/security/authorization/gbac/.

Sibling patterns

Seen in

Source

Last updated · 550 distilled / 1,221 read