c.3Scénarios B2C/G2C pour le grand public
Cette section reprend à titre d’illustration le premier scénario de collaboration fédérée envisagé entre organisations, à savoir l’accès à un site de collaboration grand public, et illustre comment une identité sociale peut facilement être utilisée dans ce contexte avec les mêmes fondations architecturales et techniques. Le propos est identique pour les autres types de ressources.
A titre d’illustration, l’utilisation d’un fournisseur OpenID pour l’authentification au niveau de SharePoint 2010 peut s’appuyer sur :
Un STS WIF personnalisé comme décrit dans la section § c.1.1.2 S’interfacer avec d’autres protocoles et standards). Le billet How to make use of a custom IP-STS with SharePoint 2010? (Part 1)102 décrit comment déclarer un tel STS avec SharePoint 2010 ;
Une personnalisation d’AD FS 2.0 comme décrit dans la section § c.1.2.2 S’interfacer avec d’autres référentiels, protocoles et standards.
Au-delà de ces approches qui demandent personnalisation et développement, le service ACS 2.0 peut directement être utilisé en lieu et place. Il ne s’agit alors que de simples configurations.
Il est supposé implicitement dans la configuration précédente qu’un serveur de fédération AD FS 2.0 contrôle l’accès à l’ensemble des ressources exposées par l’organisation. D’un point de vue technique, rien n’empêche d’établir un cadre de confiance directement entre le frontal SharePoint 2010 et le service ACS 2.0 dans le nuage. L’objectif ici consiste à montrer comment une configuration initialement mise en œuvre pour une collaboration entre organisations peut être facilement étendue par simple configuration pour offrir des accès à des identités sociales avec des permissions potentiellement différentes sur la base des revendications reçues.
Figure - Accès à SharePoint 2010 via ACS 2.0.
La Figure résume les interactions. La figure montre les interactions de façon conceptuelle. En réalité, toutes ces flèches sont des requêtes, redirections et réponses HTTP qui passent par le browser client.
L’utilisateur navigue vers le site SharePoint 2010.
Le site SharePoint 2010 détecte que l'utilisateur est anonyme et tente d'accéder à une page protégée. De ce fait et compte tenu de sa configuration, il émet une requête WS-Fed SignIn à destination du serveur de fédération AD FS 2.0 et redirige ainsi l’utilisateur vers ce dernier.
L'utilisateur précise qu’il souhaite s’identifier avec un fournisseur OpenID.
Le serveur de fédération AD FS 2.0 rediriger l’utilisateur vers l’instance configurée pour l’organisation du service ACS 2.0 dans le nuage.
Au niveau de la page de découverte de domaine de sécurité d’ACS, l'utilisateur précise son fournisseur OpenID comme Yahoo! par exemple.
L’instance d’ACS 2.0 émet une requête d'authentification à destination du fournisseur OpenID et rediriger ainsi l’utilisateur vers ce dernier.
Le fournisseur OpenID sélectionné demande l’identifiant OpenID de l’utilisateur et le mot de passe associé.
Le fournisseur OpenID valide l’identité de l’utilisateur.
Le fournisseur OpenID retourne une réponse d'authentification à l’instance d’ACS 2.0, avec la redirection associée.
L’instance d’ACS 2.0 extrait les revendications émises par le fournisseur OpenID et génère un jeton SAML avec les revendications OpenID. Elle renvoie une réponse WS-Fed SignIn avec le jeton SAML avec la redirection de l’utilisateur vers le serveur de fédération AD FS 2.0.
Le serveur de fédération AD FS 2.0 extrait les revendications émises par l’instance d’ACS 2.0 pour l’organisation et génère un jeton SAML à destination de la partie SharePoint 2010. Le serveur de fédération AD FS 2.0 renvoie une réponse WS-Fed SignIn avec le jeton SAML avec la redirection de l’utilisateur vers le site SharePoint 2010 accédée à l’origine.
Le STS interne de SharePoint récupère le jeton SAML, le valide et génère sur cette base un principal de sécurité. L'utilisateur peut accéder maintenant au site en fonction de ses permissions.
La même approche vaut également à l’identique pour une application Web de l’organisation située dans le nuage au sein de la plateforme Windows Azure.
La Figure résume les interactions. La figure montre les interactions de façon conceptuelle. En réalité, toutes ces flèches sont des requêtes, redirections et réponses HTTP qui passent par le browser client.
L’utilisateur navigue vers l’application Web de l’organisation située dans Windows Azure.
L’application considérée détecte que l'utilisateur est anonyme. De ce fait et compte tenu de sa configuration, elle émet une requête WS-Fed SignIn à destination du serveur de fédération AD FS 2.0 de l’organisation et redirige ainsi l’utilisateur vers ce dernier.
L'utilisateur précise qu’il souhaite s’identifier avec un fournisseur OpenID.
Le serveur de fédération AD FS 2.0 rediriger l’utilisateur vers l’instance configurée pour l’organisation du service ACS 2.0 dans le nuage.
Au niveau de la page de découverte de domaine de sécurité d’ACS, l'utilisateur précise son fournisseur OpenID comme Yahoo! par exemple.
L’instance d’ACS 2.0 émet une requête d'authentification à destination du fournisseur OpenID et rediriger ainsi l’utilisateur vers ce dernier.
Le fournisseur OpenID sélectionné demande l’identifiant OpenID de l’utilisateur et le mot de passe associé.
Le fournisseur OpenID valide l’identité de l’utilisateur.
Le fournisseur OpenID retourne une réponse d'authentification à l’instance d’ACS 2.0, avec la redirection associée.
L’instance d’ACS 2.0 extrait les revendications émises par le fournisseur OpenID et génère un jeton SAML avec les revendications OpenID. Elle renvoie une réponse WS-Fed SignIn avec le jeton SAML avec la redirection de l’utilisateur vers le serveur de fédération AD FS 2.0.
Le serveur de fédération AD FS 2.0 extrait les revendications émises par l’instance d’ACS 2.0 pour l’organisation et génère un jeton SAML à destination de l’application Web. Le serveur de fédération AD FS 2.0 renvoie une réponse WS-Fed SignIn avec le jeton SAML avec la redirection de l’utilisateur vers l’application Web dans Windows Azure accédée à l’origine.
Le Framework WIF récupère le jeton SAML, le valide et génère sur cette base un principal de sécurité. L'utilisateur peut accéder maintenant au site en fonction de ses permissions fondées sur les revendications reçues.
Figure - Accès à une application Web dans Windows Azure.
Comme cela a déjà été souligné, bien d’autres configurations sont aujourd’hui réalisables de façon à répondre à tel ou tel scénario.
|
