Portal and SAML IDP on two different servers with custom portal FQDN

This is work in progress - feedback and contributions are welcome :slight_smile:

Scenario

We have a distributed installation with two or more servers:

  • One server is a UCS Master or Backup and is used as SAML IdP. This server is publicly available via https://ucs-sso.example.org/.
  • A second UCS system serves a portal and is publicly available via https://portal.example.org/. The internal FQDN of this system is ucs42.example.org.

saml_01

Problem

When clicking “LOGIN” on https://portal.example.org/, the SAML-SSO-Login does not work, although https://ucs-sso.example.org/ is available. The browser then uses the fallback login without SAML SSO (https://portal.example.org/univention/login).

To find out if SAML is available, the browser tries to access /univention/saml. Because our portal server is named ucs42.example.org, it tells the browser to access https://ucs42.example.org/univention/saml. In our case, this won’t work, because this FQDN is not publicly available from the internet. Instead, we need to tell our portal server to use a different FQDN for this request.

Solution

  1. Change the UCR variable umc/saml/sp-server on the portal server to the FQDN that is publicly available:
ucr set umc/saml/sp-server="portal.example.org"
univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server.inst
  1. You should also set umc/saml/trusted/sp/* to avoid SAML ticket ping pong between a service on the portal server and the SAML IdP. Add on both servers:
ucr set umc/saml/trusted/sp/portal.example.org=portal.example.org

Additional information: If you use the UMC for LDAP operations (e.g. changing the password of a user) while being authenticated via SAML, your SAML ticket for the UMC is passed on to the LDAP server. The LDAP server only trusts tickets from services which are defined in umc/saml/trusted/sp/*. If the ticket is not trusted, the before mentioned ping pong can be observed, because to the UMC the ticket looks valid and it just tries to pass it through again.

Now, the browser should try to access https://portal.example.org/univention/saml. This should work now and redirect the browser to the login form on https://ucs-sso.example.org/simplesamlphp/...

Please note: For this article, we assume that:

  • a Reverse Proxy or NAT-solution is in place and configured properly
  • all SSL/TLS certificates are valid and in place (especially a certificate for portal.example.org)
  • internal and external domain are the same (example.org)

See also:

This topic was automatically closed after 60 minutes. New replies are no longer allowed.