Hi all, Keycloak version: 1.9.8 Here is my use case: I want to keep the access token JWS as lean as possible, only containing user roles and a few custom claims I have added. I want no PII in the access token. However, I would like my internal services to obtain the full user profile (name, email, etc...) from the OIDC "/userinfo" endpoint. Unfortunately, I can only seem to obtain the "sub" claim and the few custom claims that already exist in the access token. I don't see any support for adding scope values to the request. Is there any way to accomplish what I would like, or any other ways of obtaining this info that I may be missing? Thanks in advance _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hello Brian, I gave this a quick spin - I introduced an additional option that allows to configure whether a claim from a client mapper should be included in userinfo or not. With that in place one can now control whether a claim should be contained in the access-token, id-token or userinfo which helps to keep access-tokens lean. For the sake of simplicity I only added support for controlling user attributes but I think this could be a useful for other mappers as well. Branch is here: https://github.com/thomasdarimont/keycloak/tree/poc/KEYCLOAK-XXX-use-mapp... relevant commit: https://github.com/thomasdarimont/keycloak/commit/eb25e72060f75a00afd188f... Cheers, Thomas 2016-07-01 9:53 GMT+02:00 Thomas Darimont <thomas.darimont(a)googlemail.com&gt; : > Hello Brian, > > I gave this a spin (with 1.9.x and master) and I think that currently the > only way to extend the information in the > userinfo endpoint is by defining a custom mapper and register that for > the client you use to get the > access-token. > The protocol mappers of this client will be used for the userinfo > endpoint. However the downside of this approach is that > this information is now also added to the access-token which you wanted > to avoid. > > It would be great of one had an additional switchable option for custom > protocol mappers like "include in userinfo". > With this enabled one could control very explicitly what should go where. > > I added a small curl command sequence below that can be used for testing. > > Cheers, > Thomas > > # Setup > KC_REALM=acme-test > KC_USERNAME=tester > KC_PASSWORD=test > KC_CLIENT=test-client > KC_CLIENT_SECRET=3ee678ac-b31b-4bb6-80fa-5f25c7817bf0 > KC_SERVER=192.168.99.1:8080 > KC_CONTEXT=auth > CURL_OPTS="-k -v --noproxy 192.168.99.1" > > # Step 1 Request Tokens for credentials > KC_RESPONSE=$( \ > curl $CURL_OPTS -X POST \ > -H "Content-Type: application/x-www-form-urlencoded" \ > -d "username=$KC_USERNAME" \ > -d "password=$KC_PASSWORD" \ > -d 'grant_type=password' \ > -d "client_id=$KC_CLIENT" \ > -d "client_secret=$KC_CLIENT_SECRET" \ > "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" > \ > | jq . > ) > > # Step 2 Split tokens > KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token) > KC_ID_TOKEN=$(echo $KC_RESPONSE| jq -r .id_token) > KC_REFRESH_TOKEN=$(echo $KC_RESPONSE| jq -r .refresh_token) > > # Step 3 (Debug) Show all keycloak env variables > set | grep KC_* > > # Step 4 Access Keycloak User Info > curl $CURL_OPTS \ > -X POST \ > -H "Content-Type: application/x-www-form-urlencoded" \ > -d "access_token=$KC_ACCESS_TOKEN" \ > "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" > | jq . > > # Step 5 Define a new protocol mapper for the client test-client in the > admin-console > # via clients -> test-client -> mappers -> new -> as an example map a > custom user attribute -> add to access token > # After that a request to the userinfo endpoint will show your custom > attribute. > > # Step 6 Access Keycloak User Info > curl $CURL_OPTS \ > -X POST \ > -H "Content-Type: application/x-www-form-urlencoded" \ > -d "access_token=$KC_ACCESS_TOKEN" \ > "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" > | jq . > > > > 2016-06-30 16:41 GMT+02:00 Brian Watson <watson409(a)gmail.com&gt;: > >> Hi all, >> >> Keycloak version: 1.9.8 >> >> Here is my use case: I want to keep the access token JWS as lean as >> possible, only containing user roles and a few custom claims I have added. >> I want no PII in the access token. However, I would like my internal >> services to obtain the full user profile (name, email, etc...) from the >> OIDC "/userinfo" endpoint. Unfortunately, I can only seem to obtain the >> "sub" claim and the few custom claims that already exist in the access >> token. I don't see any support for adding scope values to the request. >> >> Is there any way to accomplish what I would like, or any other ways of >> obtaining this info that I may be missing? >> >> Thanks in advance >> >> _______________________________________________ >> 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

