More about Identity and Service Providers, SAML, OpenID Connect and other technical Requirements for User Authentication
Single sign-on (SSO) is an authentication process which allows users to log in to many different applications with only one set of credentials. They enter their username and password once and are automatically granted access to all programs and services which have been made available to them. After they have authenticated successfully for the first time, the SSO mechanism takes over and handles the authentication to all the other services.
In this article, I’m going to explain the technical background first. After that I’ll go into more detail concerning the two authentication standards OpenID Connect and SAML (Security Assertion Markup Language) – both methods are available for Univention Corporate Server (UCS). I’m also going to show the SSO authentication process for both standards, followed by some troubleshooting tips. For some of the technical terms I use in this article I’ve added an explanation in the small SSO glossary.
What is Single-Sign-on?
Every time a user logs in with a username and the associated password, he proves to the underlying system that he really is who he claims to be. Sometimes a second factor is involved, such as a YubiKey or an text message – this is called two-factor authentication (2FA). Regardless of how the login process actually happens, after the authentication was successful, the user has access to the service to which he or she has just logged in. The service opens its own session for this purpose, and further communication takes place via this session.
So how does this process work if the Identity Provider and the Service Provider are running on different systems, especially if the Service Provider should never receive the user’s password? For SSO to work, there has to be trust between the services and the single point of authentication. This means that during the login process some kind of proof of successful login must be passed to the external service. For example, if a user logs in to a service like the UCS portal, the portal has to communicate with the connected external services. This requires a framework or a protocol which has to be configured accordingly to exchange messages securely.
There are various SSO mechanisms and protocols. In this article, I’m focusing on web single sign-on: users log in to the web-based UCS portal once and have access to apps and services of the domain afterwards.
Let’s first take a look at how single sign-on with OpenID Connect and SAML works.
Single Sign-on with OpenID Connect
Before users log in for the first time, admins have to establish trust between the Identity Provider (here: UCS) and the other services. OpenID Connect uses a shared secret for this: a very long password. Administrators must therefore store the same shared secret in UCS and in the external service’s configuration. OpenID Connect uses several URLs as endpoints for exchanging messages and for the different actions. For example, those URLs are used for logging in, retrieving information about the user, and logging out.
When using OIDC, admins should take into account that all servers offering services to users via SSO should have a direct HTTPS connection to the Identity Provider, in our case UCS. It therefore makes sense to plan the firewall rules and the forwarding accordingly.
In the following example, the UCS IdP has the hostname ucs-sso.mydomain.intranet. Please adjust this to your own domain if necessary. The URL https://ucs-sso.mydomain.intranet/.well-known/openid-configuration offers all metadata needed for configuration and for connecting to other services. First, the issuer is defined, i.e. the issuing entity (here: the UCS SSO OpenID Connect provider). Next, you can see various endpoints for exchanging messages. The first one is authorization_endpoint, this is where the actual authentication is expected. The userinfo_endpoint is where the user data can be accessed.
Single Sign-on with SAML
In SAML, trust between Identity Providers and services is ensured by exchanging certificates. Like with web servers, there are two certificates (public and private). Administrators have to save the UCS IdP’s public certificate when setting up the service so that the service users log in to can verify the authentication of the UCS IdP.
Let’s take a look at the SAML endpoints. Just like in OpenID Connect, this works via HTTPS URLs where the messages are sent to. However, there is one important difference: SAML doesn’t require a direct connection between the Service Provider and the Identity Provider. Only the user’s web browser must be able to reach both sites.
The SAML endpoints and metadata can also be accessed by a URL (https://ucs-sso.mydomain.intranet/simplesamlphp/saml2/idp/metadaten.php). At the top you’ll see the entityID – this is like the issuer in OpenID Connect: it identifies the SAML IdP for the respective services. At the end of the rather complex XML file you can see the endpoints for the exchange of messages.
How does SSO work with OpenID Connect and with SAML?
So, how exactly does the login to a service work? Let’s look at both methods, OpenID Connect and SAML. It’s vital to understand all the single steps, especially if things don’t work as expected and you need to identify problems and do some debugging.
Let’s start with OpenID Connect: On the left side you can see the end user or user agent, i.e. the web browser. The middle column shows the service to which the user logs in, for example Kopano Meet. The right side in the diagram shows the Identity Provider, i.e. UCS.
1. A user opens a website in his or her browser. After a click on the login button various redirections take place.
2. The first redirection goes back to the browser.
3. Next, a request gets redirected to the UCS IdP. Among other things, it transmits the name of the service to which the user wants to log in, so that the user can be redirected to the correct place after logging in.
4. The IdP sends a login page to the user, who is unknown so far, i.e. has no session yet.
5. The user enters his or her credentials, for example username and password.
6. The Identity Provider asks the user again: Service XYZ has requested data from you (e.g. email address, phone number, etc.), and the user can agree to that. In UCS we usually skip this step, because the administrator has already agreed that the data should be transferred just by setting up the service for the users.
7. The user confirms the request.
8. After successfully logging in, the web browser receives an authorization code, a so-called token.
9. This is redirected via HTTP request back to the service the user wants to log in to.
10. Now comes a special feature of OpenID Connect: The service contacts UCS again: “A user has just sent a code, please provide further information.” This can be the email address, a group membership, phone number, or something else.
11. The Identity Provider submits the requested information.
12. Only when this has been successful, the service opens a session, the user can log in and use the service.
Let’s take a look at the SAML work flow:
1. The start looks similar: The web browser opens the login page of the service or of the UCS portal, and the user clicks the login button.
2. The browser receives an authentication redirection request.
3. Everything gets transferred to the UCS single sign-on site.
4. The user gets asked to enter his or her credentials.
5. The user logs in, for example with username and password.
6. Next, you’ll see a special feature in SAML: To verify the login, the user receives a SAML assertion, an XML file which has been signed with the IdP’s certificate.
7. The user or rather the web browser sends this to the service.
8. The service finally decides whether the login is valid or not. Only if the message is signed with the correct private key of the UCS certificate, the service authenticates the login and grants access to the user.
Please keep in mind that the configuration of the services can differ. Some services make it pretty easy to enter the meta data, others have a more complex configuration. Therefore, it’s good to understand the general procedure and the respective work flows.