1 Password for All Services and Networks with Single Sign-on

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.

Single Sign-on (SSO) – the mechanism

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.

Difference to “Same user, same password”

“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.

Advantages of SSO

• The advantage for the users is clearly in the time savings: They only need to enter their password once and can then use all other services immediately.
• For the corporate IT, the advantages include improved security and lower administration efforts. Only communicating the login data once and a centralized authentication database contribute significantly to improving security. The administration efforts are also considerably lower in this case if a user’s login data need to be reset, for example. When SSO is used, the user data only need to be reset once centrally and not for each individual database where they are stored.

Disadvantages of SSO

• The availability of the service additionally depends on the availability of the single sign-on system.
• Theft of the access key allows attackers access to all systems.

Additional option: Single sign-out

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.

Single sign-on services need protocols

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:

Security Assertion Markup Language (SAML)

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.

Advantages of the use of SAML

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:

1. If the user wishes to have access to an external service on the Internet (e.g., to the project management software Redmine);
2. He is first redirected to the internal authentication service (identity provider – IdP). The external service does not require any type of access or connection to the internal authentication service for this. It is sufficient for the user’s browser to have access;
3. At the authentication service, the user’s browser then receives a session cookie, with which it can sign on to the originally required service: in this case, Redmine;
4. The user can subsequently use this session cookie to sign on to other internal and external services.

Shibboleth

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:

1. If a student from university A now wants to access services from university B (e.g., its MediaWiki).
2. He is first redirected to a discovery service of university B.
3. This discovery service now determines the authentication service via which the student must authenticate himself.
4. It then redirects the student to the service provider (SP).
5. This, in turn, redirects him to the authentication service (identity provider – IdP).
6. Following successful authentication
7. The student is now transparently signed on to the service.

OpenID

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

1. Wants to sign on to a web service (feedly) and
2. Is subsequently redirected directly to Google’s Open ID provider. The user then authenticates himself there and
3. Is subsequently returned to the web service again.

Kerberos

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:

1. If a user wants to have access to a service in the domain,
2. He must first have a ticket granting ticket issued to him by the authentication server of the key distribution center (KDC).
3. The user can then have a service ticket issued for each affiliated service on the ticket granting server in the domain.
4. The user can now use this service ticket to sign on to the services on the domain.

How UCS integrates the protocols

UCS already integrates different single sign-on solutions, to be more specific:

• Kerberos
• SAML

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).

Further information on Kerberos in UCS

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.

Further information on SAML in UCS

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).

SAML linked to Kerberos in UCS

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.

Basic Requirements for the Introduction of Single Sign-on

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:

• the selection of an SSO mechanism (for example: Kerberos or SAML);
• an authentication point;
• the capacity of the services which conduct authentication via the SSO mechanism. A whole range of centralized enterprise services (on-premises and off-premises) support single sign-on. To name but a few: Office 365, MediaWiki, OX, owncloud, Google Apps for Business, Redmine, WordPress, Salesforce, SAP NetWeaver, Slack, Moodle, DokuWiki, and MailChimp.

Once these requirements are satisfied, there is nothing standing in the way of a gradual introduction.

Conclusions

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.

Further articles we can recommend:

Univention: Single sign-on made easy for Ubuntu clients

How to Integrate SAML Single Sign-On in ownCloud App