Security Assertion Markup Language (SAML)

SAML stands for Security Assertion Markup Language and is one of the most widely used standards for exchanging authentication data. SAML enables secure Single Sign-On. Users need to authenticate only once after which they do not need to log in again.

This is possible because the applications, ‘service providers’, trust all systems that verify the identity of users, ‘identity providers’.

SAML is one of the foundational standards for many Federated Identity Management (FIM) solutions. Federated Identity Management (FIM) is a concept where an authentication solution can be used across organizations. Other FIM standards include OpenID and OAuth. All these solutions share two common goals:

1. Offering a pleasant user experience: quick and easy access to applications with a single set of login credentials.
2. Improving security: no separate storage of login details in separate databases.

Why SAML?

SAML, as part of Federated Identity Management (FIM) solutions, is designed to make users’ lives easier and safer. Without such solutions, users would be forced to manage different login credentials for every site they use, which can ultimately lead to unsafe situations.

Here are some of the main reasons why you should consider using SAML:

1. Reduction of unsafe situations: It’s not uncommon for end-users to write their passwords on post-its and store them under their keyboard. SAML reduces this risk by decreasing the number of login credentials users need to remember and enter.
2. Enhanced security: SAML increases security by reducing the risk of phishing attacks and password leaks. All communication between the identity provider and the service provider is encrypted, reducing the chance of data interception.
3. Efficiency: SAML enables Single Sign-On (SSO), meaning users only need to log in once to access multiple applications or services. This saves time and reduces frustration for users.
4. Convenience: By introducing an advanced access management solution like SAML in your organization, end-users have streamlined access to the applications they need on a daily basis. This reduces downtime caused by forgotten passwords and locked accounts.
5. Privacy: SAML can be configured to share only necessary user information, thereby protecting users’ privacy.
6. Flexibility and interoperability: SAML is an open standard, meaning it can be implemented across a wide range of systems and applications, regardless of the programming language or platform they are built on.

In short, SAML offers a secure, efficient, and user-friendly solution for managing digital identities and performing authentication and authorization in a distributed environment. It is an essential component of any effective FIM solution.

SAML and Privacy

In today’s digital age, privacy is a key concern. SAML plays a crucial role in this by helping protect users’ privacy during the authentication process.

One way SAML does this is by minimizing the amount of personal information shared between the Service Provider (SP) and the Identity Provider (IdP). In a SAML transaction, the IdP sends a SAML assertion to the SP. This assertion contains information about the user’s identity and authentication status, but it does not need to contain detailed personal information. The SP only needs to know that the user has been successfully authenticated by the IdP, not who the user precisely is.

Furthermore, all information exchanged in a SAML transaction is encrypted and digitally signed. This ensures that the data cannot be intercepted or altered during transmission, further protecting the user’s privacy and security.

It’s also important to note that SAML can be configured to comply with various privacy laws, such as the General Data Protection Regulation (GDPR) in the European Union. This makes SAML an attractive choice for organizations concerned about complying with privacy legislation.

In summary, SAML offers a secure and privacy-friendly way to exchange authentication and authorization data between different parties. It helps organizations protect their users’ privacy while simultaneously providing an efficient and user-friendly authentication experience.

How Does SAML Work?

To fully understand how SAML works, we’ll start by exploring the concept of a SAML provider. A SAML provider is any server involved in authenticating and authorizing a user during a SAML request. There are two types of SAML providers: service providers (SP) and identity providers (IdP).

Service Providers (SP) are the systems and applications that users use throughout the day. Without SSO, each system would need to maintain its own database of login credentials. The more applications you use, the more diverse login credentials you need to remember and manage.

With the advent of SSO standards like SAML, users no longer need to remember all the different passwords. They only need to sign in once at their IdP and then gain access to their favourite applications. Authentication from that point is automatic and transparent to the user.

An Identity Provider (IdP) is the system that performs user authentication. This is the central location where login credentials are actually stored and validated. Once a user signs in at their IdP, they have access to their SSO-enabled applications. Various IdPs are available on the market. Often, (Azure) AD is used as an IdP, but HelloID can also be deployed.

The conversation that takes place between the identity and service providers happens through a message named Assertion. This is an XML document created by the IdP and verified by the SP. It contains all relevant details of the end user: unique ID, name, and any additional attributes that may be required by the SP.

All assertions are signed with an X.509 certificate by the IdP. The SP has a copy of the ‘fingerprint’ of the certificate, which is used to verify the authenticity of the assertion. This prevents unauthorized access.

Explanation of SAML Authentication – How Does It Work in Practice?

The process of SAML authentication starts when a user tries to access a service, such as a web application. This service is called the Service Provider (SP). The SP sends a request to another entity, the Identity Provider (IdP), to verify the identity of the user.

Let’s illustrate this with a concrete example where HelloID acts as the IdP and TOPdesk as the SP:

1. The user logs in to the HelloID portal (IdP) with a username and password combination. Other forms of authentication are also possible.
2. HelloID shows the user an overview of applications.
3. The user clicks on TOPdesk (SP).
4. HelloID creates a SAML message to perform authentication at TOPdesk. HelloID signs and/or encrypts the message using a certificate.
5. The SAML message is sent to TOPdesk.
6. TOPdesk verifies the SAML message using a certificate and checks access.
7. The user is logged in to TOPdesk without the need for a login page.

This entire process is seamless and transparent to the user. Most importantly, SAML provides a secure and efficient way to manage and share identities in a distributed environment. SAML can be used in much more complex scenarios, with multiple SPs and IdPs, and with more advanced types of assertions containing more detailed information.

Alternatives to SAML

Although SAML is a popular choice for managing Single Sign-On (SSO) and federated identity, there are also other technologies that offer similar functionalities. Here are some of the most common alternatives to SAML:

1. OpenID Connect: This is an open standard used for authenticating users in an end-to-end manner, allowing identities to be federated across different domains. OpenID Connect is based on the OAuth 2.0 protocol and uses JSON Web Tokens (JWT) for exchanging claims.
2. OAuth 2.0: While often used in conjunction with OpenID Connect for authentication, OAuth 2.0 is primarily used for authorized access to APIs. It allows a user to give an application access to their information at another service provider, without sharing their login credentials.
3. WS-Federation: This is a protocol used for federated identity and is based on the WS-* (Web Services) specifications. It is often used in Microsoft environments and is integrated into products such as Active Directory Federation Services (ADFS).
4. LDAP (Lightweight Directory Access Protocol): While not a federated identity protocol, LDAP is often used for storing and looking up information in a directory service, such as usernames and passwords. It can be used in combination with other technologies to implement SSO.

Each of these alternatives has its own advantages and disadvantages, and the best choice depends on the specific needs and circumstances of your organization. It’s important to consider which protocol best suits your technical requirements, security needs, and the skills and knowledge of your IT team.

Cloud software HelloID Whitepaper HelloID