4:12 a.m.
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-mapp...
relevant commit:
https://github.com/thomasdarimont/keycloak/commit/eb25e72060f75a00afd188f...
Cheers,
Thomas
2016-07-01 9:53 GMT+02:00 Thomas Darimont <thomas.darimont(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>