[keycloak-user] Service account user attributes

[Daniel Storey]

Hi Phillip

Thanks very much for your suggestion. 

To give a bit more context, I have a requirement to convert a custom attribute associated with the resource owner (user or service account) into a complex type OIDC claim for all token requests. I have achieved this for requests associated with a user account by implementing an OIDC protocol mapper similar to the "User Attribute" mapper. I have attempted to do the same for service account requests by adding functionality similar to the "Hardcoded Claim" mapper. My mapper checks the UserModel associated with the request, then executes either User Attribute mapper-esque logic, where the value to convert to a claim comes from a user attribute, or Hardcoded Claim mapper-esque logic, where the value to convert comes from the ProtocolMapperModel. The hardcoded claim part essentially allows me to define service account-specific claims via the admin UI.

It seems UserModel.serviceAccountClientLink is only set on service account token requests (null on user requests), so I'm driving my mapper logic off the presence of this property. If this is not advisable, I will define a service account role and check this instead, as you suggest.

Given my requirement, does this sound like a reasonable solution?


-----Original Message-----
From: Phillip Fleischer [mailto:pcfleischer at outlook.com] 
Sent: 30 August 2017 13:11
To: Daniel Storey <daniel.storey at weareact.com>
Cc: Marek Posolda <mposolda at redhat.com>; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Service account user attributes

Is there a reason you’re not using service account roles?  

This is what we use for this.  Ideally you’d create realm and client roles that determine the access level for whatever actions you want the service account to be authorized to do, or you could just make a role “service_account” which will show in the realm role access in the token or some combination of roles that do both.  If you then want this to be a “claim” instead of a “role” in the token then you could use the “User Realm Role” protocol mapper (assuming OIDC protocol)

It’d probably be cool too to be able to actually mess with the user entity in the admin too to do some attributes that are a claim…  but there’s probably a bunch of good reasons not to allow that either (e.g. there’s a bunch of stuff you can’t do like impersonate or delete that would need to be blocked from the UI).  It might be possible to edit the user via the rest api too if you really really need it to be an attribute, but that’s likely a hack.


> On Aug 30, 2017, at 2:54 AM, Daniel Storey <daniel.storey at weareact.com> wrote:
> 
> Thanks Marek. What would you suggest is the most reliable way to detect a service account login from a protocol mapper? Is there a service account flag in UserModel, or would I need to check for the existence of known service account field(s), such as client notes?
> 
> Are there any plans to make service account users viewable/editable in the same way as 'normal' users (via the Keycloak admin UI) in a future release?
> 
> Many thanks
> Dan
> 
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com] 
> Sent: 25 August 2017 21:15
> To: Daniel Storey <daniel.storey at weareact.com>; keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] Service account user attributes
> 
> On 25/08/17 15:11, Daniel Storey wrote:
>> Hello
>> 
>> I would like to use service accounts to allow my OIDC clients to obtain access tokens using the client credentials grant. Furthermore, I'm trying to find a way to define additional attributes for each service account client so that I can map them to custom claims via a protocol mapper.
>> 
>> I notice that Keycloak creates an internal user for each service account in its database, but the user is not visible/editable through the admin UI. Therefore, I am unable to create attributes for the service account user as I can for 'normal' users.
>> 
>> I think I can define custom claims for a service account using a protocol mapper (something like the "hardcoded claim" mapper), assuming I can distinguish service account requests from user requests in the mapper. If this approach is not recommended, I would be very grateful if you could suggest an alternative.
> That's possible if you plan to implement your own protocol mapper. You can detect if login is service-account for example by checking if UserModel corresponds to service-account user. There are also some client notes, which are available just for service-account logins.
> 
> Marek
>> 
>> Kind regards
>> Dan
>> 
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user