Single Sign-On for UCS 4.1

In order to be able to guarantee the seamless integration of apps in the identity management system provided by UCS even more proficiently, we have now implemented a single sign-on for UCS function in Version 4.1. of Univention Corporate Server. Single sign-on allows a user who has authenticated himself once on an identity provider to use a wide variety of other services without the need to sign on to each of these additional services individually.

There are a number of different web technologies available for single sign-on functions, with the most widely known being Security Assertion Markup Language, or SAML for short. Other popular technologies include Shiboleth, which is based on SAML, OAuth, which is often used for Facebook and Twitter among others, and OpenID Connect, which expands on OAuth 2.0.

UCS has already been offering a SAML Identity Provider app for download in the Univention App Center for more than two years which makes it possible to connect Google Apps for Work and UCS very easily, for example. The popularity of SAML in the enterprise sector, the high degree of security and the positive experiences that we have been able to gather with SAML in recent years were the impetus for taking the decision to implement SAML as the first single sign-on technology in UCS 4.1. Additional technologies may be added in the future.

 

SAML single sign-on

SAML is an XML-based protocol allowing the exchange of authentication information and which thus permits single sign-on. SAML offers multiple “bindings”, which make it possible to bind to additional protocols such as SOAP and HTTP. This in turn makes it possible to use SAML in desktop applications or via web services. A typical SAML environment contains at least one identity provider, which authenticates the user, and one or more service providers, which provide the actual services. These two components exchange signed XML data via public/private key encryption processes.

When the user opens the corresponding service in his browser to perform a single sign-on, the service provider identifies whether the user is already signed on and otherwise forwards the user on to the corresponding identity provider – in UCS the DC master – with a SAML request. This provides a login mask and, following successful authentication, returns the user to the service provider together with a signed SAML assertion containing information about the user. The service provider can then verify the message’s signature and authorise the user’s access to its actual service, e.g., the Univention Management Console.

UCS as the SAML identity provider

If UCS is to function as the SAML identity provider in future, it must of course be ensured that the availability of the services in case of a server failure is guaranteed and that the server is optimally protected against attack.

To this end, the simplesamlphp-based SAML identity provider is installed on every DC master and DC backup system as standard. Each SAML identity provider is then entered in a DNS entry, e.g., ucs-sso.example.com; the corresponding SSL certificates are replicated onto the respective computer. If one of the servers fails, a browser will typically attempt to establish a connection to the next IP address. This naturally requires replication of the simplesamlphp sessions between the individual identity provider copies. To this end, simplesamlphp offers the possibility of replicating session data onto multiple servers by means of memcached. As there is no guarantee that the DC backup systems in customer environments are insular as standard, defence mechanisms against possible man-in-the-middle attacks are required. As memcached is an unencrypted protocol, an SSL tunnel which uses stunnel to encapsulate memcached, specific firewall policies and UNIX sockets ensure that the memcached service can only be addressed from outside via an encrypted and authenticated connection.

In addition, the identity provider possesses the private key with which the SAML messages are signed. For this to be protected effectively, simplesamlphp runs with the rights of a user created explicitly for SAML and has very limited LDAP read access rights. This prevents, for example, vulnerable web scripts supplied by apps from being exploited to access the private key, session data or password of the LDAP user employed.

UMC as the SAML service provider

Of course, the implementation of the SAML service provider also has consequences for the Univention Management Console (UMC). As the authentication is delegated to the identity provider, the service is no longer privy to the user password. The UMC server and the UMC web server are two mutually independent services. The UMC server requires authentication and does not understand HTTP, rendering it unable to establish a SAML connection. The SAML service provider is part of the UMC web server, which as yet has only supplied the password to the UMC server. Some UMC modules also require the password to be able to establish connections to the LDAP, use the domain-wide UMC module or start a class project in UCS@school, for example. As a solution for this, UCS 4.1 now uses a PAM module called pam-saml for the authentication on the UMC server and the SASL plug-in cy2saml for the LDAP access. These two modules enable authentication based on the signed SAML message. For all further scenarios in which a password is required, Univention Management Console will be unable to avoid renewed password prompts for the time being.

Changes also apply to the integration in the UMC user interface: As SAML messages are subject to time restrictions and they are used for authentication to LDAP, they need to be renewed behind the scenes. SAML offers a passive authentication method for verifying whether a session is still valid, whereby the browser is invisibly forwarded to the identity provider, which either issues a new SAML message or reports a status error and then returns it to the service provider. However, UMC can only use this procedure subject to certain limitations as all open modules and events are lost when a browser session is forwarded. For this reason, a combination of Ajax and Iframe requests is triggered behind the scenes.

 

Outlook

Timed perfectly to coincide with UCS 4.1, Netknights is set to publish an integration of the app in SAML with the solution privacyIDEA in order to permit multiple-factor authentication in UCS. We firmly believe that more and more Univention apps will use the SAML infrastructure in future in order to offer users added security and convenience and to simplify interaction with UCS even further.