I want to use a service account token to call the admin API (for it's realm) and have discovered that the token needs the "resource_access" claim (with appropriate "realm-management" roles). I don't want user tokens generated through the client to have the claim (unless absolutely necessary). How can I get mappers to only apply to the service account token? Or find the mappers used for the service account tokens? If I add the client roles mapper to the client I still don't get the "resource_access" claim in the service account token. (Keycloak 4.8.2) Cheers, Gary _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

On 7 May 2019, at 9:38 am, Gary Kennedy <gary(a)apnic.net&gt; wrote: > > On 3 May 2019, at 8:38 am, Dmitry Telegin <demetrio(a)carretti.pro <mailto:demetrio@carretti.pro>> wrote: > > Hi Gary, > > To ensure proper "resource_access" claim, you can simply assign the necessary roles to your service account (client -> Service Account Roles -> Client Roles -> realm-management). Does that work for you? Unfortunately no. The roles are set, however they are not presented in the token, eg no "resource_access" claim. And because of the missing "resource_access" claim, using the token with the admin API results in 403 forbidden. > If you still need to use mappers, there are numerous ways to determine if the token was issued for a service account. For example, in your JS mapper you could look for "preferred_username" claim, its value will look like "service-account-<your-client>". Thanks. I previously explicitly tried the built-in "client roles" mapper for the client as well as creating a "user client role" mapper manually (not at the same time) and they were not adding the claim to the token so I assumed wrongly that the client mappers were not being used for the service account token. Using a script mapper (and a hardcoded claim mapper) works in that the service account token has the configured claims from those mappers. It seems like the "user client roles" mapper type is being filtered from the applied protocol mappers here. The mapper is applied to user tokens as well (of course) but at least using a script mapper will allow me to hack in the "resource_access" claim as I want. I'd like to do the right thing and have the script mapper use actual roles but I may have to fall back to hardcoding the claim value, we'll see how much effort is needed and that I'm allowed to put in :p. > Cheers, > Dmitry > > On Thu, 2019-05-02 at 06:18 +0000, Gary Kennedy wrote: >> I want to use a service account token to call the admin API (for it's realm) and have discovered that the token needs the "resource_access" claim (with appropriate "realm-management" roles). >> >> I don't want user tokens generated through the client to have the claim (unless absolutely necessary). >> >> How can I get mappers to only apply to the service account token? Or find the mappers used for the service account tokens? >> >> If I add the client roles mapper to the client I still don't get the "resource_access" claim in the service account token. >> >> (Keycloak 4.8.2) >> >> Cheers, >> Gary >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>

