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

[Thomas Darimont]

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/3b22731f/attachment-0001.html