Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
- a.m.m.

Single Sign-on (SSO) is a process where your users authenticate themselves only once against the system and that’s it. They can then use a whole range of different programs, services, and cloud offerings without having to sign on personally each time again. Your users will love it. No more hassle with inventing and remembering numerous different passwords.
But single sign-on is not only about user friendliness. Another important aspect is, of course, the security of your data. When you’ve got a complex IT infrastructure, which includes mobile apps and devices and cloud services, the security risk increases a lot.
This is why I would like to explain here how you can catch two birds with one stone: Making work easier for your employees with single sign-on technology while keeping your data safer from external attacks at the same time.
A user logs on to a desktop computer in the domain and then has direct access to file and print servers. The user only needs to authenticate himself once physically for the server, e.g., by entering a password or other factors, and the SSO mechanism then takes over the authentication for other services transparently in the background.
The SSO mechanism can be implemented in a number of different ways. In general, the user receives a data package referred to as a ticket, token, or cookie once he has authenticated himself successfully. This said package then functions as an access key for the authentication for other services. The SSO mechanism then saves the access key and ensures that the key is presented at the right time.
“Single sign-on” must not be confused with “same user, same password” (SUSP). With SUSP users also employ the same login data for a range of different services. However, these login data can either be synchronized or the service can pass on the authentication. Nevertheless, the user is still required to sign on physically each time: i.e., re-enter the login data.
Did you know that there is also a single sign-out option in addition to the single sign-on? This is where a user signs out of service A and is automatically also signed out of all the other services he has used during the same session.
The single sign-out is generally realized using a key expiry date. The user’s session then expires at some point. This does not pose a problem in the majority of cases. However, it can take a long time depending on the configuration, even though the user may not have needed the services any more for a considerable period of time. If that should prove a problem, the standard single sign-on protocols generally also offer a single sign-out solution.
For single sign-on services to function, they must be able to access certain protocols, of which there are a whole range.
Some of those most commonly employed SSO protocols are:
SAML is a web-based single sign-on protocol. The user’s browser receives an encrypted session cookie via SAML, which contains an expiry date and with which the user can authenticate himself for services transparently. These services can be on the internal network or on the cloud or even online.
SAML supports a wide range of cloud services. Another advantage is that the authentication service can be situated internally in the network and does not need to be accessible from the public network.
The following example shows a simplified authentication via
SAML:
Shibboleth is an expansion of the SAML standard. It additionally includes the option of allowing a single sign-on beyond the borders of security domains. In this scenario, the exchange of certificates creates a so-called ‘trust’ between the entities involved.
In the following simplified example, two universities (A and B) each have their own security domain. However, they are both also in a trust (federation) together:
OpenID in contrast is a decentralized, web-based single sign-on system, which works with an URL and without a password as the login data. To this end, the user must have authenticated himself for an Open ID provider in advance so as to be able to use this to sign on to supported websites.
In the following simple example, the user
Kerberos in turn is a network-based single sign-on protocol. A client authenticates itself on the Kerberos server and receives a ticket (TGT). This ticket can then be used to call up additional tickets for different services.
Example:
UCS already integrates different single sign-on solutions, to be more specific:
The development is currently working on an OpenID Connect integration. An exact release date is not yet known. A Shibboleth integration – i.e. the participation in an IdP Federation – is easily possible. An example would be the participation in the Authentication and Authorization Infrastructure (AAI) of the German Research Network (DFN).
Kerberos services are automatically preconfigured and used by a whole host of services in the background to verify the password. If Active Directory services based on Samba 4 are used, true SSO occurs between the workstations in the domain and, for example, the file and print services.
Kerberos is also preconfigured for access via SSH or to the LDAP directory service. Single sign-on can be activated for additional services such as access to protected websites in just a few steps.
The SAML 2.0 is supported and out-of-the-box configured. It can be used for signing on to the UMC, the corresponding Univention Apps (e.g. Office 365, Google Apps for Work) and all third-party services, which support SAML.
The UCS server functions in this case as the authentication point (SAML identity provider) and the web interface is the service (SAML service provider).
When users log in to UCS on their Windows or Linux PC, laptop, or mobile end device, they have immediate access to web applications such as Office 365, ownCloud or Nextcloud. There is no need to sign on again. This is made possible by the linking of the security assertion markup language (SAML) with the Kerberos authentication introduced. This is practical for users and administrators. For example, there is no need to sign on to the Univention Management Console (UMC) again.
In this section, I would like to go into more detail about the basic requirements for the introduction of single sign-on.
The following basic requirements need to be taken into consideration:
Once these requirements are satisfied, there is nothing standing in the way of a gradual introduction.
The single sign-on concept has been a hot topic in many organizations for some time now. In the past, the prevailing solution were native Windows applications, whereas today there is an increasing tendency towards web applications. Services and offerings on the cloud in particular are becoming more and more popular in this respect. However, in the case of web services in particular, it is common for us still not to perceive the enormous psychological strain in our customers’ employees. Browser password managers are regularly used here and appear to be a comfortable solution for the employees. The main impetus behind single sign-on is that IT departments want to introduce single sign-on for security reasons and reduce efforts efficiently in parallel.
I hope I was able to provide you with a good insight into the options available with single sign-on. Should you have any questions, please do not hesitate to comment below or contact us.
Univention: Single sign-on made easy for Ubuntu clients
How to Integrate SAML Single Sign-On in ownCloud App
Michel joined Univention in January 2014, initially working in the Professional Services team as an education project manager. Here he was involved in various projects in the school administration environment. Currently, as Product Manager Education, he is responsible for the entire education sector at Univention and is working on sustainably advancing digital education in Germany. When he finds time next to family and work, his personal interests are running, football and cooking.