Why analyze a SAML response?

A SAML response contains crucial information about the authentication and authorization process at the service provider. Analyzing it can help you identify where exactly a problem has occurred. This can include fields at assertion level, identity attributes, certificates, digital signatures, timestamps, etc.

SAML response analysis is relevant when an authentication problem occurs, or when the user session with the service provider (Olfeo Saas) fails to establish itself. This analysis will enable you to adapt or correct your IDP configuration.

The aim of this document is to give you some basic information on how the SAML protocol works, and then to give you the keys you need to analyze the SAML response for troubleshooting purposes.

The SAML protocol at a glance

SAML, which stands for "Security Assertion Markup Language", is a security protocol used to exchange authentication and authorization information between different IT systems, typically between an identity provider (IdP) and a service provider (SP), in this case the Olfeo Saas. Here's a summary of SAML's main features:

• Single Sign-On (SSO): SAML enables users to connect once to a central authentication service (Identity Provider - IdP) and then access several applications (Service Provider - SP) without having to re-enter their credentials (except for the time-limited duration of the token).
• Identity federation: SAML facilitates collaboration between different organizations by enabling users from one organization to connect securely to services from another.
• Security assertion: When a user logs in, the identity provider generates a security assertion containing information about the user and the permissions granted. This assertion is then transmitted to the service provider, which decides whether or not to authorize access on the basis of this information.
• XML-based: SAML assertions are generally encoded in XML, making them easily readable by SAML-compatible systems and applications.
• Security: SAML uses encryption and digital signature mechanisms to guarantee the integrity and confidentiality of authentication and authorization data as it is transmitted between different parties.
• Varied usage scenarios: SAML is used in a variety of scenarios, such as access to cloud applications, web services, corporate portals and more.

SAML authentication sequence 

Here are the main steps in a SAML authentication sequence between an IDP, a SP (here Olfeo Saas) and the user's Web browser:

1. SP access request: The user attempts to access SP using a web browser.
2. SAML request generation: the SP identifies that the user is not yet authenticated and generates a SAML authentication request, which is encoded and integrated into the URL associated with the IDP's SSO service.
3. Redirection to IDP: The SP sends a redirection URL to the user's browser. This URL includes the encoded authentication request to be sent to the IDP's SSO service. This includes information on the requested service (Assertion Consumer Service - ACS) and a unique request identifier.
4. Authentication by IDP: The IDP decodes the SAML request and verifies the user's authentication (e.g., via username and password). Once authentication is successful, the IDP creates a SAML token containing information on the user's identity and the necessary attributes.
5. SAML assertion creation: The IDP generates a SAML assertion containing the user's authentication information. In accordance with SAML 2.0 specifications, this assertion is digitally signed by the IDP to guarantee its integrity and origin.
6. Redirection to SP with SAML assertion: The IDP encodes the response, including the SAML assertion. It redirects the user to the ACS (Assertion Consumer Service). The SP checks the assertion's digital signature to ensure that it has come from the IDP.
7. Processing of the assertion by the SP: The SP receives the SAML assertion, checks the assertion's digital signature to ensure that it comes from the IDP and extracts the authentication information. This information can be used by the SP to authorize access to the requested resources.
8. User session establishment: The SP creates a user session for the authenticated user and gives him/her access to the requested services. The user can now interact with the SP's services, without having to provide additional credentials for the duration of the session.

SAML response capture

The SAML response contains crucial information about the authentication and authorization process at the service provider. Analyzing it can help you identify where exactly a problem has occurred. This can include fields at assertion level, identity attributes, certificates, digital signatures, timestamps, etc.

To retrieve the SAML response (step 6 in the previous diagram), you need to capture it in the client Web browser. To do this, we recommend using the SAML-Tracer extension available for Edge or Firefox browsers. The SAML response can then be viewed in XML format using Notepad++.

SAML response analysis

Assertion status :

L’élément <StatusCode> dans une réponse SAML est utilisé pour indiquer le statut du traitement de la demande ou de l’opération associée à l’assertion SAML. Il fournit des informations sur le résultat de la transaction ou de l’authentification, que ce soit une réussite ou une erreur. Assurez-vous que l’élément <StatusCode> de la réponse SAML indique un statut de succès.

Some examples of possible statuses:

• Success : Indicates that the operation was successful.
• VersionMismatch: Indicates that the SAML version in the request does not match the version supported by the receiver.
• AuthnFailed: Indicates that authentication has failed for the user.
• InvalidAttrNameOrValue: Indicates that the attributes provided in the request are invalid. Here, it's usually the format or value of the NameID (Name Identifier) attribute that is incorrect .

NameID attribute :

The NameID plays a key role in the authentication, authorization and identity management process. Thanks to the NameID, the SP receiving the SAML assertion can uniquely identify the user and make decisions based on this identification.

The identifier property (green box) defined when synchronizing your directory with Olfeo Saas must be used in the NameID attribute. You must also ensure that the domain (red box) is correctly filled in. Note that Olfeo SaaS uses the UserPrincipalName as the default identifying property.

If, when synchronizing your directory, you set the identifying property to be SamAccountName, you need to modify your IDP's claims so that it associates SamAccountName with the NameID passed during the authentication response. For more information on this subject, please refer to the " Configuring and managing directories " section.

Transmitter :

L’attribut <Issuer> de l’assertion SAML doit contenir l’identifiant unique de l’IDP émetteur. Assurez-vous que cet émetteur est celui attendu par le SP. Il doit également être présent au niveau de la réponse SAML.

Destination :

L’URL de réponse (ACS) indique au fournisseur d’identité (IdP) où envoyer l’assertion SAML une fois que l’authentification de l’utilisateur a été effectuée. L’URL de réponse (ACS) doit se trouver niveau du champ « destination » de la réponse SAML. À noter que vous devriez également retrouver l’URL de réponse (ACS) au niveau l’élément <SubjectConfirmationData> de l’assertion SAML.

Audience :

Dans une assertion SAML, le champ <AudienceRestriction> est utilisé pour définir des contraintes sur l’audience à laquelle l’assertion est destinée. En d’autres termes, il spécifie les entités (services, applications, fournisseurs de services) qui sont autorisées à recevoir et à consommer cette assertion.

Digital signature :

The SAML assertion must be digitally signed by the IDP to guarantee its integrity and origin. Signing the assertion is the minimum requirement; a signed SAML response with a signed assertion is also possible. Remember to check that the certificate and signature are present, and that the minimum SHA 256 algorithm is used. 

Conditions of Validity :

Vérifiez que les conditions temporelles (élément <Conditions>) de l’assertion SAML sont satisfaites. Cela comprend les horodatages de validité, pour assurer que l’assertion est émise et utilisée pendant la période appropriée (éléments <NotBefore> et <NotOnOrAfter>). Il peut aussi y avoir d’autre conditions si elles sont spécifiées, dans notre cas il y a une condition sur l’audiance (sujet évoqué plus haut dans le document).

Authentication method :

L’élément <AuthnContext> spécifie la méthode d’authentification utilisée. Dans le cadre d’Olfeo Saas sa valeur doit être : Password.

Encoding :

Check that the SAML assertion is correctly encoded (e.g. base64) for transport.