Schaubild Übersicht SAML

Web-based work has been a widespread phenomenon in many industries for a long time already and is increasingly become standard practice thanks to the recent trend of cloud computing. This all sounds great to begin with, as you also have access to web-based programs from outside of the company and are thus able to work from practically wherever you want, whenever you want. However, the direct consequence of this flexibility is that each user has to remember more and more login data for the individual programs for security reasons. Added to this is also the time and effort required every day for logging in and out of each program, depending on how many programs you work with in parallel.

Luckily, this is where SAML – security assertion markup language – comes into its own. SAML is a secure, XML-based data format for the exchange of authentication and authorization information so as not to put a company’s data security at risk despite web-based working. At the same time, it also offers each and every user an optimal level of comfort.

What exactly is SAML?

SAML offers a web-based single sign-on for access to numerous, autonomous services without the need to re-enter login data every time. The SSO mechanism takes over the authentication transparently in the background at the same time. To this end, an encrypted session cookie is used in SAML. The user is provided with this session cookie, which is furnished with an expiry date, in the browser of an authentication service (identity provider – IdP). The user can then use all the connected services in the browser (service provider – SP).

SAML components

SAML is made up of the following elements:

Principal

The principal is the user. It must authenticate itself via the browser’s user agent.

Identity provider – IdP

The identity provider is the authentication service. It provides a login mask for the user and then forwards the browser on to the service provider.

Artifacts

* SingleSignOnService link
This URL is used to sign on to the identity provider. The identity provider offers a login mask for authentication of users as a rule here. The method is not specified more precisely. A user name and password or another form of authentication including multi-factor authentication may also be required. This link must be entered for all connected services.

* SingleLogoutService link
This URL is used to log out of the identity provider. If a user logs out of a service, he should be forwarded on to this endpoint of the identity provider so that it may also log the user out. This link can be entered for all connected services.

* Public certificate
The identity provider offers a public certificate. This is used for signing thesamlp:authnRequest from the service providers. This certificate must be made available to all connected services.

* Metadata file
An XML file, which is mostly made available by the identity provider under a special URL. This file contains the artifacts listed above (SingleSignOnService link, SingleLogoutService link, public certificate). This file can be made available to all connected services.

Service provider – SP

The service provider offers services which require authentication. However, it does not take care of this authentication itself, but rather forwards it on transparently to the identity provider.

Artifacts

Speaking of the service provider, there are the following artifacts:

* AssertionConsumerService link
This URL specifies the place to which the user should be returned once he has authenticated himself. This link must be entered on the identity provider.

* SingleLogoutService link
This URL is used to log out of additional services once a user has logged out of one service. That means that the identity provider sends a logout request to service A as soon as the user logs out of service B. The prerequisite for this is that this SingleLogoutService link has been entered on the identity provider for service A in advance.

Komponenten SAML

Connection of services via SAML

Services are connected via the exchanging of the artifacts described above between the identity provider and the service. Following this exchange, the authentication process can be conducted by calling up a resource belonging to a connected service. To this end, an XML syntax [1] defines so-called SAML AuthnRequests, SAML Assertions, and SAML Responses, which can be generated by the components during authentication and exchanged.

User management

Many services offer the option of creating a user directly the first time you log in. This process is referred to as ‘just-in-time provisioning’. If a service does not support this function, the users need to be created manually first of all, or another means of provisioning is employed. UCS offers this for Office 365 and Google Apps for Work. When user characteristics are being edited, SAML attributes or the provisioning via other interfaces is practical. It is also possible to combine the two.

Similar questions are posed when deleting users. Some services offer the option of deleting them once they have been inactive for a while. The use of another interface would be another possibility for deleting users. This is also possible in UCS for Office 365 and Google Apps for Work.

Authentication via SAML

The following steps illustrate an example of authentication via SAML:

  1. If the user wishes to gain access to a resource of a service – be it external or internal – he has to send a GET request to the service. In this example, the login URL wiki.univent.intern/login.
  2. He then receives a redirect from the service to the SingleSignOnService link of the identity provider. This redirect includes the samlp:authnRequest to be signed by the identity provider.
  3. The user’s browser then calls up the identity provider’s SingleSignOnService link and submits the samlp:authnRequest.
  4. The user then has to authenticate himself and receives a
  5. samlp:response in the form of an XHTML form. This XHTML form contains among other elements the AssertionConsumerService link, which the user agent of the browser can use to send a
  6. POST request to the service provider of the service.
  7. The service provider then creates a security context and
  8. redirects the user to the original login URL as well as, as a security context exists, also to additional resources of the service.

Prozess SAML Schaubild

As all the steps are performed via the user agent of the browser, it is also clear that no external service requires direct access or a connection to the internal authentication service. It is sufficient for the user’s browser to have access. Apart from that, an orderly configuration of the DNS is also important.

Attribute-based authorization

In addition to the authentication, attribute-based authorization is also configurable. In this respect, the XML syntax includes possibilities for exchanging attributes between the identity provider and service provider. The service provider can then employ these attributes to make decisions about accesses to resources in detail.

Advantages

  • Single sign-on for all users
  • Many services support SAML natively or via plugins; especially also a variety of cloud services
  • Administration savings. Only one database needs to be administrated in account administration.
  • Improved security, as:
    • only one internal user database needs to be protected. This can also only be accessed internally on the network and does not need to be accessible from the outside (Internet).
    • Passwords are no longer required in other services.

Disadvantages

  • The availability of individual services depends on the availability of the identity provider.
  • Theft of the session cookie allows attackers access to all services.

Integration in UCS

SAML has already been integrated in UCS since UCS 4.1. The login mask can be found at https://ucs-sso.domainname/univention-management-console/saml/

The metadata can be found respectively at https://ucs-sso.domainname/simplesamlphp/saml2/idp/metadata.php

The UCS manual describes how services are added.

There are extra connectors available for the provisioning of Office 365 and Google Apps for Work, which create, modify, and delete users. As such, UCS is now offering even deeper integration of the services.

Basic requirements on the introduction of SAML

You should answer the following questions at least before (partially) introducing SAML:

  • Does the service to be connect support SAML 2.0?
  • What does the user synchronization entail?
  • Does the service to be connected support just-in-time provisioning?
    • How are users deleted?
    • How it is possible to perform other provisioning?
  • What roles should there be in the service to be connected?
    • Are there a wide range of different user roles?
    • Is there a standard role for users?
    • How can this be reflected using SAML attributes?
    • Can the service assign that?

We hope that we have been able to offer you a good introduction to the technology of the SAML protocol. Should you have any further questions, please feel free to contact us.

Sources:
[1] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
[2] https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

Michel has been working in the Professional Services Team at Univention since January 2014. He is involved in larger and small-sized UCS projects. Lots of them in the educational area. Furthermore does he like giving presentations and conducting workshops. His personal interests are agile project management and test-driven development in Python. Currently Michel works as IT-Consultant.

What's your opinion? Leave a comment!

Your email address will not be published. Required fields are marked *