SAML security cheat sheet

Introduction#

The Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions that is used for single sign-on (SSO) and identity federation. It is commonly used in enterprise environments for authentication and authorization purposes.

Standard SAML authentication flow#

1. User requests access to a client application, which acts as a service provider (SP).
2. SP sends a SAML SSO authentication request to the identity provider (IdP) and redirects the user to the IdP.
3. IdP prompts the user for credentials if the user is not already authenticated.
4. User enters credentials, and IdP authenticates the user.
5. IdP sends a SAML response assertion to the SP, which includes the user's authentication status and attributes. IdP then redirects the user back to the SP.
6. SP receives the SAML response assertion, validates it, and grants access to the user.

Security factors in SAML#

SP entity ID#

Think of the SP entity ID as the unique badge for a SP under the SAML authentication context. It’s like a fingerprint that helps the IdP recognize the SP during their interactions. This ID is a key part of the SP's metadata, shared with the IdP to build trust and ensure secure communication.

Usage of SP entity ID:

1. Metadata registration: The EntityID attribute is part of the SP's metadata, shared with the IdP to establish a trust relationship. It serves as a unique identifier to locate the SP's metadata and obtain the required configuration details for SAML interactions.
2. Authentication request: The SP entity ID is included in the SAML authentication request sent to the IdP, clearly identifying the requesting SP. The IdP uses this information to validate the request and determine the appropriate authentication context.
3. Assertion audience: After successful user authentication, the SP entity ID is included in the SAML assertion as an audience restriction. This measure ensures that the assertion is intended exclusively for the designated SP and cannot be misused by other SPs.

IdP entity ID#

On the flip side, the IdP entity ID is the special label for the IdP. It helps identify the IdP within the SAML ecosystem, making it easy for the SP to find it. This ID is included in the IdP's metadata and is shared with the SP, fostering a trusting relationship and secure connections.

Usage of IdP entity ID:

1. Metadata registration: The EntityID attribute is also included in the IdP's metadata, shared with the SP to establish a trust relationship. It serves as a unique identifier to locate the IdP's metadata and obtain the necessary configuration details for SP to validate SAML responses.
2. Assertion issuer: When the IdP generates a SAML assertion, it includes its entity ID as the issuer. This attribute indicates the entity that issued the assertion and helps the SP verify the assertion's authenticity and integrity.

Relay state#

Relay state is a parameter used in SAML authentication that facilitates the transfer of state information between the SP and the IdP. It acts as a bridge between the SP-initiated and IdP-initiated SSO flows, preserving the user's context and session state during the authentication process.

Usage of relay state:

1. Maintaining user context: Relay state allows the SP to pass additional information to the IdP during the authentication process. This information can include the user's session state, application context, or any other relevant data that needs to be preserved across the SAML flow. Such as the URL or session ID of the application the user was accessing before authentication.
2. Preventing CSRF attacks: Relay state is crucial for preventing cross-site request forgery (CSRF) attacks during SAML authentication. By including a unique and unpredictable relay state value in the authentication request, the SP can verify the integrity of the SAML response and ensure that it corresponds to the original request.

Assertion signature#

The assertion signature is a critical security feature in SAML that ensures the integrity, authenticity, and non-repudiation of SAML assertions. It involves digitally signing the SAML assertion using the IdP's private key, allowing the SP to verify the assertion's origin and detect any tampering attempts.

How assertion signature works:

1. Key pair generation: The IdP generates a public-private key pair, where the private key is used to sign the SAML assertion, and the public key is shared with the SP for verification. This asymmetric encryption scheme ensures that only the IdP can sign the assertion, while the SP can validate it.
2. Shared certificate: The IdP provides the SP with its public key certificate, which contains the public key used for verifying the assertion signature. Normally, this certificate will be part of the IdP's metadata, or the SP can obtain it through a secure download process.
3. Assertion signing: After authenticating the user, the IdP digitally signs the SAML assertion using its private key. This signature is included in the assertion, along with the public key certificate, allowing the SP to verify the assertion's authenticity.
4. Assertion verification: Upon receiving the SAML assertion, the SP uses the IdP's public key to verify the assertion's signature. If the signature is valid, the SP can trust the assertion and grant access to the user.

Assertion encryption#

In addition to signing, SAML also supports assertion encryption to protect sensitive user attributes and data transmitted between the IdP and SP. By encrypting the assertion, the IdP ensures that only the intended recipient (SP) can decrypt and access the assertion's contents, safeguarding user privacy and confidentiality. Assertion encryption is an optional security feature in SAML that can be used to enhance data protection.

Usage of assertion encryption:

1. Sensitive attribute protection: Assertion encryption is particularly useful for safeguarding sensitive user attributes, such as Personally Identifiable Information (PII), financial data, or health records. By encrypting these attributes within the assertion, the IdP prevents unauthorized access and ensures data confidentiality.

How assertion encryption works:

1. Key exchange: The IdP and SP establish a secure key exchange mechanism to share encryption keys for protecting the SAML assertion. This can involve using symmetric encryption keys or public-key encryption schemes, depending on the encryption algorithm and key management strategy.
2. Attribute encryption: After generating the SAML assertion, the IdP encrypts the sensitive user attributes using the shared encryption key. The encrypted attributes are embedded within the assertion, ensuring that only the SP can decrypt and access the data.
3. Assertion decryption: Upon receiving the encrypted assertion, the SP decrypts the protected attributes using the shared encryption key. This process allows the SP to access the user's sensitive data securely and process it as needed.

