SAML – meaning „Security Assertion Markup Language“ – is a standard which enables a Single Sign-On (SSO). Users only log in once and are able to use other programs and services automatically. UCS supports SSO with SAML as well. That‘s why users get not only a central identity by using SAML but also a central log-in with UCS, making web-based working more secure and comfortable.
To enable users‘ authentication and authorization, SAML uses XML. SAML defines two different components: The identity provider (IdP) and the service provider (SP). The IdP is an authentication service that provides a login mask. On top of that it redirects users to the SP. You can use the service provider only after you have done your authentication with the IdP because the SP trusts the IdP‘s authority to authenticate users. The SP can be any service supporting SAML; for example a cloud storage service such as Nextcloud.
SAML uses so called session cookies in the background. These cookies have an expiry date. Users get them after they have authenticated themselves at the IdP. This is also important for using other services that are connected to the IdP. A direct connection between IdP and SP isn‘t necessary because session cookies are stored in the user‘s browser. This enables scenarios in which an UCS server, acting as an IdP, can only be reachable within an internal network and still authenticate user‘s for an external cloud service reachable from the internet.
To connect services with SAML it‘s necessary to exchange metadata, which contains so called artifacts.
But don‘t be scared! These terms sound complicated – but are explained quickly. IdP and SP both provide metadata. Most of the time metadata is stored in XML files (also on UCS). The IdP provides the following important artifacts in it‘s metadata:
This link points to the log-in process of the identity provider. It must be provided to any service provider, which shall trust authentications from the IdP. How the authentication actually happens is not specified. You can have a nickname and a password, but it could also be a multi-factor authentication.
This link points to the IdP‘s log-out process and is needed for the log-out in any other services trusting the IdP. Users log out and will be redirected to the IdP logout endpoint. This link can be provided to service providers.
The identity provider provides a public certificate which is used by service providers to sign authentication requests to the IdP. It must be provided to service providers.
Service providers use the following artifacts:
This link redirect users to a service after their authentication at the IdP. It must be configured on the IdP.
After logging out of one service, this link is used for logging out of any other services. The IdP sends a logout request to service A if a user has done the logout in service B already. For this purpose, the SingleLogoutService link has to be configured in service A.
Exchanging metadata typically works different between different services. Some services only require the metadata XML file to be uploaded, others require a manual configuration of the artifacts it contains.
Many services offer so called just-in-time provisioning. That means: users who authenticate themselves for the first time, automatically get a user account in the service. Some services don‘t support just-in-time provisioning so that user accounts have to be created separately for users to authenticate via SAML.
UCS supports – if required – just-in-time provisioning for example for services as Office 365 and Google GSuite. Many other services create user accounts by themselves if the users log in via SAML. The easiest way to modify user attributes in a service is for the IdP to provide them along with the SAML assertion or via other interfaces. It‘s also possible to combine both.
There are also several possibilities for deleting users. For example, some services will delete accounts automatically if they are unused for some time. Others can be deleted by using another interface. Both variants are supported by UCS for example for Office 365 (here the UCS Office 365 Connector authenticates against an interface in the Azure cloud and commissions users there) or for GSuite services. The types of the interfaces varied between different services a lot.
An authentication with SAML typically goes like this:
In addition to the authentication of the users themselves, a detailed authorization can also be configured. Authorization might be necessary to get access to certain resources a service provides. For that purpose SAML allows the exchange of user attributes between IdP and SP.
Using the attributes a service can make decisions about resource access. UCS allows you to define whether it should transfer LDAP attributes and if so, which ones, for each individual service provider.
Broadband internet speeds have made real-time communication a reality, but it can be a challenge to sift all of the solutions on the market. Rocket.Chat, as an open-source product, has positioned itself as a full-featured messaging platform. More
The SAML integration in UCS already exists since UCS 4.1. You can find the login mask here by default: https://ucs-sso.domainname/univention/saml/. The following link serves the metadata: https://ucs-sso.domainname/simplesamlphp/saml2/idp/metadata.php.
The UCS manual describes how to add service providers. For Office 365 and Google G Suite there are special connector apps in the Univention App Center, which create, modify and delete users.
Tip: You can make SAML login available under another link to enable outside access for example. The Univention Knowledge Base describes how that works.
Before you decide to use SAML in your infrastructure you should ask yourself some questions:
If you use SSO in the right way, your users will have a comfortable access to many different services, applications and resources.
SAML as an authentication and authorization system and UCS as the identity provider that performs the verification provide good service here. If you have any further questions, please don‘t hesitate to contact us.
