Pourquoi analyser une réponse SAML ?

Une réponse SAML contient des informations cruciales sur le processus d’authentification et d’autorisation au fournisseur de service. L’analyser peut vous aider à identifier où exactement un problème s’est produit. Cela peut inclure des champs au niveau des assertions, les attributs d’identités, les certificats, les signatures numériques, les horodatages, etc.

L’analyse de la réponse SAML est pertinente dès lors qu’un problème d’authentification se produit ou lorsque la session utilisateur avec le fournisseur de service (Olfeo Saas) ne s’établit pas. Cette analyse vous permettra d’adapter ou corriger la configuration de votre IDP.

Dans un premier temps ce document a pour objectif de vous donner quelques informations de base sur le fonctionnement du protocole SAML, puis de vous donner les clefs nécessaires pour pouvoir analyser la réponse SAML à des fins de troubleshooting.

Le protocole SAML en bref

SAML, qui signifie « Security Assertion Markup Language », est un protocole de sécurité utilisé pour l’échange d’informations d’authentification et d’autorisation entre différents systèmes informatiques, typiquement entre un fournisseur d’identité (IdP) et un fournisseur de services (SP), en l’occurrence le Saas Olfeo. Voici un résumé des principales caractéristiques de SAML :

• Authentification unique (Single Sign-On, SSO) : SAML permet aux utilisateurs de se connecter une seule fois à un service d’authentification central (Identity Provider – IdP) et d’accéder ensuite à plusieurs applications (fournisseur de services – SP) sans avoir à saisir à nouveau leurs identifiants (sauf durée du token limité dans le temps).
• Fédération d’identités : SAML facilite la collaboration entre différentes organisations en permettant à des utilisateurs provenant d’une organisation de se connecter de manière sécurisée à des services d’une autre organisation.
• Assertion de sécurité : Lorsqu’un utilisateur se connecte, le fournisseur d’identité génère une assertion de sécurité qui contient des informations sur l’utilisateur et les permissions accordées. Cette assertion est ensuite transmise au fournisseur de service qui décide d’autoriser ou non l’accès en fonction de ces informations.
• Basé sur XML : Les assertions SAML sont généralement encodées en XML, ce qui les rend facilement lisibles par les systèmes et les applications compatibles avec SAML.
• Sécurité : SAML utilise des mécanismes de chiffrement et de signature numérique pour garantir l’intégrité et la confidentialité des données d’authentification et d’autorisation lors de leur transmission entre les différentes parties.
• Scénarios d’utilisation variés : SAML est utilisé dans une variété de scénarios, tels que l’accès aux applications cloud, aux services web, aux portails d’entreprise, etc.

Séquence d’authentification SAML 

Voici les principales étapes d’une séquence d’authentification SAML entre un IDP, un SP (ici Olfeo Saas) et le navigateur Web de l’utilisateur :

