[keycloak-user] Service account user attributes

Phillip Fleischer pcfleischer at outlook.com
Wed Aug 30 08:11:23 EDT 2017


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




More information about the keycloak-user mailing list