10:59 p.m.
Hello,
Sorry for the long email...
A while ago I experimented with a Keycloak extension that would support
converting access_tokens,
retrieved via a Direct Access Grant, to a 307 redirect response with the
KEYCLOAK_IDENTITY,
KEYCLOAK_SESSION set to transparently authenticate a user.
The use case was to allow users to transparently authenticate via the login
pages of a legacy-app
(a portal, which I cannot change) without requiring users to use the
Keycloak login pages.
Next to the legacy application there are other newer apps which are fully
integrated with Keycloak.
Users who login to the legacy-app first should be able to access the other
applications without an
additional login step. The users of all applications are stored in Keycloak.
This and similar topics have come up quite often on this mailing list in
the past so I
wanted to discuss a potential solution, which uses Direct Access Grants, a
new hypothetical
“token2cookies” endpoint in Keycloak, as well as redirects.
It would work like this:
1) legacy-app sends a POST with client_credentials + user_credentials + a
generated nonce
to Keycloak to retrieve an access_token via Direct Access Grant.
The nonce is stored with the client session in Keycloak. The purpose of the
nonce is to prevent
attackers from issuing cookies for an access_token that was issued for a
different client or at a different time.
2) legacy-app extracts session_state from access_token, generates
"token2cookies" URL
and sends a 307 redirect to the users browser.
This URL contains the session_state, the nonce and the client_id to
redirect to as parameters.
E.g.:
Location:
https://sso.acme.local/auth/realms/transparent-login/protocol/openid-conn...
3) The browser follows the redirect.
The endpoint verifies the session_state by comparing the previously stored
nonce
given as URL parameter. If the session is verified & active the endpoint
performs some
checks with the user associated with the session (present, disabled, etc.).
If the user is valid then:
AuthenticationManager.createLoginCookie(session, realm, user, userSession,
uriInfo, clientConnection);
is called which generates and injects the KEYCLOAK_IDENTITY,
KEYCLOAK_SESSION cookies into the response,
which is then returned as a 307 redirect to the base_url configured for the
client referred to by the redirect_to_client_id parameter.
The redirect points to the
org.keycloak.services.resources.RealmsResource#getRedirect
endpoint which eventually redirects to the base path of the target
application.
This redirect URL looks like:
https://sso.acme.local/auth/realms/transparent-login/clients/legacy-app/r...
The user is now returned to the legacy-app. He can now transparently go to
other applications e.g.
new-app without having to login again since the Keycloak session cookies
are now present for sso.acme.local.
The new-app will transparently renew the sso session.
I think this approach could be applied in many legacy integration scenarios
where users are used to access
a centralized application which, for whatever reason, cannot be changed
that much or fronted with Keycloak.
Looking forward to hear your opinions about this approach.
Cheers,
Thomas