Court-circuiter le WAYF/DS

Références :

Dans certains cas, il peut être utile de court-circuiter le service de découverte (WAYF ou DS) pour l'accès à une ressource. Exemple : l'utilisateur se connecte sur le portail de son établissement, puis accède à un périodique électronique extérieur. Ce fournisseur de services l'oriente vers un service de découverte. L'utilisateur considère cette phase comme redondante, puisqu'il a suivi un lien depuis le site de son établissement.

Les solutions techniques à ce problème consistent toutes à proposer dans le portail de l'établissement un lien particulier qui évitera le passage par le service de découverte.

La première solution, évoquée ci-dessous, a été largement utilisée par les établissements français. Par contre, cette solution n'est pas applicable au protocole SAML2. Or certains SP n'utilisent pas le logiciel Shibboleth et implémentent uniquement SAML2. Nous explorons donc d'autres options pour court-circuiter le service de découverte.

Dernières nouvelles : les développeurs de Shibboleth annoncent le support du IdP initiated dans la version 2.3.0 de l'IdP Shibboleth, voir ce mail de Scott Cantor du 3 février 2011.

1. Solution avec SAML1

Cette solution ne semble plus fonctionner avec les IdP Shibboleth 3.x. Nous vous recommandons de mettre en oeuvre l'alternative SAML2 documentée plus bas dans cette page.

La version du profil Browser/POST SAML 1, telle que implémenté dans Shibboleth, prévoit qu'une session d'authentification puisse être initiée au niveau de l'IdP. Le protocole WAYF exploite cette possibilité.

Nous vous proposons ci-dessous un formulaire permettant de construire une URL pour initier une session d'authentification en initiant un requête d'authentification SAML 1 auprès de l'IdP.

  • Adresse du service SSO de l'IdP (mentionné dans les méta données, dans l'attribut Location du noeud SingleSignOn de l'IdP) :
  • Adresse où renvoyer l'utilisateur, côté SP :
  • Identifiant du SP (mentionné dans les méta données, dans l'attribut entityID) :
  • Adresse du consomateur s'assertions du SP (mentionné dans les méta données, dans l'attribut Location du noeud AssertionConsumerService) :

Attention cette solution ne fonctionne pas avec certains navigateurs (dont IE7) si le lien ainsi construit ouvre une connexion dans une frame.

Inconvénients de cette solution :

  • elle ne fonctionne pas avec SAML 2, donc pas avec des SP qui n'implémentent que SAML 2

2. Solution avec SAML2

Depuis sa version 2.3.0 l'IdP Shibboleth propose un nouveau endpoint /idp/profile/SAML2/Unsolicited/SSO permettant d'initier une session d'authentification en fonction de paramètres passés dans l'URL (comme dans le cas SAML1). Ce endpoint est activé par défaut sur les IdP Shibboleth.

3. Solution côté SP : les lazy sessions

Références :

Le mécanisme des lazy sessions, spécifique au SP Shibboleth, permet de déclencher la phase d'authentification à l'initiative d'une application protégée. Mais l'API utilisée entre l'application et le SP consistant en des redirections HTTP, l'authentification peut être déclenchée depuis un site web tiers, en construisant l'URL appropriée. Par ailleurs, l'URL déclenchant l'authentification peut spécifier quel IdP sera contacté. Nous pouvons donc détourner le mécanisme des lazy sessions pour éviter le passage par le service de découverte lors de l'accès à un SP.

L'URL d'authentification est construite de la façon suivante :

  1. handler URL du SP
  2. +identifiant du sessionInitiator correspondant au discovery initiator
  3. +paramètre entityId pour spécifier l'identifiant de l'IdP à contacter
  4. +paramètre target pour spécifier l'URL du service vers lequel renvoyer l'utilisateur

Voici un exemple d'URL pour l'accès à la ressource de test, en s'authentifiant auprès de l'IdP de test de la Fédération :

https://test.federation.renater.fr/Shibboleth.sso/Login?entityID=https://test.federation.renater.fr/idp/shibboleth&target=https://test.federation.renater.fr/Shibboleth.sso/Session

Les inconvénients de cette solution :

  • elle nécessite de connaître l'identifiant du sessionInitiator, issu du fichier de configuration du SP shibboleth2.xml. Il faut également tenir compte de changements éventuels de configuration des session initiators.
  • elle ne s'applique qu'aux SP Shibboleth