1. Demande d’accès au SP : L’utilisateur tente d’accéder SP en utilisant un navigateur internet.
2. Génération SAML requête : Le SP identifie que l’utilisateur n’est pas encore authentifié et génère une demande d’authentification SAML, qui est encodée et intégrée dans l’URL associée au service SSO de l’IDP.
3. Redirection vers l’IDP : Le SP envoie une URL de redirection au navigateur de l’utilisateur. Cette URL inclut la demande d’authentification encodée qui doit être envoyée au service SSO de l’IDP. Celle-ci inclut des informations sur le service demandé (Assertion Consumer Service – ACS) et un identifiant unique de demande (Request Identifier).
4. Authentification par l’IDP : L’IDP décode la demande SAML et vérifie l’authentification de l’utilisateur (par exemple, via un nom d’utilisateur et un mot de passe). Une fois l’authentification réussie, l’IDP crée un jeton SAML contenant des informations sur l’identité de l’utilisateur et les attributs nécessaires.
5. Création de l’assertion SAML : L’IDP génère une assertion SAML qui contient les informations d’authentification de l’utilisateur. Conformément aux spécifications SAML 2.0, cette assertion est signée numériquement par l’IDP pour garantir son intégrité et son origine.
6. Redirection vers le SP avec l’assertion SAML : L’IDP encode la réponse en y incluant l’assertion SAML. Il redirige l’utilisateur vers l’ACS (Assertion Consumer Service). Le SP vérifie la signature numérique de l’assertion pour s’assurer qu’elle provient bien de l’IDP.
7. Traitement de l’assertion par le SP : Le SP reçoit l’assertion SAML, il vérifie la signature numérique de l’assertion pour s’assurer qu’elle provient bien de l’IDP et extrait les informations d’authentification. Ces informations peuvent être utilisées par le SP pour autoriser l’accès aux ressources demandées.
8. Établissement de la session utilisateur : Le SP crée une session utilisateur pour l’utilisateur authentifié et lui donne accès aux services demandés. L’utilisateur peut désormais interagir avec les services du SP, sans avoir à fournir des informations d’identification supplémentaires pendant la durée de la session.

Capture de la réponse SAML

La réponse SAML contient des informations cruciales sur le processus d’authentification et d’autorisation au fournisseur de service. L’analyser peut vous aider à identifier où exactement un problème s’est produit. Cela peut inclure des champs au niveau des assertions, les attributs d’identité, les certificats, les signatures numériques, les horodatages, etc.

Pour récupérer la réponse SAML (étape 6 du précédent schéma) il faut la capturer au niveau du navigateur Web client. Pour se faire nous vous recommandons d’utiliser l’extension SAML-Tracer disponible pour les navigateurs Edge ou Firefox. La réponse SAML peut ensuite être visualisée au format XML à l’aide de Notepad++.

Analyse de la réponse SAML

Statut de l’Assertion :

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.

Quelques exemples de statuts possibles :

• Success : Indique que l’opération s’est déroulée avec succès.
• VersionMismatch : Indique que la version de SAML dans la demande ne correspond pas à la version prise en charge par le récepteur.
• AuthnFailed : Indique que l’authentification a échoué pour l’utilisateur.
• InvalidAttrNameOrValue : Indique que les attributs fournis dans la demande sont invalides. Ici, en général c’est le format ou la valeur de l’attribut NameID (Name Identifier) qui est incorrect.

Attribut NameID :

Le NameID joue un rôle clé dans le processus d’authentification, d’autorisation et de gestion de l’identité. Grâce au NameID, le SP recevant l’assertion SAML peut identifier de manière unique l’utilisateur et prendre des décisions en fonction de cette identification.

La propriété identifiante (encadré vert) définie lors de la synchronisation de votre annuaire avec Olfeo Saas doit être utilisée au niveau de l’attribut NameID. Aussi, il faut veiller à ce que le domaine (encadré rouge) soit correctement renseigné. A noter qu’Olfeo SaaS utilise par défaut le UserPrincipalName comme propriété identifiante.

Si vous avez défini lors de la synchronisation de votre annuaire que la propriété identifiante serait SamAccountName, vous devez modifier les revendications de votre IDP pour qu’il associe SamAccountName au NameID passé lors de la réponse d’authentification. Pour plus d’information sur ce sujet se reporter à la partie « Configurer et gérer des annuaires »

Émetteur :

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.

Signature Numérique :

L’assertion SAML doit être signée numériquement par l’IDP pour garantir son intégrité et son origine. La signature de l’assertion est le minimum requis, une réponse SAML signée avec assertion signée est aussi possible. Pensez à vérifier la présence du certificat et de la signature, ainsi que de l’utilisation de l’algorithme SHA 256 minimum. 

Conditions de Validité :

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).

Méthode d’Authentification :

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

Encodage :

Vérifiez que l’assertion SAML est correctement encodée (par exemple, base64) pour le transport.