OIDC claim-to-group/role mapping #81

New Issue

claude · 2026-03-17T19:14:24+01:00

claude commented

2026-03-17 19:14:24 +01:00

Context

OIDC users are auto-registered with provider = "oidc:<issuer>" and assigned the VIEWER role by default (OidcAuthController). There is no automatic mapping from OIDC claims (e.g., groups, roles, realm_access) to Cameleer groups or roles.

Admins must manually assign groups/roles to each OIDC user after their first login.

Requirements

Claim mapping configuration

Extend oidc_config table (or new oidc_claim_mappings table) to store mapping rules
Admin API endpoints to configure mappings:
- POST /api/v1/admin/oidc/mappings — create a mapping rule
- GET /api/v1/admin/oidc/mappings — list mapping rules
- DELETE /api/v1/admin/oidc/mappings/{id} — delete a mapping rule

Mapping rule structure

{
  "claimPath": "groups",
  "claimValue": "engineering",
  "targetType": "group",
  "targetId": "<cameleer-group-uuid>"
}

Behavior

On OIDC login/token-exchange, after user upsert, evaluate all mapping rules against the ID token claims
If a claim matches, assign the user to the target group/role
Mappings are additive (don't remove existing assignments)
Consider: should mappings be re-evaluated on every login (sync) or only on first registration?

UI

Mapping configuration section in OIDC admin page
Show claim path, value, and target group/role with add/remove controls

Notes

Common claim paths: groups (Azure AD/Entra), realm_access.roles (Keycloak), cognito:groups (AWS)
This enables zero-touch onboarding for OIDC users

## Context OIDC users are auto-registered with `provider = "oidc:<issuer>"` and assigned the VIEWER role by default (`OidcAuthController`). There is no automatic mapping from OIDC claims (e.g., `groups`, `roles`, `realm_access`) to Cameleer groups or roles. Admins must manually assign groups/roles to each OIDC user after their first login. ## Requirements ### Claim mapping configuration - Extend `oidc_config` table (or new `oidc_claim_mappings` table) to store mapping rules - Admin API endpoints to configure mappings: - `POST /api/v1/admin/oidc/mappings` — create a mapping rule - `GET /api/v1/admin/oidc/mappings` — list mapping rules - `DELETE /api/v1/admin/oidc/mappings/{id}` — delete a mapping rule ### Mapping rule structure ```json { "claimPath": "groups", "claimValue": "engineering", "targetType": "group", "targetId": "<cameleer-group-uuid>" } ``` ### Behavior - On OIDC login/token-exchange, after user upsert, evaluate all mapping rules against the ID token claims - If a claim matches, assign the user to the target group/role - Mappings are additive (don't remove existing assignments) - Consider: should mappings be re-evaluated on every login (sync) or only on first registration? ### UI - Mapping configuration section in OIDC admin page - Show claim path, value, and target group/role with add/remove controls ## Notes - Common claim paths: `groups` (Azure AD/Entra), `realm_access.roles` (Keycloak), `cognito:groups` (AWS) - This enables zero-touch onboarding for OIDC users

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: cameleer/cameleer-server#81