C. Scénarios de mise en œuvre 27








télécharger 325.98 Kb.
titreC. Scénarios de mise en œuvre 27
page6/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.2Scénarios B2B de collaboration fédérée entre organisations


Cette section illustre quelques-uns des scénarios de collaboration fédérée rendus aisément possibles avec les produits et technologies précédentes. Bien d’autres combinaisons peuvent être construites…

Avec des entreprises désormais étendues, ces scénarios illustrent comment les collaborateurs d’une organisation peuvent concrètement accéder à des ressources proposées par une autre organisation. Ces scénarios sont envisagés sous l’angle de produits et technologies Microsoft et non Microsoft. C’est le cas notamment pour la technologie utilisée pour les fournisseurs d’identités.

c.2.1Accès à un site de collaboration SharePoint 2010


Le support par AD FS 2.0 du protocole SAML 2.0 et sa capacité d’agir comme passerelle protocolaire entre les standards OASIS WS-Federation et SAML 2.0 (Cf. section § c.1.2.1 Vue d’ensemble) permet d’exposer très simplement un portail SharePoint 2010, qui utilise WS-Federation, à des fournisseurs d’identité s’appuyant sur SAML 2.0 pour la fédération des identités.

En effet, la plateforme SharePoint 2010 tire bénéfice du Framework WIF et externalise l’authentification en reposant sur la mise en œuvre d’un STS interne prenant en charge :

  • L’authentification Windows intégrée (NTLM ou Kerberos),

  • L’authentification par formulaire (Form Based Authentication en anglais ou FBA en abrégé),

  • L’authentification déléguée à un STS (de jeton d’identité) de confiance (Trusted Identity Token Provider dans la terminologie SharePoint 2010) sur la base du protocole WS-Fed Passive.

Quel que soit le mécanisme utilisé pour l’authentification, l’identité numérique résultante est ensuite représentée comme un ensemble de revendications.

Il suffit de déclarer le serveur AD FS 2.0 comme un STS de confiance vis-à-vis du STS interne de SharePoint. AD FS 2.0 agit comme un fournisseur de revendication vis-à-vis de SharePoint 2010 qui est un consommateur d’identité. La communication entre AD FS 2.0 et SharePoint 2010 et vice versa utilise le standard WS-Federation.

Dans le même temps, ce même serveur AD FS 2.0 agit comme un consommateur d’identité/fournisseur de service du fournisseur d’identité SAML 2.0. La communication entre AD FS 2.0 et le fournisseur SAML 2.0 et vice versa utilise le standard SAML 2.0.

Le livre blanc Guide étape-par-étape Collaboration fédérée avec Shibboleth 2.0 et SharePoint 201097. Propose une description complète de la mise en œuvre d’une telle configuration avec le projet Shibboleth 2 (en tant que système distribué sous licence de logiciel libre) dans le rôle de fournisseur d’identité. Cette version de Shibboleth propose une implémentation du standard SAML 2.0.



Figure - Accès à un site SharePoint 2010.

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 son domaine de sécurité.

  3. Le serveur de fédération AD FS 2.0 émet une requête d'authentification SAML 2.0 à destination du fournisseur d’identité Shibboleth 2 et redirige ainsi l’utilisateur vers ce dernier.

  4. Le fournisseur d’identité Shibboleth 2 demande à l’utilisateur ses crédentités.

  5. Le fournisseur d’identité Shibboleth 2 valide l’identité de l’utilisateur.

  6. Le fournisseur d’identité Shibboleth 2 retourne une réponse SAML 2.0 au serveur de fédération AD FS 2.0, avec la redirection associée.

  7. Le serveur de fédération AD FS 2.0 extrait les revendications émises par le fournisseur d’identité Shibboleth 2 et génère un jeton SAML à destination de la partie SharePoint 2010. Le STS 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 maintenant accéder au site en fonction de ses permissions.

c.2.2Accès à sa boîte aux lettres Outlook Web Access 2010


Outlook Web Access (OWA) 2010 (avec Exchange 2010) peut également être configuré de façon à reposer sur WIF pour obtenir un contexte de sécurité via le service C2WTS sur la base des revendications reçus (Cf. section § c.1.1.1 Vue d’ensemble).

