• Identity Provider Discovery Service Protocol and Profile, OASIS
• IdP Discovery, Internet2
• Le WAYF de SWITCH
• SessionInitiator, configuration du SP Shibboleth

La fonction WAYF (Where Are You From) est définie par les développeur de Shibboleth et est spécifique à cette implémentation. Les autres implémentation SAML ne gèrent pas ce protocole.

L'objectif du service WAYF est de déterminer quel fournisseur d'identités sera contacté pour authentifier l'utilisateur. Le WAYF consiste en un menu déroulant, proposé à l'utilisateur, listant les fournisseurs d'identités disponibles. Dans le cadre d'une relation bilatérale (entre 1 SP et un IdP) ou dans certains cas où l'IdP est contacté en premier, le service WAYF n'est utilisé.

SAML2 normalise le protocole Discovery Service, équivalent au WAYF, à quelques variantes près.

Les points communs :

• comme pour le WAYF, l'appel au DS est initié par SP,
• l'ergonomie des implémentation actuelle est similaire au WAYF (un menu déroulant),
• les IdPs Shibboleth 1.x peuvent fonctionner avec un DS,

Les différences :

• le flux du protocole est légèrement différent (SP ⇒ DS ⇒ SP ⇒ IdP), voir le détail plus bas,
• les paramètres d'appel au DS sont légèrement différents de ceux du WAYF,
• l'utilisation du protocole SAML2 nécessite l'utilisation du DS (sauf relations bilatérales).

L'implémentation de SWITCH est capable d'agir en tant que WAYF et en tant que DS, sans paramétrage spécifique.

Cas du WAYF : SP ⇒ WAYF ⇒ IdP
Dans ce cas, c'est le WAYF qui redirigera l'utilisateur vers l'IdP. Le WAYF doit donc connaître l'URL du profil SSO urn:oasis:names:tc:SAML:1.0:profiles:browser-post de l'IdP. Le WAYF ne connait pas les URL des profils SAML2 des IdP.

Cas du DS : SP ⇒ DS ⇒ SP ⇒ IdP
Le Discovery Service se contente de sélectionner l'IdP à contacter, charge au SP de rediriger l'utilisateur vers l'IdP. Le SP est mieux armé pour effectuer cette tache, en prenant en compte les profils SAML supportés par chaque IdP (SAML2 ou Shib1). Pour déterminer quel profil utiliser pour chaque IdP, le SP utilise un chaînage de SessionInitiators.

Exemple de configuration pour un SP Shibboleth 2.x :

<SessionInitiator type="Chaining" Location="/DS" id="DS" isDefault="true" relayState="cookie">
  <SessionInitiator type="SAML2" defaultACSIndex="1” acsByIndex="false" template="bindingTemplate.html"/>
  <SessionInitiator type="Shib1" defaultACSIndex="5"/>
  <SessionInitiator type="SAMLDS" URL="https://discovery.renater.fr/test/wayf"/>
</SessionInitiator>

1. Lors de la première évaluation du SessionInitiator, le SP cherche à déterminer l'IdP à contacter ; il contacter le SAMLDS.
2. La chaîne de SessionInitiators est évaluée une seconde fois lors du retour du DS. On cherche alors à déterminer quel profil utiliser pour faire une demande d'authentification auprès de l'IdP. Si l'IdP a publié un point d'accès de type SAML2 (correspond à urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST), c'est ce protocole qui sera utilisé (les SessionInitiators sont ordonnés). Sinon, c'est le point d'accès Shib1 (correspond à urn:oasis:names:tc:SAML:1.0:profiles:browser-post) qui sera utilisé par défaut.

Actuellement les SP et les IdP Shibboleth supportant le protocole SAML2 continuent à échanger au moyen du protocole SAML1. En effet, le passage par un WAYF ne permet pas l'utilisation d'une demande d'authentification au format SAML2.

Pour généraliser l'utilisation du protocole SAML2, il faut utiliser un Discovery Service en lieu et place d'un WAYF. Pour ceux qui utilisent le WAYF de SWITCH, ses versions récentes reconnaissent également le protocole DS.

Les modifications à faire sont donc exclusivement du côté du SP qui doit modifier sa configuration (voir ci-dessus) pour utiliser le protocole Discovery Service.