Secure identity and access management has become a key challenge for organisations. Among the solutions available, Security Assertion Markup Language (SAML) has become an essential standard for single sign-on (SSO).
This XML-based protocol enables users to authenticate once and access multiple applications without having to log in again, simplifying the user experience. However, if poorly implemented, critical vulnerabilities can be exploited.
This article takes an in-depth look at the principles and operation of SAML. We will also present the common vulnerabilities and attacks to which it can be exposed; and detail the best practices to adopt for a secure SAML implementation.
What is SAML and How Does SAML Authentication Work?
Understanding SAML
Security Assertion Markup Language (SAML) is an XML-based open standard that enables the exchange of authentication and authorisation information between different parties, in particular between an Identity Provider (IdP) and a Service Provider (SP).
SAML plays a crucial role in enterprise environments by facilitating single sign-on (SSO), enabling users to authenticate once to access a multitude of applications and services without having to log in each time.
SAML architecture and components
This protocol is based on a clear, well-defined architecture that includes key components and fundamental principles. At the heart of this architecture are the IdP and the SP.
Identity Provider
An Identity Provider (IdP) is an entity responsible for authenticating users and providing the necessary identity information to Service Providers (SPs). The IdP plays a central role in verifying identities and managing authentication information.
The IdP is responsible for validating the user’s identity using various authentication mechanisms, such as passwords, digital certificates, hardware tokens or multifactor authentication (MFA) methods. Once the user has been authenticated, the IdP generates a SAML assertion, which contains the user’s identity and authorisation information. This assertion is signed to guarantee its integrity and authenticity.
The IdP manages the user’s identity information, such as name, email address, role and other relevant attributes. This information is included in the SAML assertion sent to the SP. Many IdPs are available, including Okta, Microsoft Azure Active Directory, Google Identity Platform, Auth0 and Keycloak.
Service Provider
A Service Provider (SP) is an entity that provides services, applications or resources to users. The SP delegates responsibility for authentication to an IdP and uses the information provided by the IdP to control access to resources.
When a user attempts to access an application or service, the SP redirects the user to the IdP for authentication. It will then process the SAML assertion sent back to it to connect the user to the platform.
SAML authentication process
To fully understand how SAML works, it is useful to examine a typical authentication flow in detail. When a user attempts to access a SAML-protected application (SP), the access request triggers a series of well-defined steps.
First, the user initiates a request for access to the application (SP). In response, the SP redirects the user to the IdP for authentication. This redirection is often accompanied by a SAML request containing the information needed to identify the user and the requested service.
Once redirected, the user interacts with the IdP to authenticate. This may involve entering a username and password, using multi-factor authentication (MFA) methods or other authentication techniques. If authentication is successful, the IdP generates a SAML assertion, which is essentially a proof of the user’s identity and authentication.
The SAML assertion is then transmitted to the SP. The SP receives the assertion and checks its integrity and authenticity. This includes validating the assertion’s digital signature and checking the attributes contained to ensure that they match the SP’s expectations and security rules.
If the assertion is valid and the attributes match the security criteria, the SP grants access to the user, enabling him or her to access the requested resources without having to log in again.
This fluid, secure SSO process not only enhances the user experience, but also strengthens security by centralising identity management and reducing the attack surface for passwords.
SAML signature and encryption keys
In SAML-based security systems, the use of cryptographic keys is essential to ensure the security and integrity of exchanges.
Two types of keys are commonly used: signing keys and encryption keys.
Signing keys
Signing keys are used to guarantee the authenticity and integrity of SAML messages. When an Identity Provider (IdP) signs a SAML assertion, it uses a private key to create a digital signature.
This signature enables the Service Provider (SP) to verify that the assertion has not been altered in transit, and that it comes from the legitimate IdP.
The digital signature is created by applying a signature algorithm to the SAML assertion using the IdP’s private key. The SP, in possession of the corresponding public key, can then verify the signature (via the <ds:X509Certificate> tag in the metadata).
If the signature is valid, this confirms that the assertion is authentic.
Encryption Keys
Encryption keys are used to protect the confidentiality of exchanged data. When sensitive information is included in a SAML assertion, it can be encrypted to ensure that it can only be read by authorised parties.
Data encryption is achieved by using a public key to encrypt the information. Only the party possessing the corresponding private key can decrypt the data. In the SAML context, this means that the IdP can encrypt certain parts of the assertion before sending it to the SP. This ensures that only the SP with the corresponding private key can read the information.
What is the Difference Between SAML and OpenID?
In the identity and access management (IAM) landscape, SAML and OpenID are two of the most widely used protocols for single sign-on (SSO) and authorisation. Although they share similar objectives, their architectures, mechanisms and use cases differ.
Architecture and working principles
SAML is based on a structured exchange of authentication and authorisation information using XML documents between an identity provider (IdP) and a service provider (SP). SAML uses assertions to transmit identity and authorisation information, enabling secure single sign-on.
OpenID is an OAuth 2.0-based protocol that enables authentication using JSON Web Tokens (JWT).
Unlike SAML, OpenID Connect is designed to be lightweight and easy to integrate, making it particularly suitable for modern web and mobile applications.
OpenID Connect adds an authentication layer to OAuth 2.0, allowing users to connect to third-party applications using their existing credentials from an identity provider.
Security and session management
In terms of security, both protocols offer robust mechanisms for protecting identity and authentication information.
SAML relies heavily on digital signatures and certificates to ensure the integrity and authenticity of assertions. This enables strict session and access management, which is particularly useful in regulated environments.
OpenID Connect also uses signing and cryptographic methods to secure JWTs. What sets it apart, however, is its ability to manage sessions more flexibly.
The access and update tokens in OAuth 2.0 enable user sessions to be managed efficiently. They also offer options for revoking and renewing tokens.
What are the Most Common SAML Vulnerabilities and Attacks?
SAML, although robust, can be vulnerable to several types of attack if poorly configured or implemented.
Among the most critical are replay attacks, assertion manipulation (due to a lack of signature), external file inclusion attacks (XXE), and attacks exploiting attribute validation errors, such as inter-tenant e-mail addresses.
Replay attacks
A replay attack occurs when valid SAML messages are intercepted and reused by an attacker to gain unauthorised access. This type of attack is possible if the system does not implement adequate mechanisms to prevent the reuse of SAML messages, such as timestamps or single-use tokens.
In a typical scenario, the SAML assertion is valid for approximately one minute, which is enough time for it to be generated and sent to the SP.
This delay is indicated in the saml:Conditions tag via the NotBefore and NotOnOrAfter attributes.
The assertion lifespan can be configured in the IdP parameters. For example, if it is set to 30 days, this could allow a valid assertion to be replayed and the account to be accessed unauthorised.
With a correct configuration, the assertion will no longer be valid after its first use, which limits the risks of replayability. On the other hand, incorrect configurations may not invalidate the assertion after use, thus allowing replay attacks.
To protect against replay attacks, it is necessary to use tokens with a limited lifespan: SAML assertions must include timestamps and very short validity periods. In addition, assertions must be invalidated as soon as they are used.
Assertion manipulation (in the absence of a signature)
When SAML assertions are not signed, they can be manipulated by attackers. The absence of a digital signature means that the assertion’s integrity and authenticity cannot be verified, allowing an attacker to modify the assertion’s attributes, such as roles or privileges.
In this case, all the options for validating assertions have been disabled via the SP configuration. This means that it will not check whether the assertion is encrypted and signed.
On our IdP, we are also going to disable signing and encryption of assertions.
When connecting to the identity provider, it will generate an unencrypted assertion, which will not protect the integrity of transmitted data.
By default, the “vaadata” user has the “default-roles-master” role.
An attacker can then intercept the SAML request during authentication, and add a ‘Role’ attribute with the value ‘create-client’.
This will modify the assertion sent to the server by adding a new role.
Once authenticated, you can see that the ‘create-client’ role has been added to the ‘vaadata’ account on the service provider, giving it more privileged access to the platform.
To prevent assertion manipulation, it is essential that all SAML assertions are digitally signed by the IdP. This ensures the integrity and authenticity of the information transmitted.
In addition, Service Providers (SPs) must systematically check the signature of each assertion to ensure that it has not been altered in transit.
XXE (XML External Entity)
XXE (XML External Entity) attacks exploit vulnerabilities in the processing of XML documents by misconfigured parsers. An XXE attack can enable an attacker to read sensitive files on the server, make network requests from the server and execute remote commands on the remote server.
If the SP server uses a custom XML parser or one that is vulnerable to XXE, it is possible to inject a payload into the SAML assertion in order to exploit an XML External Entity when parsing the SAML assertion.
To find out more, please refer to our article: Understanding XXE vulnerabilities.
Email forwarding attack
This attack exploits attribute validation flaws in SAML assertions, in particular when emails are not correctly checked to belong to the correct tenant.
If the system does not check that the email in the SAML assertion actually belongs to the tenant’s domain, an attacker can gain unauthorised access by using a valid email from another tenant.
In a context where the platform is multi-tenant and uses SAML for authentication, it is crucial to test the possibility of stealing an account from another tenant.
A lack of rights control on the Service Provider (SP) side can enable this attack. The Identity Provider’s (IdP) SAML assertion returns several attributes, including the user’s email, first name and last name, as well as other potential attributes such as role.
These attributes, present in <saml:Attribute> tags, are then parsed by the SP. The server then checks whether the email is present in its database. If so, it authenticates the user. If not, the connection fails because the user does not exist.
The attack therefore consists in sending the email address of another tenant’s account to the SP so that it can perform the connection and grant access in an unauthorised manner.
To ensure strict validation of email attributes, SPs must verify that the emails contained in SAML assertions actually belong to the correct tenant.
This ensures that only authorised users can access the resources specific to their tenant.
It is also crucial to implement strict separation controls between tenants. This segmentation avoids any confusion over identities between tenants, thereby strengthening security.
Finally, it is recommended that specific domains are assigned to each tenant. SPs should check that email addresses belong to the domain assigned to the tenant concerned, thus ensuring that users can only access authorised resources.
How to Secure SAML Implementations?
Strict validation of attributes
Service Providers (SPs) must strictly validate the email attributes contained in SAML assertions to ensure that they belong to the correct tenant.
This prevents malicious users from using valid but unauthorised email addresses to access sensitive resources.
Rigorous attribute validation verifies the authenticity and legitimacy of the information provided in SAML assertions.
Strict segmentation of tenants
It is crucial to implement strict separation controls between tenants to avoid any confusion or misunderstanding about identities.
Strict segmentation of tenants ensures that each tenant has its own identity management space, with no possible interference with the others.
Use of specific domains per tenant
Assigning specific domains for each tenant and checking that email addresses belong to the assigned domain is recommended practice.
By ensuring that email addresses are correctly associated with their respective tenant, SPs can prevent email forwarding attacks.
Digital signatures
All SAML assertions must be digitally signed by the Identity Provider (IdP).
Digital signatures guarantee the integrity and authenticity of assertions, preventing them from being altered by attackers.
SPs must systematically check the signature of each assertion to ensure that it has not been altered in transit.
Preventing replay attacks
To prevent replay attacks, SAML assertions must include time-limited tokens and precise timestamps.
SPs must rigorously check these timestamps and reject any assertion outside the validity window.
Regular monitoring and auditing
It is important to regularly monitor and audit SAML exchanges to detect any suspicious activity or anomalies. SAML transactions can be monitored and analysed by setting up intrusion detection systems (IDS) and audit logs.
This ongoing vigilance helps to identify and respond quickly to security incidents, reinforcing the organisation’s overall security posture.
Implementing multifactor authentication (MFA)
Multifactor authentication (MFA) adds an extra layer of security to the authentication process.
By combining several authentication methods, such as passwords, hardware tokens and biometric verification, IdPs can enhance the security of user identities.
Implementing an MFA reduces the risk of credentials being compromised and strengthens protection against unauthorised access.
Author: Alexis MARTIN – Pentester @Vaadata