8:31 a.m.
Hello,
I'm encountering an issue with the OAuth sequence that occurs because of a
unique combination of components.
We are deploying keycloak protected web applications into an OpenShift
environment. The web applications must be accessible through an Ozone
Widgets Framework (OWF) portal. These are immovable constraints. It's a
government system and therefore cannot be easily changed. I'd drop OWF if I
could.
The OWF portal is mapped to a client in Keycloak and is a protected
resource. OWF is a way to bring multiple applications into a single browser
window (via inline frames). Each application (mapped into an Iframe in OWF,
and an App in Openshift) is protected by keycloak. The applications are
each keycloak clients within the same realm as the OWF client.
When the OWF page loads, it first attempts to authenticate the user via
normal keycloak mechanisms. This authentication and authorization completes
successfully. However, once the OWF portal is loaded into the browser, it
begins opening the user's widgets concurrently. Each of the widgets is an
OpenShift application (specifically a wildfly application using the Keycloak
client adapter). As a consequence, each of the widgets needs to establish a
security context. While running thought the redirect sequence between the
app, keycloak, and back to the app, a cookie is exchanged. The cookie's
name is OAuth_Token_Request_State. The problem arises when there are
multiple apps attempting to establish their security context concurrently.
When this happens, the OAuth_Token_Request_State is overwritten. As a
result, all but one of the apps fail to establish the security context
because the cookie value does not match the OAuth state. As a result, most
of the widgets on the screen do not load. It's possible to reload the
widgets and the authentication process completes successfully, but forcing
users to reload is clearly a UX problem.
Is it possible to fix this by changing the name of this cookie to include a
unique string? If the cookie name is unique, it won't be overwritten. When
the user agent is redirected back to the client, it will include the
uniquely named cookie and the verification of the OAuth state will succeed.
The name of the cookie appears to be an implementation detail of OAuth 2.0,
not a SHALL. It seems like this could be changed and still comply with the
standard. I cloned the code and found where the cookie name is set. I can
make the modification and rebuild the adapter, but I wanted to be sure I
wasn't causing another problem. It seems pretty straightforward.
Again, I'd prefer to drop OWF from the architecture and not worry about
this, but that's not an option.
Thanks,
Von Belser