Cool - shall I file a jira and issue a PR? Then you can polish it a bit ;-) Cheers, Thomas 2016-07-01 11:18 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com&gt;: > +1 To the user info toggle for mappers > > On 1 July 2016 at 11:12, Thomas Darimont <thomas.darimont(a)googlemail.com&gt; > wrote: > >> Hello Brian, >> >> I gave this a quick spin - I introduced an additional option that allows >> to configure whether a claim from a >> client mapper should be included in userinfo or not. >> With that in place one can now control whether a claim should be >> contained in the access-token, id-token or userinfo >> which helps to keep access-tokens lean. >> >> For the sake of simplicity I only added support for controlling user >> attributes but I think this could be a useful >> for other mappers as well. >> >> Branch is here: >> >> https://github.com/thomasdarimont/keycloak/tree/poc/KEYCLOAK-XXX-use-mapp... >> relevant commit: >> >> https://github.com/thomasdarimont/keycloak/commit/eb25e72060f75a00afd188f... >> >> Cheers, >> Thomas >> >> 2016-07-01 9:53 GMT+02:00 Thomas Darimont < >> thomas.darimont(a)googlemail.com&gt;: >> >>> Hello Brian, >>> >>> I gave this a spin (with 1.9.x and master) and I think that currently >>> the only way to extend the information in the >>> userinfo endpoint is by defining a custom mapper and register that for >>> the client you use to get the >>> access-token. >>> The protocol mappers of this client will be used for the userinfo >>> endpoint. However the downside of this approach is that >>> this information is now also added to the access-token which you wanted >>> to avoid. >>> >>> It would be great of one had an additional switchable option for custom >>> protocol mappers like "include in userinfo". >>> With this enabled one could control very explicitly what should go >>> where. >>> >>> I added a small curl command sequence below that can be used for >>> testing. >>> >>> Cheers, >>> Thomas >>> >>> # Setup >>> KC_REALM=acme-test >>> KC_USERNAME=tester >>> KC_PASSWORD=test >>> KC_CLIENT=test-client >>> KC_CLIENT_SECRET=3ee678ac-b31b-4bb6-80fa-5f25c7817bf0 >>> KC_SERVER=192.168.99.1:8080 >>> KC_CONTEXT=auth >>> CURL_OPTS="-k -v --noproxy 192.168.99.1" >>> >>> # Step 1 Request Tokens for credentials >>> KC_RESPONSE=$( \ >>> curl $CURL_OPTS -X POST \ >>> -H "Content-Type: application/x-www-form-urlencoded" \ >>> -d "username=$KC_USERNAME" \ >>> -d "password=$KC_PASSWORD" \ >>> -d 'grant_type=password' \ >>> -d "client_id=$KC_CLIENT" \ >>> -d "client_secret=$KC_CLIENT_SECRET" \ >>> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" >>> \ >>> | jq . >>> ) >>> >>> # Step 2 Split tokens >>> KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token) >>> KC_ID_TOKEN=$(echo $KC_RESPONSE| jq -r .id_token) >>> KC_REFRESH_TOKEN=$(echo $KC_RESPONSE| jq -r .refresh_token) >>> >>> # Step 3 (Debug) Show all keycloak env variables >>> set | grep KC_* >>> >>> # Step 4 Access Keycloak User Info >>> curl $CURL_OPTS \ >>> -X POST \ >>> -H "Content-Type: application/x-www-form-urlencoded" \ >>> -d "access_token=$KC_ACCESS_TOKEN" \ >>> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" >>> | jq . >>> >>> # Step 5 Define a new protocol mapper for the client test-client in the >>> admin-console >>> # via clients -> test-client -> mappers -> new -> as an example map a >>> custom user attribute -> add to access token >>> # After that a request to the userinfo endpoint will show your custom >>> attribute. >>> >>> # Step 6 Access Keycloak User Info >>> curl $CURL_OPTS \ >>> -X POST \ >>> -H "Content-Type: application/x-www-form-urlencoded" \ >>> -d "access_token=$KC_ACCESS_TOKEN" \ >>> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" >>> | jq . >>> >>> >>> >>> 2016-06-30 16:41 GMT+02:00 Brian Watson <watson409(a)gmail.com&gt;: >>> >>>> Hi all, >>>> >>>> Keycloak version: 1.9.8 >>>> >>>> Here is my use case: I want to keep the access token JWS as lean as >>>> possible, only containing user roles and a few custom claims I have added. >>>> I want no PII in the access token. However, I would like my internal >>>> services to obtain the full user profile (name, email, etc...) from the >>>> OIDC "/userinfo" endpoint. Unfortunately, I can only seem to obtain the >>>> "sub" claim and the few custom claims that already exist in the access >>>> token. I don't see any support for adding scope values to the request. >>>> >>>> Is there any way to accomplish what I would like, or any other ways of >>>> obtaining this info that I may be missing? >>>> >>>> Thanks in advance >>>> >>>> _______________________________________________ >>>> 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 >> > >

