Ce document présente sous forme de schéma la séquence d'échanges des principaux profils.

Les normes SAML et Shibboleth (cette dernière est basée elle-même sur SAML) offrent plusieurs modes d'utilisation, nommés “profils”. Ils définissent comment sont utilisés les messages SAML pour un contexte donné : requêter une authentification, réaliser du SSO, déconnexion globale, etc. Différents profils de SAML 1.1, Shibboleth 1 et SAML 2 sont présentés ci-dessous.

Une partie de ces profils utilisent des échanges SOAP directs entre SP et IdPs. Il s'agit notamment du profil browser/artifact et du profil browser/POST sans attribute push (pour ce second cas l'échange SOAP sert à requêter et récupérer les attributs). L'utilisation de ces profils compliquent la configuration de la brique IdP et obligent à lister dans les méta données les chaînes d'autorités de certification ayant émis les certificats des serveurs web des IdP répondant aux requêtes SOAP. Les développeurs de Shibboleth déconseillent leur utilisation (voir ce message du développeur du SP dans la liste shibboleth-users). À l'occasion d'une formation sur Shibboleth 2 auquel le CRU a assisté, Chad La Joie (développeur de l'IdP Shibboleth) a indiqué qu'il déconseillait aussi l'utilisation de back-channel, également pour des raisons de déploiement.

1. browser/artifact profile of SAML
2. browser/POST profile of SAML

Ces deux profils décrivent la séquence d'échanges HTTP qui transfèrent le navigateur jusqu'à un assertion consumer service du Service Provider. L'objectif est de transmettre une assertion d'authentification depuis l'IdP vers le SP. La présence de l'assertion d'authentification est obligatoire, d'autres assertions peuvent être ajoutée également. L'envoi d'attributs n'est pas décrit dans ces profils.

SAML V1.1 considère que l'utilisateur s'authentifie d'abord au niveau de l'IdP avant de se connecter au SP (les rédacteurs de SAML 1.1 considéraient des fédérations mono IdP).

Les deux profils se distinguent par la façon dont est transmise l'assertion d'authentification de l'IdP vers le SP.

Artifact : un artifact est une donnée transportée dans une query string d'URL (limitée en pratique par les navigateurs à 2000 caractères), et qui référence une assertion. Quand un SP récupère un artificat, il peut ensuite interroger l'IdP avec cette référence pour récupérer l'assertion.

Form POST : les assertions SAML sont transmises au navigateur dans un formulaire HTML. Quand l'utilisateur valide le formulaire (peut être fait automatiquement avec du JavaScript), elles sont transmises au SP dans le HTTP POST payload.

Séquence :

1. le navigateur fait un GET sur l'IdP avec en paramètre d'URL l'URL du SP vers lequel il souhaite se rendre ;
2. l'IdP authentifie l'utilisateur (par ex. avec un SSO) puis envoie au navigateur un formulaire HTML contenant la réponse SAML contenant l'assertion d'authentification (dans un champ hidden du formulaire). Cette réponse SAML doit être signée. L'attribut action du formulaire HTML est l'URL du assertion consumer du SP ;
3. le navigateur soumet le formulaire au SP, soit manuellement par l'utilisateur, soit automatiquement avec du JavaScript ;
4. le SP reçoit l'assertion d'authentification, la traite puis envoie une réponse HTTP au navigateur pour lui autoriser ou non l'accès.

Séquence :

1. le navigateur fait un GET sur l'IdP avec en paramètre d'URL l'URL du SP vers lequel il souhaite se rendre ;
2. l'IdP authentifie l'utilisateur (par ex. avec un SSO) puis répond au navigateur par une redirection HTTP vers une URL artifact receiver associé au assertion consumer service du SP. L'URL de redirection contient en paramètre un artifact (ou plusieurs) ;
3. le navigateur fait un GET sur cette URL (vers le SP donc) ;
4. le SP envoie une requête SAML à l'IdP en indiquant l'artifact ;
5. l'IdP répond à cette requête par une réponse SAML qui contient l'assertion correspondante. Cet échange 4 et 5 doit utiliser un protocole binding SAML d'échange de message requête-réponse SAML (pas plus de précision, mais un exemple est donné dans le document : 3.1.3.7 Example SAML Message Exchange Using SOAP over HTTP) ;
6. le SP reçoit l'assertion d'authentification, la traite puis envoie une réponse HTTP au navigateur pour lui autoriser ou non l'accès.

Les considérations de sécurité sont décrites dans “4.1.1.9 Threat Model and Countermeasures”.

Les profils de SAML 1.1 considèrent que l'utilisateur part de l'IdP. Pour prendre en compte les scénarios où l'utilisateur se connecte d'abord au niveau d'un SP, Shibboleth a étendu les profils SAML browser/POST et browser/Artifact.

Pour cela, Shibboleth :

1. définit la notion de requête d'authentification qui permet à un SP de demander à un IdP une authentification du navigateur ;
2. introduit la notion de WAYF (Where Are You From) qui permet à un navigateur de sélectionner son IdP ;
3. spécifie explicitement l'échange d'attributs (contrairement à SAML 1.1).

Comme pour les profils browser/POST et browser/Artifact de SAML 1.1, dans Shibboleth ces deux profils se distinguent “uniquement” par la façon dont l'assertion d'authentification est envoyée. Ci-dessous les étapes qui divergent sont celles soulignées.

Une requête d'authentification Shibboleth est un message encodé dans une URL et envoyé au SSO service endpoint d'un IdP. Il contient l'identifiant du SP (providerId), l'URL au assertion consumer service du SP (shire), l'adresse de retour vers le SP (target), et la date epoch d'émission de la requête. Le traitement d'une telle requête par l'IdP qui la reçoit est décrit précisément dans la norme Shibboleth.

Il enrichit le profil correspondant de SAML 1.1.

Séquence :

1. la navigateur requête une page protégée par le SP ;
2. le SP redirige le navigateur vers le WAYF (avec les paramètres d'une requête d'authentification Shibboleth) ;
3. le navigateur requête le WAYF avec ces paramètres ;
4. le WAYF renvoie un formulaire HTML (les paramètres de la requête d'authentification sont des champs hidden du formulaire) ;
5. l'utilisateur sélectionne un IdP dans la liste, le navigateur envoie une requête GET au WAYF ;
6. le WAYF redirige le navigateur vers l'IdP, avec dans l'URL les paramètres de la requête d'authentification ;
7. le navigateur requête l'IdP avec cette URL. L'IdP délègue à un service de SSO l'authentification de l'utilisateur ;
8. l'IdP envoie au navigateur un formulaire HTML contenant la réponse SAML contenant l'assertion d'authentification (voir profil SAML 1.1) ;
9. le navigateur soumet le formulaire au SP, soit manuellement par l'utilisateur, soit automatiquement avec du JavaScript ;
10. le SP traite l'assertion d'authentification, créé un contexte de sécurité et envoie vers l'IdP un message SAML SOAP contenant une requête d'attributs ;
11. l'IdP traite cette requête et renvoie dans la réponse SOAP une assertion d'attributs ;
12. le SP filtre les attributs, met à jour le contexte de sécurité et redigire le navigateur vers la page initialement requêtée par le navigateur ;
13. le navigateur requête la page ;
14. le SP renvoie la page.

Il enrichit le profil correspondant de SAML 1.1.

Les attributs sont fournis dans une assertion d'attributs envoyée en même temps que l'assertion d'authentification. Comme il s'agit de deux assertions différentes, deux artifact au lieu d'un seul sont utilisés.

Séquence :

1. la navigateur requête une page protégée par le SP ;
2. le SP redirige le navigateur vers le WAYF (avec les paramètres d'une requête d'authentification Shibboleth) ;
3. le navigateur requête le WAYF avec ces paramètres ;
4. le WAYF renvoie un formulaire HTML (les paramètres de la requête d'authentification sont des champs hidden du formulaire) ;
5. l'utilisateur sélectionne un IdP dans la liste, le navigateur envoie une requête GET au WAYF ;
6. le WAYF redirige le navigateur vers l'IdP, avec dans l'URL les paramètres de la requête d'authentification ;
7. le navigateur requête l'IdP avec cette URL. L'IdP délègue à un service de SSO l'authentification de l'utilisateur ;
8. l'IdP redirige le navigateur vers l'assertion consumer service du SP. Deux artificats sont suffixés à l'URL de redirection, un correspondant à l'assertion d'authentification, l'autre à l'assertion d'attributs ;
9. le navigateur requête l'assertion consumer service du SP ;
10. le SP traite la requête et envoie à l'IdP une requête SAML contenant les deux artifacts (sous forme d'une requête SOAP HTTP POST) ;
11. l'IdP répond en envoyant les deux assertions correspondantes au SP ;
12. le SP filtre les attributs, met à jour le contexte de sécurité et redigire le navigateur vers la page initialement requêtée par le navigateur ;
13. le navigateur requête la page ;
14. le SP renvoie la page.

Ils sont listés sur cette page.

Il est similaire aux profils Shibboleth browser/artifact et browser/POST dans le sens où la séquence débute au niveau du SP. La solution (WAYF par ex.) pour le choix de l'IdP n'est pas précisée. La redirection initiale du SP vers l'IdP n'est plus seulement possible via un HTTP redirect, mais aussi via un HTTP POST, ou Artifact. L'envoi de l'assertion d'authentification est effectuée soit via HTTP POST, soit via HTTP Artifact.

Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1

Shibboleth Architecture Protocols and Profiles

Profiles for the OASIS Assertion Security Assertion Markup Language (SAML) V2.0

Protocoles supportés dans l'IDP Shibboleth 4