fix(keycloak): grant admin realm role to adm user#50
Open
abir-oumghar wants to merge 1 commit into
Open
Conversation
Closes #45. The 'adm' user authenticates OKDP services via OIDC but could not access the Keycloak admin console because that requires the master realm's native 'admin' role. Granting it to 'adm' lets a single account drive both the user-facing services and Keycloak administration.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #45.
The
admuser (defined inclusters/sandbox/default-context.yaml) is the OIDC admin used to log into OKDP UI, Airflow, JupyterHub, Superset, and the other user-facing services. It only carried the customadminsrealm role, so it could not log into the Keycloak admin console — that one requires the master realm's nativeadminrole. The bootstrap superuseradmin/adminwas the only way in, which conflicted with theadmOIDC session and produced the auth/session loop described in the issue.Adding the native
adminrole toadmlets a single account drive both the user-facing services and Keycloak administration. The change is purely additive: existing services that map roles do so on theadminsgroup (Superset'sAUTH_ROLES_MAPPING, JupyterHub'sadmin_groups, etc.), not on the nativeadminrole, so nothing else is affected.Verified locally on the kind sandbox by granting the role via
kcadm.shand logging into both the Keycloak admin console and OKDP UI asadm/admwithout any session conflict.