C. Scénarios de mise en œuvre 27
télécharger 325.98 Kb.
|
c.2Scénarios B2B de collaboration fédérée entre organisationsCette 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 2010Le 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 :
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.
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 2010Outlook 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.
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.
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 RESTfulLe 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. |
