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

[Grandjean]

This is work in progress - feedback and contributions are welcome

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.

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

2. 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:

Problem: Changing ucs-sso login from master.schein.sun to portal.schein.sun

Problem: How can I make the registration at the UMC for SSO available on an alternate name. E.g changing ucs-sso login on the UMC from master.schein.sun to portal.schein.sun This was tested for a singlemaster environment Solution: Assuming that a certificate for portal.schein.sun already exists… This way: (Can also be the alternate name in the UCS certificate) … and this is stored under /etc/univention/ssl/portal.schein.sun, these two further steps still necessary Or this way: Or …

Q&A: How does the SAML workflow look like

Question: How does the saml workflow looks like, and which certificates are used. Answer: We want to have a look into the service provider initiated login. This can be separated in 3 steps The SP (servcie provider) is the UMC in this case. Memory hook: SP is the one, where you can do much more then login Step 1. The SP (e.g. UMC) contacts the IdP (simpleSAMLphp) with a SAML message: “Please login in this $user for me” This message is signed with http://$SP_FQDN/univention/saml/metadata Y…

Reconfigure UCS Single Sign On

Reconfigure UCS Single Sign On By default, UCS Single Sign On uses a shared DNS record to provide a failover for the Login. The SAML Identity Provider is available at ucs-sso.domain.name, where domain.name is chosen during UCS installation. Administrators often want to configure Single Sign On to be available from the internet. As the UCS domain name is often chosen for an intranet scenario, service configuration has to be adapted to match the target domain- and hostnames. Involved services a…