Univention Bugzilla – Bug 55969
Keycloak uses internal backend domain instead of configured frontend domain
Last modified: 2024-05-06 00:04:45 CEST
Customer has set up Keycloak using an external domain while $domainname is an internal domain, see #55967. Related to that is that (when the setup has been tweaked to work) the customer connects via external domain and HAproxy, gets redirected to ucs-sso-ng.$domainname instead of $keycloak_fqdn and after logging in, the redirect is being done to e.g. portal.$internal_domain (=ucr get domainname) instead of external portal.$keycloak_fqdn. This is most likely related to the other bugs dealing with internal/external/custom domain and/or related to a missing appropriate Apache config (see #55635 as well). In the end the customer is very unhappy that the internal domain is being exposed to the Internet.
Changing the FQDN for Keycloak is not implemented yet, retagging this bug as development internal.
In Keycloak 21.0.1-ucs2 using custom domains and change the FQDN from ucs-sso-ng to e.g. sso is supported/possible. However when changing the FQDN in the Keycloak settings UI it seems that the following two UCR variables are not changed accordingly: - saml/idp/entityID - umc/saml/idp-server In my test setup those were still pointing to the old FQDN of ucs-sso-ng which in turn led to an error when trying to log in. After changing those UCRVs to the new FQDN everything seemed to work.
(In reply to Ingo Jürgensmann from comment #2) > In Keycloak 21.0.1-ucs2 using custom domains and change the FQDN from > ucs-sso-ng to e.g. sso is supported/possible. > > However when changing the FQDN in the Keycloak settings UI it seems that the > following two UCR variables are not changed accordingly: > > - saml/idp/entityID > - umc/saml/idp-server > > In my test setup those were still pointing to the old FQDN of ucs-sso-ng > which in turn led to an error when trying to log in. > After changing those UCRVs to the new FQDN everything seemed to work. umc/saml/idp-server - is covered by the documentation http://docs.software-univention.de/keycloak-app/latest/use-cases.html#configuration-of-umc-as-service-provider saml/idp/entityID - not sure about that, seems to be simplesamlPHP related, with keycloak the entityID for the saml IDP is automatically generated from the keycloak/server/sso/fqdn, see the realm settings in the admin console so i would RESOLVE INVALID, OK?
In case of umc/saml/idp-server I would expect as a customer that this UCRV is being changed, when I change the FQDN in the Keycloak settings UI. Yes, the documentation mentions changing this, but I don't think that many customers will follow this instruction. When they change the setting the expectation will be that the setting will be changed as well. The documentation might be interpreted as a "when I first install Keycloak"-thingie. I agree that it is difficult to change the UCRV across all systems. Maybe it is an idea to present a popup to the admin user as a reminder to change it manually by pointing directly to the documentation part. If we leave it as it is now, I fear many support requests of "broken installations". Regarding saml/idp/entityID: yes, I'm unsure about this as well being related solely to simplesamlphp. So, I'm basically fine with ignoring that part of the report, if that's true with simplesamlphp. However, speaking of keycloak/server/sso/fqdn there is also ucs/server/sso/fqdn for which ucr info ucs/server/sso/fqdn shows: Defines the fqdn of the identity provider of this UCS domain. Categories: management This as well might be misleading or confusing. Maybe it is an idea to check and clearify all SAML/SSO related UCRVs whether they are simplesamlphp or Keycloak related and stating this within the UCRV description. Maybe marking all simplesamlphp related UCRVs as "deprecated" or maybe the category can be used for this as well by introducing categories for "SimpleSamlPHP" and "Keycloak"? I do think we have an issue here for sure, so I'm not quite happy about marking this as "RESOLVE INVALID", but for sure we can discuss how a proper fix can look like. Maybe the solution is a different one like a good and well documentated migration path or something, but currently I expect lots of confused customers when they look at "ucr search saml" and we should try to avoid confused customers. :-)
> umc/saml/idp-server Not quite sure as keycloak is not yet the default IDP in UCS. Needs to be discussed. > UCR variables Yes, we should better document the new keycloak settings and the relation to the old variables. > documentated migration path we are working on that
If I understand it correctly, this is not a bug now, and is only open because: If we leave it as it is now, I fear many support requests of "broken installations". But since then, we have improved the documentation (including a migration guide), we have not seen many problems. I will close this bug. Please reopen, if my impression is wrong. https://docs.software-univention.de/keycloak-app/latest/use-cases.html#single-sign-on-through-external-public-domain-name