Brief Introduction: SAML- a secure, comfortable web access

What about SAML

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.

Connecting services with SAML

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:

SingleSignOnService Link

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.

SingleLogoutService Link

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.

Public certificate

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:

AssertionConsumerService Link

This link redirect users to a service after their authentication at the IdP. It must be configured on the IdP.

SingleLogoutService Link

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.

User administration

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.

Procedure: Authentication with SAML

An authentication with SAML typically goes like this:

1. If a user wants access to an internal or external service, she opens the service‘s login link (technically a GET request), for example wiki.univent.intern/login.
2. The service will redirect the user to the IdP‘s SingleSignOnService link. The redirection
   contains a request of the service that has to be signed by IdP.
3. The user‘s browser opens the IdP‘s SingleSignOnService Link and submits the request.
4. The user authenticates herself.
5. The IdP‘s answer contains the AssertionConsumerService link.
6. The browser uses the AssertionConsumerService link to make a POST request to the SP.
7. The SP considers the user to be authenticated at this point.
8. The SP redirects the user to the initial login URL. From there she is redirected to the actual resources of the service, because of the successful authentication from the IdP.

Authorization based on attributes

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.

Advantages and disadvantages of SAML

Advantages

• Single Sign-On is available for all users.
• Many services support SAML natively or via plug-ins, including many cloud services.
• Administration effort is reduced, because there is only one database to maintain the accounts in.
• Security profit:
  There is only one internal user database which doesn‘t have to be accessible from the outside (Internet).
  Passwords are no longer needed in other services.

SAML – Suitable for me?

Before you decide to use SAML in your infrastructure you should ask yourself some questions:

• Are my services compatible to SAML 2.0?
• How do I handle user synchronization?
• Are my services capable of just-in-time provisioning?
• How are users deleted?
• How can I provide users other methods?
• Which roles should exist in the service to be connected?
• Are there many different user roles?
• Is there a default role for users?
• How can a default role be mapped via SAML attributes?
• Can the service assign this?

Do you have 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.