8:11 a.m.
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.
Kind regards
Dan
3:14 p.m.
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
https://lists.jboss.org/mailman/listinfo/keycloak-user
1:54 a.m.
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>; keycloak-user(a)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
https://lists.jboss.org/mailman/listinfo/keycloak-user
7:11 a.m.
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> 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>; keycloak-user(a)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
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
9:54 a.m.
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>
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.
On Aug 30, 2017, at 2:54 AM, Daniel Storey
<daniel.storey(a)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>; keycloak-user(a)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
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3:49 p.m.
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>
Sent: Wednesday, August 30, 2017 10:54:45 AM
To: Phillip Fleischer
Cc: Marek Posolda; keycloak-user(a)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>
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.
On Aug 30, 2017, at 2:54 AM, Daniel Storey
<daniel.storey(a)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>; keycloak-user(a)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
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3:38 a.m.
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>
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@weareact.com<mailto:daniel.storey@weareact.com>>
Sent: Wednesday, August 30, 2017 10:54:45 AM
To: Phillip Fleischer
Cc: Marek Posolda;
keycloak-user@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@weareact.com<mailto:daniel.storey@weareact.com>>
Cc: Marek Posolda <mposolda@redhat.com<mailto:mposolda@redhat.com>>;
keycloak-user@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@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@weareact.com<mailto:daniel.storey@weareact.com>>;
keycloak-user@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@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
9:53 a.m.
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@outlook.com]
*Sent:* 30 August 2017 21:49
*To:* Daniel Storey <daniel.storey(a)weareact.com>
*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
3140
days inactive
3150
days old
7 comments
3 participants
participants (3)
-
Daniel Storey -
Marek Posolda -
Phillip Fleischer