Direct Naked Impersonation - error: access_denied

Describe the bug

I have followed directions according to the guide (https://www.keycloak.org/docs/latest/securing_apps/#direct-naked-impersonation), but still cannot get it to work. After researching, seems like others can’t get it to work neither (https://keycloak.discourse.group/t/direct-naked-impersonation/6887/3) and unfortunately I wasn’t able to find a possible solution.

Details about my Keycloak installation:

Version: 18 Installed using containers (AWS ECS) and using this guide: https://www.keycloak.org/server/containers SSL enabled token-exchange and admin-fine-grained-authz features enabled

Example request:

curl --location --request POST 'https://example_domain.com/realms/my-realm/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'client_id=my-client' \
--data-urlencode 'client_secret=iXwJB01N5u0WcTEMMcGA1KvUWm5VA9HN' \
--data-urlencode 'requested_subject=test_user'

Example response:

403
{
    "error": "access_denied",
    "error_description": "Client not allowed to exchange"
}

Has anybody experienced the same or know if there’s anything else to configure or may it be a bug?

Version

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Anything else?

No response

Issue Analytics

State:
Created a year ago
Comments:7 (2 by maintainers)

Top GitHub Comments

3reactions

motiejusscommented, Jun 20, 2022

I figured out a way, but I’m not sure this is the right way to do it. Some help from more experienced experts would be very much appreciated.

When following the Direct Naked Impersonation guide, instead of user-impersonated under Users -> Permissions I chose impersonate to apply the client-impersonators policy.

And then in order to achieve the desired result, there’s rather a 2 step call that looks like this:

curl --location --request POST 'https://identity.domain.com/realms/my-realm/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=my_client_id' \
--data-urlencode 'client_secret=BZqGENd9LKJTixvJLl860jpCJvMgAY7y'

Client access_token from the response will then be used in the next call as a subject_token parameter.

curl --location --request POST 'https://identity.domain.com/realms/my-realm/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'requested_token_type=urn:ietf:params:oauth:token-type:access_token' \
--data-urlencode 'subject_token=eyJhbGciOiJSUzIU0ODU5NzQsImlhdCI6MTY1NTQ0OTk3NCwianRpIjoiZmFkYTBkODctNzMyYy00ZDY4LWJhYzctMDk2NWU1ZmJjMGFkIiwiaXNzIjoiaHR0cHM6Ly9zdGFnaW5nLWlkZW50aXR5Lm5vaWUuY29tL3JlYWxtcy9teS1yZWFsbSxlcy1teS1yZWFsbSJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InJlYWxtLW1hbmFnZW1lbnQiOnsicm9sZXMiOlsibWFuYWdlLXVzZXJzIiwidmlldy11c2VycyIsInF1ZXJ5LWdCBwcm9maWxlIiwiY2xpZW50SWQiOiJ3ZWJzaXRlIiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJjbGllbnRIb3N0IjoiODIuMTkyLjE3MS4yMzgiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzZXJ2aWNlLWFjY291bnQtd2Vic2l0ZSIsImNsaWVudEFkZHJlc3MiOiI4Mi4xOTIuMTcxLjIzOCJ9.ZducIG0iqNJ55kWgcN7-EwZvVibwa-RCl2lc3JZRCike4bkhIHBOWe_ypFPb-i_VEVRhKrhv-vANl5xIFbvqez_1PRGrhqHhIaf5xQmMoFu_TKd7EoKIbk_bCKrj3P3OdVqt0N0Uiutc2IDSlhsLGtFHmz1H5vc_2Jddlp_KnjeSjobiamC9_4ut2uGVYJ8ev_639hF54Y67_rH88SPorAM8riWFxsvhi0LDQ5swBpi9rT1K-cAT3PtrM2vKITg4H-GSfKI3z7VA' \
--data-urlencode 'client_secret=BZqGENd9LKJTixvJLl860jpCJvMgAY7y' \
--data-urlencode 'client_id=my_client_id' \
--data-urlencode 'audience=my_client_id' \
--data-urlencode 'requested_subject=username'

Response of the above should give User’s access token that then can be used to authenticate (or rather impersonate).

However it’s still not at all how the official guide describes it.

1reaction

nlokecommented, Jun 23, 2022

@pedroigor The updated Documentation still does not reflect that the whole Direct Naked steps are wrong like what @motiejuss mentioned. In the documentation it is just a ONE STEP curl with the clientID and secret, not like the example that @motiejuss provided which is two steps and requires the access token from first doing a client_credential flow.

Below is what the current documentation have without mention of the subject token.

curl -X POST \
    -d "client_id=starting-client" \
    -d "client_secret=the client secret" \
    --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
    -d "requested_subject=wburke" \
    http://localhost:8080/auth/realms/myrealm/protocol/openid-connect/token

Top Results From Across the Web

Unable to reproduce keycloak direct naked impersonation

In your expert there is no Policy that permits a specific Client to use the Impersonation feature. Example from my Realm:

Direct Naked Impersonation - Getting advice - Keycloak

I have a client that needs to impersonate a user and these steps did not help, so in addition you will notice that...

Securing Applications and Services Guide - Keycloak

This is called a direct naked impersonation because it places a lot of trust in a client as that client can impersonate any...

keycloak-documentation/token-exchange.adoc at main - GitHub

You can make an internal token exchange request without providing a subject_token . This is called a direct naked impersonation because it places...

Gestion des Identités Archives - JANUA - RSSing.com

ERROR 1698 (28000): Access denied for user 'root'@'localhost' at Ubuntu 18.04 ... So direct naked impersonation is just an authentication flow which allows ......