4:25 a.m.
Hello,
I would like to present a usecase to you where we struggle a bit to see how
to implement it properly using keycloak... We are creating a solution where
we have some legacy components using X.509 and SAML to identify users in
our front-end applications. These applications now need to call some REST
services, and pass on the identity. Our front-end system would call the
REST service by presenting a token obtained via client credentials grant,
based on a signed JWT. This way, we can establish a circle of trust between
the front-end applications and the REST service. The REST service is
prepared to accept that the user is the one that our front-end applications
vow that he is.
Question is now : how do we transport this claim from the front-end to the
backend REST service? We have found an RFC in internet-draft status that
addresses this problem :
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-08. But since
this is not yet approved, I assume you do not support this yet.
One way of solving this problem is sending the identity of the user
out-of-band, in an HTTP header. This is however a bit of a pain, since then
we need to make the REST service aware that for certain users (our
frontends), the header needs to be interpreted. However, for other callers
(both machine and user), this HTTP header must not be interpreted (we do
not want a normal user adding this header and impersonating who he wants).
So we are moving the configuration of who may impersonate/delegate to the
business service... which is not great. Also, when we want to pass on the
token, we need to repeat/set the header as well, which means we could
potentially change the content... and the idea is that our front-end is
stating that this is the user, not that any intermediate service can alter
that.
So it would be nice to have this in the token, taking over a value set in
the initial signed JWT that we present to keycloak. Is this possible (I
cannot seem to find if you pass any of the token information on the user
session so that we could map this)? Furthermore, we would like to get some
control on that value... because we would like to be able to place
restrictions on who is impersonated (not every front-end has the same
audience, so we should be able to limit for which persons they are making
claims). Is this possible with the current extension points? If so, could
you give us a hint on which one(s) to use?
Thanks in advance.
Jef