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&gt; Cc: Marek Posolda <mposolda(a)redhat.com>; keycloak-user(a)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.