Binding methods#

SAML binding methods define how SAML messages are transmitted between the SP and IdP over different communication protocols. They specify the encoding, transport, and security mechanisms used to exchange SAML assertions and requests, ensuring secure and reliable communication between the involved parties.

Both the SP and IdP will specify which binding methods they support in their metadata, allowing them to negotiate the appropriate method for SAML interactions. The choice of binding method depends on factors such as message size, security requirements, and the communication channel's characteristics.

SAML binding methods:

1. HTTP Redirect: SAML messages are encoded as URL parameters and transmitted via HTTP redirect. This binding is suitable for scenarios where the message size is limited, and the communication channel is not secure.
2. HTTP POST: SAML messages are encoded as form parameters and transmitted via HTTP POST requests. This binding is used when the message size exceeds the URL length limit or when additional security measures are required.
3. Artifact: SAML messages are transmitted using short-lived tokens called artifacts, which are exchanged over a secure back-channel between the SP and IdP. This binding is suitable for scenarios where message confidentiality and integrity are critical, and the communication channel is secure.

Most common binding methods:

• Authentication request: The authentication request from the SP to the IdP is typically transmitted using the HTTP Redirect due to its simplicity and efficiency. The SP encodes the SAML request as URL parameters and redirects the user's browser to the IdP for authentication. This is known as the SP-initiated SSO flow.
• Assertion response: The SAML response assertion from the IdP to the SP is usually transmitted using the HTTP POST binding method. The IdP encodes the SAML assertion as form parameters and posts it back to the SP for validation. This ensures that the assertion is securely transmitted without exposing sensitive data in the URL. Also, the HTTP POST binding can handle larger message sizes compared to the HTTP Redirect binding.

Security elements and considerations in SAML assertions#

Issuer#

As mentioned earlier, the issuer is a key attribute in SAML assertions that identifies the entity that issued the assertion. The issuer is typically the IdP that authenticated the user and generated the assertion. By including the issuer attribute in the assertion, the SP can verify the assertion's origin and ensure that it comes from a trusted source.

Signature#

The signature element in a SAML assertion contains the digital signature generated by the IdP to ensure the assertion's integrity and authenticity. The signature is created using the IdP's private key and included in the assertion along with the public key certificate for verification by the SP. By validating the signature, the SP can verify that the assertion has not been tampered with and comes from the expected IdP.

Conditions#

The conditions element in a SAML assertion defines the constraints and restrictions that apply to the assertion's validity and usage. It includes conditions such as the assertion's validity period, audience restrictions, and other contextual constraints that the SP must enforce when processing the assertion.

Authentication statement#

The authentication statement (AuthnStatement) is a key component of the SAML assertion that provides information about the user's authentication status and context. It includes details such as the authentication method used, the time of authentication, and any relevant authentication context information, allowing the SP to make informed access control decisions based on the user's authentication state.

Authentication statement attributes:

1. AuthenticationContext: Describes the method and context of user authentication, such as username-password, multi-factor authentication, or single sign-on. This attribute helps the SP assess the strength and reliability of the authentication process and determine the appropriate access controls.
2. AuthenticationInstant: Indicates the time when the user was authenticated by the IdP. This timestamp is crucial for verifying the freshness of the authentication and preventing replay attacks or session hijacking.
3. SessionNotOnOrAfter: Specifies the expiration time of the user's session, after which the user must re-authenticate to access the service. This attribute helps enforce session management policies and mitigate the risk of unauthorized access.

Best practices for SAML security#

1. Use secure binding methods: Choose appropriate SAML binding methods based on your security requirements and communication channel characteristics. Use HTTP POST for transmitting sensitive data and HTTP Redirect for simple requests.
2. Validate assertion signatures: Verify the digital signatures of SAML assertions to ensure their integrity and authenticity. Use the IdP's public key certificate to validate the signature and detect tampering attempts.
3. Enforce audience restrictions: Include audience restrictions in SAML assertions to limit the assertion's scope to the intended SP. This prevents assertion replay attacks and unauthorized access by other service providers.
4. Secure metadata exchange: Protect the exchange of SP and IdP metadata to prevent metadata tampering and spoofing attacks. Use secure channels and mechanisms to share metadata securely.
5. Implement secure relay state handling: Use unique and unpredictable relay state values to prevent CSRF attacks during SAML authentication. Validate the relay state to ensure its integrity and authenticity.
6. Enforce session management: Define session expiration policies and enforce session timeouts to mitigate the risk of session hijacking and unauthorized access. Use session-related attributes in SAML assertions to manage user sessions securely.
7. Encrypt sensitive attributes: If necessary, encrypt sensitive user attributes within SAML assertions to protect user privacy and data confidentiality. Use secure encryption algorithms and key management practices to safeguard sensitive data.

Alternatives to SAML#

While SAML remains a widely adopted standard for SSO and identity federation, offering a robust set of features and security mechanisms, its age can pose challenges in meeting the evolving security and usability demands of modern applications. When compared to the more contemporary OAuth 2.0-based OpenID Connect (OIDC), SAML tends to be more complex and lacks some of the enhanced security features that OIDC provides. For instance, OIDC’s multi-security request authorization code grant flow offers a more secure approach than the relatively straightforward SAML assertion exchange flow. For organizations looking to adopt a more modern and flexible identity federation solution, OIDC may be a viable alternative to SAML.