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

On Fri, Jul 1, 2016 at 5:24 AM, Stian Thorgersen <sthorger@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@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@redhat.com>:
+1 To the user info toggle for mappers

On 1 July 2016 at 11:12, Thomas Darimont <thomas.darimont@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:
relevant commit:

Cheers,
Thomas

2016-07-01 9:53 GMT+02:00 Thomas Darimont <thomas.darimont@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_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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user