On 9 May 2019, at 7:01 am, Dmitry Telegin <demetrio(a)carretti.pro&gt; wrote: Hi Gary, I'm still convinced this could be done much simpler. Just performed a quick test: - created a realm; - created an OIDC client of type "confidential"; - enabled service account; - went to Service Account Roles and assigned realm-management.manage-realm role; Then ran a script: #!/bin/sh KEYCLOAK_URL=http://localhost:8080/auth KEYCLOAK_REALM=test-realm KEYCLOAK_CLIENT=test-client KEYCLOAK_CLIENT_SECRET=... ACCESS_TOKEN=$(curl -s $KEYCLOAK_URL/realms/$KEYCLOAK_REALM/protocol/openid-connect/token \ --basic --user $KEYCLOAK_CLIENT:$KEYCLOAK_CLIENT_SECRET \ -d grant_type=client_credentials \ | jq -r '.access_token') echo $ACCESS_TOKEN | sed 's/\(.*\)\.\(.*\)\.\(.*\)/\2/' | base64 -d | jq I've been able to see the following inside the token: "realm_access": { "roles": [ "offline_access", "uma_authorization" ] }, "resource_access": { "realm-management": { "roles": [ "manage-realm" // <- this ] }, "account": { "roles": [ "manage-account", "manage-account-links", "view-profile" ] } }, (How it works: by default, built-in client scopes are assigned to the clients (see Client Scopes tab -> Assigned Default Client Scopes). One of them, namely "roles", invokes the "client roles" mapper, which in its turn resolves the roles and puts them into a token.) Could you please try to reproduce the same on your instance? Hope that helps, Dmitry Telegin Opensource IAM consultant https://www.linkedin.com/in/d-telegin On Tue, 2019-05-07 at 03:40 +0000, Gary Kennedy wrote: > I think I've found an acceptable solution, can I get some feedback please? I don't want to risk any loopholes or lessened security here. > > Originally I was thinking that I needed to add the "resource_access" claim to the token (with "realm-management" roles), because the admin API was using the "KeycloakIdentity" class in "MgmtPermissions.hasOneAdminRole" calls. However, now I've gone with changing the "azp" (issued-for) claim instead, so that "MgmtPermissions.initIdentity" uses the "UserModelIdentity" class instead. FYI - I've arbitrarily chosen to use the "admin-cli" client id for the "azp" claim, but "security-admin-console" would work just as well. > > This is all accomplished with a single client specific script mapper with no "Token Claim Name", no "Claim JSON Type", and set to only "Add to access token" (ie, ID token and user info flags are OFF). > > The script: > > ``` > // todo: can we make the service account detection a bit more robust? ie, sub claim?? > // note: could also check client session notes for form data scope so we don't always set the issued-for > var tokenName = null; > if (token !== null && token.getOtherClaims() !== null) { > tokenName = token.getOtherClaims().get('preferred_username'); > } > if (tokenName == 'service-account-test-client') { > // admin-cli is to get the admin api to use the usermodel instead of the token for roles > // you could also use the security-admin-console client id > // see MgmtPermissions.initIdentity > token.issuedFor('admin-cli'); > } > ``` > > Digging through the code I cannot find any other means of setting the issued-for of the token during the client credentials grant, but am I missing something? Is there another way we can set the issued-for at token request time? > > Cheers, > Gary > >>>> On 7 May 2019, at 9:38 am, Gary Kennedy <gary(a)apnic.net&gt; wrote: >> >>>>>> On 3 May 2019, at 8:38 am, Dmitry Telegin <demetrio(a)carretti.pro&gt; wrote: >>> >>> Hi Gary, >>> >>> To ensure proper "resource_access" claim, you can simply assign the necessary roles to your service account (client -> Service Account Roles -> Client Roles -> realm-management). Does that work for you? >> >> Unfortunately no. >> >> The roles are set, however they are not presented in the token, eg no "resource_access" claim. >> >> And because of the missing "resource_access" claim, using the token with the admin API results in 403 forbidden. >> >>> If you still need to use mappers, there are numerous ways to determine if the token was issued for a service account. For example, in your JS mapper you could look for "preferred_username" claim, its value will look like "service-account-<your-client>". >> >> Thanks. I previously explicitly tried the built-in "client roles" mapper for the client as well as creating a "user client role" mapper manually (not at the same time) and they were not adding the claim to the token so I assumed wrongly that the client mappers were not being used for the service account token. >> >> Using a script mapper (and a hardcoded claim mapper) works in that the service account token has the configured claims from those mappers. It seems like the "user client roles" mapper type is being filtered from the applied protocol mappers here. >> >> The mapper is applied to user tokens as well (of course) but at least using a script mapper will allow me to hack in the "resource_access" claim as I want. I'd like to do the right thing and have the script mapper use actual roles but I may have to fall back to hardcoding the claim value, we'll see how much effort is needed and that I'm allowed to put in :p. >> >>> Cheers, >>> Dmitry >>> >>> On Thu, 2019-05-02 at 06:18 +0000, Gary Kennedy wrote: >>>> I want to use a service account token to call the admin API (for it's realm) and have discovered that the token needs the "resource_access" claim (with appropriate "realm-management" roles). >>>> >>>> I don't want user tokens generated through the client to have the claim (unless absolutely necessary). >>>> >>>> How can I get mappers to only apply to the service account token? Or find the mappers used for the service account tokens? >>>> >>>> If I add the client roles mapper to the client I still don't get the "resource_access" claim in the service account token. >>>> >>>> (Keycloak 4.8.2) >>>> >>>> Cheers, >>>> Gary >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user

On 9 May 2019, at 11:47 am, Dmitry Telegin <demetrio(a)carretti.pro&gt; wrote: Gary, you're welcome! At least you now know how to do scripting in Keycloak, which is beyond any doubt a valuable asset :) Fun fact: did you know that in the context of Keycloak the term "scope" is used in at least seven (!) different meanings? :) Dmitry On Thu, 2019-05-09 at 00:11 +0000, Gary Kennedy wrote: > Ugh, someone had turned off the "Full Scope Allowed" setting in the client registration scope mappings. (Not me, I swear) > This is the second time I've been bitten by this and I feel dumb about wasting everyone's time because of it. > > Because the TokenManager uses the intersection of actual user roles with the client "scope mappings", with the scope mappings "Full Scope Allowed" being off and no matching assigned roles the final role set for the "resource_access" claim was empty - hence no "resource_access" claim. > > At least I have a better understanding of the Keycloak internals and another pain point to prompt me to check client scope mappings more often. > > Thank you Dmitry :) > >>>> On 9 May 2019, at 7:01 am, Dmitry Telegin <demetrio(a)carretti.pro&gt; wrote: >> >> Hi Gary, >> >> I'm still convinced this could be done much simpler. Just performed a quick test: >> - created a realm; >> - created an OIDC client of type "confidential"; >> - enabled service account; >> - went to Service Account Roles and assigned realm-management.manage-realm role; >> >> Then ran a script: >> >> #!/bin/sh >> >> KEYCLOAK_URL=http://localhost:8080/auth >> KEYCLOAK_REALM=test-realm >> KEYCLOAK_CLIENT=test-client >> KEYCLOAK_CLIENT_SECRET=... >> >> ACCESS_TOKEN=$(curl -s $KEYCLOAK_URL/realms/$KEYCLOAK_REALM/protocol/openid-connect/token \ >> --basic --user $KEYCLOAK_CLIENT:$KEYCLOAK_CLIENT_SECRET \ >> -d grant_type=client_credentials \ >> | jq -r '.access_token') >> >> echo $ACCESS_TOKEN | sed 's/\(.*\)\.\(.*\)\.\(.*\)/\2/' | base64 -d | jq >> >> I've been able to see the following inside the token: >> >> "realm_access": { >> "roles": [ >> "offline_access", >> "uma_authorization" >> ] >> }, >> "resource_access": { >> "realm-management": { >> "roles": [ >> "manage-realm" // <- this >> ] >> }, >> "account": { >> "roles": [ >> "manage-account", >> "manage-account-links", >> "view-profile" >> ] >> } >> }, >> >> (How it works: by default, built-in client scopes are assigned to the clients (see Client Scopes tab -> Assigned Default Client Scopes). >> One of them, namely "roles", invokes the "client roles" mapper, which in its turn resolves the roles and puts them into a token.) >> >> Could you please try to reproduce the same on your instance? Hope that helps, >> >> Dmitry Telegin >> Opensource IAM consultant >> https://www.linkedin.com/in/d-telegin >> >> On Tue, 2019-05-07 at 03:40 +0000, Gary Kennedy wrote: >>> I think I've found an acceptable solution, can I get some feedback please? I don't want to risk any loopholes or lessened security here. >>> >>> Originally I was thinking that I needed to add the "resource_access" claim to the token (with "realm-management" roles), because the admin API was using the "KeycloakIdentity" class in "MgmtPermissions.hasOneAdminRole" calls. However, now I've gone with changing the "azp" (issued-for) claim instead, so that "MgmtPermissions.initIdentity" uses the "UserModelIdentity" class instead. FYI - I've arbitrarily chosen to use the "admin-cli" client id for the "azp" claim, but "security-admin-console" would work just as well. >>> >>> This is all accomplished with a single client specific script mapper with no "Token Claim Name", no "Claim JSON Type", and set to only "Add to access token" (ie, ID token and user info flags are OFF). >>> >>> The script: >>> >>> ``` >>> // todo: can we make the service account detection a bit more robust? ie, sub claim?? >>> // note: could also check client session notes for form data scope so we don't always set the issued-for >>> var tokenName = null; >>> if (token !== null && token.getOtherClaims() !== null) { >>> tokenName = token.getOtherClaims().get('preferred_username'); >>> } >>> if (tokenName == 'service-account-test-client') { >>> // admin-cli is to get the admin api to use the usermodel instead of the token for roles >>> // you could also use the security-admin-console client id >>> // see MgmtPermissions.initIdentity >>> token.issuedFor('admin-cli'); >>> } >>> ``` >>> >>> Digging through the code I cannot find any other means of setting the issued-for of the token during the client credentials grant, but am I missing something? Is there another way we can set the issued-for at token request time? >>> >>> Cheers, >>> Gary >>> >>>>>>>>>>>> On 7 May 2019, at 9:38 am, Gary Kennedy <gary(a)apnic.net&gt; wrote: >>>>>>>> On 3 May 2019, at 8:38 am, Dmitry Telegin <demetrio(a)carretti.pro&gt; wrote: >>>>> >>>>> Hi Gary, >>>>> >>>>> To ensure proper "resource_access" claim, you can simply assign the necessary roles to your service account (client -> Service Account Roles -> Client Roles -> realm-management). Does that work for you? >>>> >>>> Unfortunately no. >>>> >>>> The roles are set, however they are not presented in the token, eg no "resource_access" claim. >>>> >>>> And because of the missing "resource_access" claim, using the token with the admin API results in 403 forbidden. >>>> >>>>> If you still need to use mappers, there are numerous ways to determine if the token was issued for a service account. For example, in your JS mapper you could look for "preferred_username" claim, its value will look like "service-account-<your-client>". >>>> >>>> Thanks. I previously explicitly tried the built-in "client roles" mapper for the client as well as creating a "user client role" mapper manually (not at the same time) and they were not adding the claim to the token so I assumed wrongly that the client mappers were not being used for the service account token. >>>> >>>> Using a script mapper (and a hardcoded claim mapper) works in that the service account token has the configured claims from those mappers. It seems like the "user client roles" mapper type is being filtered from the applied protocol mappers here. >>>> >>>> The mapper is applied to user tokens as well (of course) but at least using a script mapper will allow me to hack in the "resource_access" claim as I want. I'd like to do the right thing and have the script mapper use actual roles but I may have to fall back to hardcoding the claim value, we'll see how much effort is needed and that I'm allowed to put in :p. >>>> >>>>> Cheers, >>>>> Dmitry >>>>> >>>>> On Thu, 2019-05-02 at 06:18 +0000, Gary Kennedy wrote: >>>>>> I want to use a service account token to call the admin API (for it's realm) and have discovered that the token needs the "resource_access" claim (with appropriate "realm-management" roles). >>>>>> >>>>>> I don't want user tokens generated through the client to have the claim (unless absolutely necessary). >>>>>> >>>>>> How can I get mappers to only apply to the service account token? Or find the mappers used for the service account tokens? >>>>>> >>>>>> If I add the client roles mapper to the client I still don't get the "resource_access" claim in the service account token. >>>>>> >>>>>> (Keycloak 4.8.2) >>>>>> >>>>>> Cheers, >>>>>> Gary >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-user mailing list >>>>>> keycloak-user(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >