The increasing number of programs that employees in companies have to deal with day in, day out makes their work not only easier but also increasingly more complex. In addition, a higher number of applications also translates to an increasing security risk for the data in the corporate network.
We would now like to take this opportunity to explain how you can make work easier for your employees with single sign-on technology and keep your data safer from external attacks at the same time.
What is SSO?
Single sign-on (SSO) in companies means for users that they only need to sign on (authenticate themselves) once and can then use a whole range of different programs, services, and offerings without having to sign on personally each time.
That means, for example, that 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 entity (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, with said package then functioning 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), where the 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.
Single sign-out as an additional option
In addition to the single sign-on, there is also a single sign-out concept. 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 and protocols
For single sign-on services to function, they must be able to access certain protocols, of which there are a whole range.
Below we would like to introduce you to some of those most commonly employed.
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
- If the user wishes to have access to an external service on the Internet;
- 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;
- 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;
- The user can subsequently use this session cookie to sign on to other internal and external services.
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:
- If a student from university A now wants to access services from university B (e.g., its MediaWiki).
- He is first redirected to a discovery service of university B.
- This discovery service now determines the authentication service via which the student must authenticate himself.
- It then redirects the student to the service provider (SP).
- This, in turn, redirects him to the authentication service (identity provider – IdP).
- Following successful authentication
- the student is now transparently signed on to the service.
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
- wants to sign on to a web service (feedly) and
- is subsequently redirected directly to Google’s Open ID provider. The user then authenticates himself there
- and is subsequently returned to the web service again.
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.
- If a user wants to have access to a service in the domain,
- he must first have a ticket granting ticket issued to him by the authentication server of the key distribution center (KDC).
- The user can then have a service ticket issued for each affiliated service on the ticket granting server in the domain.
- The user can now use this service ticket to sign on to the services on the domain.
Integration of the protocols in UCS
UCS already integrates different single sign-on solutions, to be more specific:
Shibboleth and OpenID have not yet been integrated, as our users have yet to inform us of any scenarios where they would require them.
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
SAML 2.0 is also available for UCS. It can be used for both signing on to the UMC and also via the corresponding Univention apps for integration with Office 365 or Google Apps for Work.
You can test it for the UMC on your server if you select the “Single Sign-ON” link at the top in your login mask.
Of course, it is also possible to mount additional web services to the SAML identity provider. Further information on this will be available in my next article, which will be published next week.
Basic Requirements for the Implementation 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);
- 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.
The single sign-on concept has been a hot topic in many organizations for some time now. In the past, the prevailing solution was native Windows applications, whereas now 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 IT departments wanting to introduce single sign-on for security reasons and to reduce efforts efficiently.
We hope that this article has provided you with a good overview of the options available with single sign-on. Should you have any questions, please do not hesitate to contact us. And don’t forget to check back in next week, when I will be reporting on SAML in more detail.