Re: [keycloak-user] Service account user attributes

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@outlook.com] *Sent:* 30 August 2017 21:49 *To:* Daniel Storey <daniel.storey(a)weareact.com&gt; *Cc:* Marek Posolda <mposolda(a)redhat.com>; keycloak-user(a)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(a)weareact.com <mailto:daniel.storey@weareact.com>> *Sent:* Wednesday, August 30, 2017 10:54:45 AM *To:* Phillip Fleischer *Cc:* Marek Posolda; keycloak-user(a)lists.jboss.org <mailto:keycloak-user@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@outlook.com] Sent: 30 August 2017 13:11 To: Daniel Storey <daniel.storey(a)weareact.com <mailto:daniel.storey@weareact.com>> Cc: Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>; keycloak-user(a)lists.jboss.org <mailto:keycloak-user@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(a)weareact.com <mailto:daniel.storey@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@redhat.com] > Sent: 25 August 2017 21:15 > To: Daniel Storey <daniel.storey(a)weareact.com <mailto:daniel.storey@weareact.com>>; keycloak-user(a)lists.jboss.org <mailto:keycloak-user@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(a)lists.jboss.org <mailto:keycloak-user@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