Re: [keycloak-user] Obtaining full profile from "userinfo" endpoint

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 >> > >