[keycloak-user] Service account user attributes

Mon Sep 4 10:53:33 EDT 2017

I can confirm that UserModel.serviceAccountClientLink is available just 
for service-account users.

Marek

On 31/08/17 10:38, Daniel Storey wrote:
>
> Thanks Phillip. I need a custom mapper to transform my user/service 
> account attribute into a complex object claim value (not a primitive 
> claim value). So, unfortunately, it’s not simply a case of mapping a 
> role name to a claim, which is what I think you are suggesting?
>
> Assuming a custom mapper is necessary, it seems to make sense to fold 
> the user/service account conditional logic into the mapper.
>
> *From:*Phillip Fleischer [mailto:pcfleischer at outlook.com]
> *Sent:* 30 August 2017 21:49
> *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
>
> I'm not a contributor just an avid user. So "best" is relative.
>
> Seems like your solution will work just also seems like a service 
> account role mapping would also work without any code.  Both should be 
> capable of controlling through the admin UI, so I guess not much 
> difference.
>
> ------------------------------------------------------------------------
>
> *From:*Daniel Storey <daniel.storey at weareact.com 
> <mailto:daniel.storey at weareact.com>>
> *Sent:* Wednesday, August 30, 2017 10:54:45 AM
> *To:* Phillip Fleischer
> *Cc:* Marek Posolda; keycloak-user at lists.jboss.org 
> <mailto:keycloak-user at lists.jboss.org>
> *Subject:* RE: [keycloak-user] Service account user attributes
>
> 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 
> <mailto:daniel.storey at weareact.com>>
> Cc: Marek Posolda <mposolda at redhat.com <mailto:mposolda at redhat.com>>; 
> keycloak-user at lists.jboss.org <mailto: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 <mailto: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 
> <mailto:daniel.storey at weareact.com>>; keycloak-user at lists.jboss.org 
> <mailto: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 <mailto:keycloak-user at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>