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

Fri Jul 1 05:24:59 EDT 2016

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 at googlemail.com>
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 at redhat.com>:
>
>> +1 To the user info toggle for mappers
>>
>> On 1 July 2016 at 11:12, Thomas Darimont <thomas.darimont at googlemail.com>
>> 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-mapper-only-for-userinfo-endpoint
>>> relevant commit:
>>>
>>> https://github.com/thomasdarimont/keycloak/commit/eb25e72060f75a00afd188fc3b2c242e7b21aa7f
>>>
>>> Cheers,
>>> Thomas
>>>
>>> 2016-07-01 9:53 GMT+02:00 Thomas Darimont <
>>> thomas.darimont at googlemail.com>:
>>>
>>>> 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 at gmail.com>:
>>>>
>>>>> 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160701/887657ee/attachment-0001.html 