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>
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>