如何更改由 Keycloak OpenID Connect Java 适配器生成的身份验证 Url？
How to change authentication Url generated by Keycloak OpenID Connect Java adapter?
我们将 Keycloak Java 适配器 4.5.0 与 EAP7.1 结合使用。当我们配置 keycloak.json 时，我们有 auth-server-url url https://authentication.country.com/op/v1/auth。到目前为止一切顺利。
当我们导航到我们的应用程序时，我们被转发到 https://authentication.country.com/op/v1/auth/realms/KeycloakOIDCRealm/protocol/openid-connect/auth?response_type=code&client_id=fac9d161-d27d-493d-uze896zed78&redirect_uri=....。
这不好，因为我们使用自己的身份提供者。删除 url 的 realms/KeycloakOIDCRealm/protocol/openid-connect/ 部分，将其正确转发给身份提供者。所以 Keycloak 适配器默认添加它，假设我们将始终使用 Keycloak 作为身份提供者。在我们使用 SAML 之前没有这个问题。
我们如何配置适配器的 keycloak.json 以省去添加 realms/KeycloakOIDCRealm/protocol/openid-connect/？
我联系了 Keycloak 的支持，他们的回答如下：
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.
最后，我们在没有任何配置或 Keycloak Jboss 服务器的情况下回退到 SAML 适配器 (01/2019)。应该每年检查一次，看看 Keycloak 是否会对 OpenID 做同样的事情。
我们将 Keycloak Java 适配器 4.5.0 与 EAP7.1 结合使用。当我们配置 keycloak.json 时，我们有 auth-server-url url https://authentication.country.com/op/v1/auth。到目前为止一切顺利。
当我们导航到我们的应用程序时，我们被转发到 https://authentication.country.com/op/v1/auth/realms/KeycloakOIDCRealm/protocol/openid-connect/auth?response_type=code&client_id=fac9d161-d27d-493d-uze896zed78&redirect_uri=....。
这不好，因为我们使用自己的身份提供者。删除 url 的 realms/KeycloakOIDCRealm/protocol/openid-connect/ 部分，将其正确转发给身份提供者。所以 Keycloak 适配器默认添加它，假设我们将始终使用 Keycloak 作为身份提供者。在我们使用 SAML 之前没有这个问题。
我们如何配置适配器的 keycloak.json 以省去添加 realms/KeycloakOIDCRealm/protocol/openid-connect/？
我联系了 Keycloak 的支持，他们的回答如下：
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.
最后，我们在没有任何配置或 Keycloak Jboss 服务器的情况下回退到 SAML 适配器 (01/2019)。应该每年检查一次，看看 Keycloak 是否会对 OpenID 做同样的事情。