C. Scénarios de mise en œuvre 27








télécharger 325.98 Kb.
titreC. Scénarios de mise en œuvre 27
page7/10
date de publication30.03.2017
taille325.98 Kb.
typeScénario
ar.21-bal.com > loi > Scénario
1   2   3   4   5   6   7   8   9   10

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.

  1. L’utilisateur navigue vers le site SharePoint 2010.

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

  2. L'utilisateur précise qu’il souhaite s’identifier avec un fournisseur OpenID.

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

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

  5. L’instance d’ACS 2.0 émet une requête d'authentification à destination du fournisseur OpenID et rediriger ainsi l’utilisateur vers ce dernier.

  6. Le fournisseur OpenID sélectionné demande l’identifiant OpenID de l’utilisateur et le mot de passe associé.

  7. Le fournisseur OpenID valide l’identité de l’utilisateur.

  8. Le fournisseur OpenID retourne une réponse d'authentification à l’instance d’ACS 2.0, avec la redirection associée.

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

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

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

  1. L'utilisateur précise qu’il souhaite s’identifier avec un fournisseur OpenID.

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

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

  4. L’instance d’ACS 2.0 émet une requête d'authentification à destination du fournisseur OpenID et rediriger ainsi l’utilisateur vers ce dernier.

  5. Le fournisseur OpenID sélectionné demande l’identifiant OpenID de l’utilisateur et le mot de passe associé.

  6. Le fournisseur OpenID valide l’identité de l’utilisateur.

  7. Le fournisseur OpenID retourne une réponse d'authentification à l’instance d’ACS 2.0, avec la redirection associée.

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

  9. 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.
1   2   3   4   5   6   7   8   9   10

similaire:

C. Scénarios de mise en œuvre 27 iconC. Scénarios de mise en œuvre 27

C. Scénarios de mise en œuvre 27 iconScénarios relatifs au service Web de mise à jour des appareils 13

C. Scénarios de mise en œuvre 27 iconCalendrier de mise en œuvre 14

C. Scénarios de mise en œuvre 27 iconScénario pédagogique. Pour de Lièvre, Quintin & Depover (2002), IL...
«activités», «tâches», «scénarios», …, se posent des questions de «granularité», de mise en scène et d’architecture

C. Scénarios de mise en œuvre 27 icon"Mise en œuvre de Cisco Unified Communication Manager"

C. Scénarios de mise en œuvre 27 iconPrincipes et conditions de mise en œuvre du protocole enum en France

C. Scénarios de mise en œuvre 27 iconThierry brugvin lipha, Paris Est la difficile mise en œuvre

C. Scénarios de mise en œuvre 27 iconLa mise en œuvre de la prime d’activité : un enjeu pour la Branche Famille

C. Scénarios de mise en œuvre 27 iconLa mise en œuvre d’une «mixité sociale» dans le parc hlm de la ville de Martigues

C. Scénarios de mise en œuvre 27 iconMéthodologie de mise en œuvre et problèmes posés par la première application de la réforme 2005








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com