<div dir="ltr">Cool - shall I file a jira and issue a PR? Then you can polish it a bit ;-)<div><br></div><div>Cheers,</div><div>Thomas</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-01 11:18 GMT+02:00 Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+1 To the user info toggle for mappers</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 1 July 2016 at 11:12, Thomas Darimont <span dir="ltr"><<a href="mailto:thomas.darimont@googlemail.com" target="_blank">thomas.darimont@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Brian,<div><br></div><div>I gave this a quick spin - I introduced an additional option that allows to configure whether a claim from a </div><div>client mapper should be included in userinfo or not. </div><div>With that in place one can now control whether a claim should be contained in the access-token, id-token or userinfo</div><div>which helps to keep access-tokens lean.</div><div><br></div><div>For the sake of simplicity I only added support for controlling user attributes but I think this could be a useful </div><div>for other mappers as well.</div><div><br></div><div>Branch is here:</div><div><a href="https://github.com/thomasdarimont/keycloak/tree/poc/KEYCLOAK-XXX-use-mapper-only-for-userinfo-endpoint" target="_blank">https://github.com/thomasdarimont/keycloak/tree/poc/KEYCLOAK-XXX-use-mapper-only-for-userinfo-endpoint</a><br></div><div>relevant commit:</div><div><a href="https://github.com/thomasdarimont/keycloak/commit/eb25e72060f75a00afd188fc3b2c242e7b21aa7f" target="_blank">https://github.com/thomasdarimont/keycloak/commit/eb25e72060f75a00afd188fc3b2c242e7b21aa7f</a><br></div><div><br></div><div>Cheers,</div><div>Thomas</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-01 9:53 GMT+02:00 Thomas Darimont <span dir="ltr"><<a href="mailto:thomas.darimont@googlemail.com" target="_blank">thomas.darimont@googlemail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello Brian,</div><div><br></div><div>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 </div><div>userinfo endpoint is by defining a custom mapper and register that for the client you use to get the</div><div>access-token.</div><div>The protocol mappers of this client will be used for the userinfo endpoint. However the downside of this approach is that </div><div>this information is now also added to the access-token which you wanted to avoid.</div><div><br></div><div>It would be great of one had an additional switchable option for custom protocol mappers like "include in userinfo".</div><div>With this enabled one could control very explicitly what should go where.</div><div><br></div><div>I added a small curl command sequence below that can be used for testing.</div><div><br></div><div>Cheers,</div><div>Thomas</div><div><br></div><div># Setup</div><div>KC_REALM=acme-test</div><div>KC_USERNAME=tester</div><div>KC_PASSWORD=test</div><div>KC_CLIENT=test-client</div><div>KC_CLIENT_SECRET=3ee678ac-b31b-4bb6-80fa-5f25c7817bf0</div><div>KC_SERVER=<a href="http://192.168.99.1:8080" target="_blank">192.168.99.1:8080</a></div><div>KC_CONTEXT=auth</div><div>CURL_OPTS="-k -v --noproxy 192.168.99.1"</div><div><br></div><div># Step 1 Request Tokens for credentials</div><div>KC_RESPONSE=$( \ </div><div> curl $CURL_OPTS -X POST \</div><div> -H "Content-Type: application/x-www-form-urlencoded" \</div><div> -d "username=$KC_USERNAME" \</div><div> -d "password=$KC_PASSWORD" \</div><div> -d 'grant_type=password' \</div><div> -d "client_id=$KC_CLIENT" \</div><div> -d "client_secret=$KC_CLIENT_SECRET" \</div><div> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" \</div><div> | jq . </div><div>)</div><div><br></div><div># Step 2 Split tokens</div><div>KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token)</div><div>KC_ID_TOKEN=$(echo $KC_RESPONSE| jq -r .id_token)</div><div>KC_REFRESH_TOKEN=$(echo $KC_RESPONSE| jq -r .refresh_token)</div><div><br></div><div># Step 3 (Debug) Show all keycloak env variables</div><div>set | grep KC_*</div><div><br></div><div># Step 4 Access Keycloak User Info</div><div>curl $CURL_OPTS \</div><div> -X POST \</div><div> -H "Content-Type: application/x-www-form-urlencoded" \</div><div> -d "access_token=$KC_ACCESS_TOKEN" \</div><div> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" | jq .</div><div><br></div><div># Step 5 Define a new protocol mapper for the client test-client in the admin-console</div><div># via clients -> test-client -> mappers -> new -> as an example map a custom user attribute -> add to access token </div><div># After that a request to the userinfo endpoint will show your custom attribute.</div><div><br></div><div># Step 6 Access Keycloak User Info</div><div>curl $CURL_OPTS \</div><div> -X POST \</div><div> -H "Content-Type: application/x-www-form-urlencoded" \</div><div> -d "access_token=$KC_ACCESS_TOKEN" \</div><div> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" | jq .</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2016-06-30 16:41 GMT+02:00 Brian Watson <span dir="ltr"><<a href="mailto:watson409@gmail.com" target="_blank">watson409@gmail.com</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi all,<div><br></div><div>Keycloak version: 1.9.8</div><div><br></div><div>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.</div><div><br></div><div>Is there any way to accomplish what I would like, or any other ways of obtaining this info that I may be missing?</div><div><br></div><div>Thanks in advance</div></div>
<br></div></div>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>