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

Fri Jul 1 08:49:38 EDT 2016

Great! Thank you all so much for the quick response and effort!

On Fri, Jul 1, 2016 at 5:24 AM, Stian Thorgersen <sthorger at redhat.com>
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 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/bf0491df/attachment-0001.html 