Great! Thank you all so much for the quick response and effort! On Fri, Jul 1, 2016 at 5:24 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > Ideally PR should come with polish and testing. Otherwise it'll just sit > in the queue ;) > > On 1 July 2016 at 11:19, Thomas Darimont <thomas.darimont(a)googlemail.com&gt; > wrote: > >> Cool - shall I file a jira and issue a PR? Then you can polish it a bit >> ;-) >> >> Cheers, >> Thomas >> >> 2016-07-01 11:18 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com&gt;: >> >>> +1 To the user info toggle for mappers >>> >>> On 1 July 2016 at 11:12, Thomas Darimont < >>> thomas.darimont(a)googlemail.com&gt; wrote: >>> >>>> Hello Brian, >>>> >>>> I gave this a quick spin - I introduced an additional option that >>>> allows to configure whether a claim from a >>>> client mapper should be included in userinfo or not. >>>> With that in place one can now control whether a claim should be >>>> contained in the access-token, id-token or userinfo >>>> which helps to keep access-tokens lean. >>>> >>>> For the sake of simplicity I only added support for controlling user >>>> attributes but I think this could be a useful >>>> for other mappers as well. >>>> >>>> Branch is here: >>>> >>>> https://github.com/thomasdarimont/keycloak/tree/poc/KEYCLOAK-XXX-use-mapp... >>>> relevant commit: >>>> >>>> https://github.com/thomasdarimont/keycloak/commit/eb25e72060f75a00afd188f... >>>> >>>> Cheers, >>>> Thomas >>>> >>>> 2016-07-01 9:53 GMT+02:00 Thomas Darimont < >>>> thomas.darimont(a)googlemail.com&gt;: >>>> >>>>> Hello Brian, >>>>> >>>>> I gave this a spin (with 1.9.x and master) and I think that currently >>>>> the only way to extend the information in the >>>>> userinfo endpoint is by defining a custom mapper and register that >>>>> for the client you use to get the >>>>> access-token. >>>>> The protocol mappers of this client will be used for the userinfo >>>>> endpoint. However the downside of this approach is that >>>>> this information is now also added to the access-token which you >>>>> wanted to avoid. >>>>> >>>>> It would be great of one had an additional switchable option for >>>>> custom protocol mappers like "include in userinfo". >>>>> With this enabled one could control very explicitly what should go >>>>> where. >>>>> >>>>> I added a small curl command sequence below that can be used for >>>>> testing. >>>>> >>>>> Cheers, >>>>> Thomas >>>>> >>>>> # Setup >>>>> KC_REALM=acme-test >>>>> KC_USERNAME=tester >>>>> KC_PASSWORD=test >>>>> KC_CLIENT=test-client >>>>> KC_CLIENT_SECRET=3ee678ac-b31b-4bb6-80fa-5f25c7817bf0 >>>>> KC_SERVER=192.168.99.1:8080 >>>>> KC_CONTEXT=auth >>>>> CURL_OPTS="-k -v --noproxy 192.168.99.1" >>>>> >>>>> # Step 1 Request Tokens for credentials >>>>> KC_RESPONSE=$( \ >>>>> curl $CURL_OPTS -X POST \ >>>>> -H "Content-Type: application/x-www-form-urlencoded" \ >>>>> -d "username=$KC_USERNAME" \ >>>>> -d "password=$KC_PASSWORD" \ >>>>> -d 'grant_type=password' \ >>>>> -d "client_id=$KC_CLIENT" \ >>>>> -d "client_secret=$KC_CLIENT_SECRET" \ >>>>> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" >>>>> \ >>>>> | jq . >>>>> ) >>>>> >>>>> # Step 2 Split tokens >>>>> KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token) >>>>> KC_ID_TOKEN=$(echo $KC_RESPONSE| jq -r .id_token) >>>>> KC_REFRESH_TOKEN=$(echo $KC_RESPONSE| jq -r .refresh_token) >>>>> >>>>> # Step 3 (Debug) Show all keycloak env variables >>>>> set | grep KC_* >>>>> >>>>> # Step 4 Access Keycloak User Info >>>>> curl $CURL_OPTS \ >>>>> -X POST \ >>>>> -H "Content-Type: application/x-www-form-urlencoded" \ >>>>> -d "access_token=$KC_ACCESS_TOKEN" \ >>>>> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" >>>>> | jq . >>>>> >>>>> # Step 5 Define a new protocol mapper for the client test-client in >>>>> the admin-console >>>>> # via clients -> test-client -> mappers -> new -> as an example map a >>>>> custom user attribute -> add to access token >>>>> # After that a request to the userinfo endpoint will show your custom >>>>> attribute. >>>>> >>>>> # Step 6 Access Keycloak User Info >>>>> curl $CURL_OPTS \ >>>>> -X POST \ >>>>> -H "Content-Type: application/x-www-form-urlencoded" \ >>>>> -d "access_token=$KC_ACCESS_TOKEN" \ >>>>> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" >>>>> | jq . >>>>> >>>>> >>>>> >>>>> 2016-06-30 16:41 GMT+02:00 Brian Watson <watson409(a)gmail.com&gt;: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Keycloak version: 1.9.8 >>>>>> >>>>>> Here is my use case: I want to keep the access token JWS as lean as >>>>>> possible, only containing user roles and a few custom claims I have added. >>>>>> I want no PII in the access token. However, I would like my internal >>>>>> services to obtain the full user profile (name, email, etc...) from the >>>>>> OIDC "/userinfo" endpoint. Unfortunately, I can only seem to obtain the >>>>>> "sub" claim and the few custom claims that already exist in the access >>>>>> token. I don't see any support for adding scope values to the request. >>>>>> >>>>>> Is there any way to accomplish what I would like, or any other ways >>>>>> of obtaining this info that I may be missing? >>>>>> >>>>>> Thanks in advance >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >> >