π Bug Summary
Generic OIDC providers (Authentik in my case) cannot promote users to platform admin via SSO group mapping. The Keycloak and Entra paths work because they have dedicated bootstrap and admin-check wiring β the generic path is missing equivalent support in three places along the same code flow.
Tested on v1.0.0-RC-3 (a02a04b) with Authentik as the IdP. Groups are correctly emitted by the IdP and correctly extracted by the gateway (the RC3 fix in #3597/#3719 works). The problem is what happens after extraction.
π§© Affected Component
π Steps to Reproduce
- Configure Generic OIDC (
SSO_GENERIC_ENABLED=true, SSO_GENERIC_PROVIDER_ID=authentik, standard endpoints).
- IdP emits
groups: ["cf-platform-admin"] in the token.
- Log in via SSO.
- Result: user lands with
platform_viewer + team_admin on personal team. No platform_admin. Admin UI sections don't work.
Expected Behavior
A user whose IdP group maps to platform_admin via role_mappings should get full admin access β same as Keycloak/Entra users do today.
π What breaks (single code flow, three gaps)
1. Bootstrap: provider_metadata is always {}
sso_bootstrap.py lines 290-312 β the generic OIDC block never sets provider_metadata. Keycloak (lines 268-282) and Entra (lines 228-234) both populate groups_claim, role_mappings, default_role. Generic writes {}, so _map_groups_to_roles() exits early with "No role mappings configured" even when the IdP sends the right groups.
2. Admin flag: _should_user_be_admin has no generic path
sso_service.py lines 2093-2132 β checks GitHub orgs, Google domains, Entra admin groups, but nothing for generic providers. Always returns False for Authentik. Even after manually fixing gap 1 so that platform_admin is correctly assigned in user_roles, the legacy is_admin flag on email_users stays false.
3. UI: admin rendering gates on legacy is_admin, not RBAC role
admin.py lines 2830, 3544, 3571 β the UI reads is_admin from the user/session, not from user_roles. A user with platform_admin RBAC role but is_admin = false sees the admin sidebar but clicking anything (Users, Maintenance, System Config) just shows the Overview page.
π§ Environment Info
| Key |
Value |
| Version or commit |
v1.0.0-RC-3 (a02a04b) |
| Runtime |
Docker (ghcr.io/ibm/mcp-context-forge:latest) |
| Platform / OS |
macOS (Docker Desktop) |
| Container |
Docker Compose |
π§© Additional Context
Suggested fix direction:
- Add
SSO_GENERIC_GROUPS_CLAIM, SSO_GENERIC_ROLE_MAPPINGS (JSON), SSO_GENERIC_DEFAULT_ROLE env vars and wire them into provider_metadata during bootstrap (parity with Keycloak/Entra).
- In
_should_user_be_admin, after the provider-specific checks, consult provider_metadata.role_mappings β if any of the user's groups maps to platform_admin, return True. Or sync is_admin after _map_groups_to_roles when platform_admin is in the result.
Current workaround (two manual DB statements after each fresh deployment):
UPDATE sso_providers SET provider_metadata = '{"groups_claim":"groups","default_role":"platform_viewer","role_mappings":{"cf-platform-admin":"platform_admin"}}' WHERE id = 'authentik';
UPDATE email_users SET is_admin = true, admin_origin = 'manual' WHERE email = 'user@example.com';
π Bug Summary
Generic OIDC providers (Authentik in my case) cannot promote users to platform admin via SSO group mapping. The Keycloak and Entra paths work because they have dedicated bootstrap and admin-check wiring β the generic path is missing equivalent support in three places along the same code flow.
Tested on v1.0.0-RC-3 (a02a04b) with Authentik as the IdP. Groups are correctly emitted by the IdP and correctly extracted by the gateway (the RC3 fix in #3597/#3719 works). The problem is what happens after extraction.
π§© Affected Component
mcpgateway- APImcpgateway- UI (admin panel)π Steps to Reproduce
SSO_GENERIC_ENABLED=true,SSO_GENERIC_PROVIDER_ID=authentik, standard endpoints).groups: ["cf-platform-admin"]in the token.platform_viewer+team_adminon personal team. Noplatform_admin. Admin UI sections don't work.Expected Behavior
A user whose IdP group maps to
platform_adminviarole_mappingsshould get full admin access β same as Keycloak/Entra users do today.π What breaks (single code flow, three gaps)
1. Bootstrap:
provider_metadatais always{}sso_bootstrap.pylines 290-312 β the generic OIDC block never setsprovider_metadata. Keycloak (lines 268-282) and Entra (lines 228-234) both populategroups_claim,role_mappings,default_role. Generic writes{}, so_map_groups_to_roles()exits early with "No role mappings configured" even when the IdP sends the right groups.2. Admin flag:
_should_user_be_adminhas no generic pathsso_service.pylines 2093-2132 β checks GitHub orgs, Google domains, Entra admin groups, but nothing for generic providers. Always returnsFalsefor Authentik. Even after manually fixing gap 1 so thatplatform_adminis correctly assigned inuser_roles, the legacyis_adminflag onemail_usersstaysfalse.3. UI: admin rendering gates on legacy
is_admin, not RBAC roleadmin.pylines 2830, 3544, 3571 β the UI readsis_adminfrom the user/session, not fromuser_roles. A user withplatform_adminRBAC role butis_admin = falsesees the admin sidebar but clicking anything (Users, Maintenance, System Config) just shows the Overview page.π§ Environment Info
π§© Additional Context
Suggested fix direction:
SSO_GENERIC_GROUPS_CLAIM,SSO_GENERIC_ROLE_MAPPINGS(JSON),SSO_GENERIC_DEFAULT_ROLEenv vars and wire them intoprovider_metadataduring bootstrap (parity with Keycloak/Entra)._should_user_be_admin, after the provider-specific checks, consultprovider_metadata.role_mappingsβ if any of the user's groups maps toplatform_admin, returnTrue. Or syncis_adminafter_map_groups_to_roleswhenplatform_adminis in the result.Current workaround (two manual DB statements after each fresh deployment):