Support for direct naked impersonation during token exchange

[tokoko]

Keycloak supports a non-standard and somewhat dangerous token exchange type called "direct naked impersonation" that allows a client to impersonate any user using it's own credentials alone. The request looks like this, you would do a normal token-exchange, but leave out subject token and set requested_subject field instead:

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/realms/myrealm/protocol/openid-connect/token

In practice, the change in auth manager would mean adding additional rest.auth.oauth2.token-exchange.requested_subject field.

The use case we have for it is an integration of iceberg rest catalog (polaris to be exact) with Apache Kyuubi. Out of the box Kyuubi supports LDAP or kerberos for authentication. Authorization story is a bit all over the place though, you can do full impersonation using kerberos depending on the setup or you can integrate it with Apache Ranger directly, but other than that you're on your own. Neither of those authorization solutions work for us, because we don't want to use either kerberos or Ranger.

One mechanism that I think could work is to rely on LDAP for authentication and then instruct Kyuubi to inject authenticated user's username in just the right places in spark conf (which is fortunately possible). In this case it would be the newly added requested_subject parameter that we would inject to effectively turn LDAP auth into OIDC impersonation.

P.S. I've not checked whether Nimbus allows this or not yet, but I'm pretty sure it should.

[adutra]

@tokoko thanks for this suggestion. How do you feel about contributing the implementation yourself? I could give you some guidelines.

I've not checked whether Nimbus allows this or not yet, but I'm pretty sure it should.

Well I checked, and the subject token is required in Nimbus. But it doesn't mean implementing this feature would be impossible, only that we would need to consider this as a different grant.

[tokoko]

Sure, I can give it a try. Managed to get my local env up and running and will familiarize myself with the code.

only that we would need to consider this as a different grant.

Do you mean a different grant as far as Nimbus is concerned or do you think it better to introduce different grant type in auth manager conf as well?

I think the easiest solution would be to still treat it as a token exchange for auth manager users and try to hide the complexity inside TokenExchangeFlow.java, which will execute current code (using TokenExchangeGrant) in normal cases, but fall back to custom token request in case subject token is not provided.

[adutra]

Do you mean a different grant as far as Nimbus is concerned or do you think it better to introduce different grant type in auth manager conf as well?

Whichever is easier for you. What I know for sure is that you won't be able to reuse TokenExchangeGrant for that, because it requires a subject token. So at the very least, you will need a new subclass of AuthorizationGrant.