Un cadre de confiance peut être établi entre WIF et un serveur de fédération AD FS 2.0 pour l’organisation considérée ; ce dernier vise à contrôler les ressources exposées par cette organisation vis-à-vis d’autre organisation partenaires. La communication entre le serveur AD FS 2.0 et la ressource OWA 2010/WIF et vice versa utilise le standard WS-Federation. Le livre blanc Exposing OWA 2010 with AD FS 2.0 to other organizations98 propose une vue d’ensemble de la configuration associée.

Le serveur AD FS 2.0 peut ensuite établir des cadres de confiance avec d’autres organisations utilisant les standards OASIS SAML 2.0 et/ou WS-Federation ou d’autres protocoles comme abordés précédemment.



Figure - Accès à sa boîte aux lettres OWA 2010.

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 OWA 2010 pour accéder à sa boîte aux lettres.

  1. L’application OWA 2010 configurée pour fonctionner avec les revendications via le Framework WIF 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 et redirige ainsi l’utilisateur vers ce dernier.

  2. L'utilisateur précise son domaine de sécurité.

  3. Le serveur de fédération AD FS 2.0 émet une requête d'authentification SAML 2.0 à destination du fournisseur d’identité Shibboleth 2 et redirige ainsi l’utilisateur vers ce dernier.

  4. Le fournisseur d’identité Shibboleth 2 demande à l’utilisateur ses crédentités.

  5. Le fournisseur d’identité Shibboleth 2 valide l’identité de l’utilisateur.

  6. Le fournisseur d’identité Shibboleth 2 retourne une réponse SAML 2.0 au serveur de fédération AD FS 2.0, avec la redirection associée.

  7. Le serveur de fédération AD FS 2.0 extrait les revendications émises par le fournisseur d’identité Shibboleth 2 et génère un jeton SAML à destination de la partie OWA 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 l’application OWA 2010 accédée à l’origine.

  8. Le Framework WIF récupère le jeton SAML, le valide et génère sur cette base un principal de sécurité. Il s’appuie pour cela sur le service WIF Claims to Windows Token Service (C2WTS en abrégé) pour constituer une identité Windows correspondant à sa boîte aux lettres. L'utilisateur peut accéder maintenant à l’application OWA 2010 et à sa boîte aux lettres.

c.2.3Accès à une application Web




Au-delà de ce qui a été mentionné précédemment à la section § c.1 Cadre d’illustration avec les technologies Microsoft, le livre blanc Single Sign-On from Active Directory to a Windows Azure Application Whitepaper99 illustre comment utiliser AD FS 2.0, avec le Framework WIF, et la plateforme Windows Azure pour atteindre une authentification unique entre des applications Web déployées à la fois en en entreprise et dans le nuage.

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.

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

  2. L'utilisateur précise son domaine de sécurité.

  3. Le serveur de fédération AD FS 2.0 émet une requête d'authentification SAML 2.0 à destination du fournisseur d’identité Shibboleth 2 et redirige ainsi l’utilisateur vers ce dernier.

  4. Le fournisseur d’identité Shibboleth 2 demande à l’utilisateur ses crédentités.

  5. Le fournisseur d’identité Shibboleth 2 valide l’identité de l’utilisateur.

  6. Le fournisseur d’identité Shibboleth 2 retourne une réponse SAML 2.0 au serveur de fédération AD FS 2.0, avec la redirection associée.

  7. Le serveur de fédération AD FS 2.0 extrait les revendications émises par le fournisseur d’identité Shibboleth 2 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.

c.2.4Accès à un service Web RESTful


Le billet Protecting and consuming REST based resources with ACS, WIF, and the OAuth 2.0 protocol100 propose un exemple de bout en bout qui montre comment utiliser OAuth avec ACS 2.0 et la nouvelle extension WIF OAuth mentionnée précédemment (cf. section § c.1.1.1 Vue d’ensemble).

La même approche de configuration s’applique pour un service Web RESTful non WCF à la condition que le socle technique propose un support du protocole OAuth comme en Java avec la bibliothèque OAuth for Java101.
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