We are using Keycloak Java adapter 4.5.0 in combination with EAP7.1. When we configure our keycloak.json we have for auth-server-url the url https://authentication.country.com/op/v1/auth. So far so good.
When we navigate to our application, we are forwarded to https://authentication.country.com/op/v1/auth/realms/KeycloakOIDCRealm/protocol/openid-connect/auth?response_type=code&client_id=fac9d161-d27d-493d-uze896zed78&redirect_uri=.....
This is not good, since we use our own identity provider. Removing the realms/KeycloakOIDCRealm/protocol/openid-connect/ part of the url, forwards it correctly to the identity provider. So the Keycloak adapter adds it by default, assuming we will always use Keycloak as an identity provider. Before we were using SAML and didn't had this issue.
How can we configure the keycloak.json for the adapter to leave out the addition of realms/KeycloakOIDCRealm/protocol/openid-connect/?
I contacted the support of Keycloak and they answered the following way:
Hello Fabrizio,
Indeed, string templates like "/realms/{realm-name}/protocol/openid-connect/auth" are hardcoded into Keycloak adapters.
Luckily, there seems to be a workaround. In Keycloak, there is a mechanism for multitenancy; it requires you to supply a resolver that would return a KeycloakDeployment instance based on request parameters. One of its bonus features is that you can completely redefine the behavior of KeycloakDeployment. For example, you can extend org.keycloak.adapters.KeycloakDeployment and override its resolveUrls() method, to make the URLs point to your 3rd party IDP.
This approach doesn't require any modifications to the adapter code, so I'd recommend you start with it. However, I wouldn't rule out further incompatibilities that could pop up.
Another option is installing an intermediary Keycloak (server), configuring brokering to 3rd party IDP and pointing your adapter to Keycloak. Though sounds like an overkill, it's a bulletproof solution that should work 100% (and it also has some other benefits).
There are of course other options like using 3rd party IDP's equivalent for Keycloak adapter, or using other OpenID Connect Java libraries, or even proxy-level adapters like apache-mod_auth_openidc or Keycloak Gatekeeper. But I understand that this would probably require code rewrite, so you should consider these options only as the last resort.
As for SAML and why it used to work: Keycloak adapter uses standard SAML SP metadata for configuration, which defines URLs strictly and unambiguously; here we need to admit that SAML is more mature and feature-complete.
OIDC, on the contrary, allows for some freedom. At the moment, Keycloak OIDC adapter doesn't use any standard metadata, but rather generates URLs using hardcoded templates. I think Keycloak adapter could use OIDC's rough equivalent for SAML metadata, namely "well-known" URLs.
In theory, Keycloak OIDC adapter could ingest this metadata instead of hardcoding URL templates. To me, this could be a valuable addition, but surprisingly I don't see any related JIRA issue. Maybe Keycloak developers could give us some feedback.
In the end we did a fallback to the SAML adapter without any configuration or Keycloak Jboss server (01/2019). It should be checked yearly or something to see if Keycloak will do the same for OpenID.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With