1 / 48

Code Session : ARC203

Architecture des applications et des services fondés sur la fédération d'identité et les revendications : une introduction. Code Session : ARC203. Philippe Beraud Architecte Direction Technique Microsoft France philber@microsoft.com. Benjamin Guinebertière Architecte DPE

frederique-krish
Télécharger la présentation

Code Session : ARC203

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architecture des applications et des services fondés sur la fédération d'identité et les revendications : une introduction Code Session : ARC203 Philippe Beraud Architecte Direction Technique Microsoft France philber@microsoft.com Benjamin Guinebertière Architecte DPE Microsoft France bengui@microsoft.com Stéphane Goudeau Architecte DPE Microsoft France stephgou@microsoft.com

  2. La fédération d’identité dans le cadre des Microsoft TechDays 2011 • 2 sessions pour faire un point ensemble • Session ARC203 "Architecture des applications et des services fondés sur la fédération d'identité et les revendications : une introduction" • Cette session !! • Session SEC2306 "Utiliser Active Directory Federation Services 2.0 pour une authentification unique interopérable entre organisations et dans le Cloud" • Demain de 16h00 à 17h00

  3. Les technologies Microsoft qui rendent possible l’identité fédérée • Active Directory Federation Services 2.0 (AD FS 2.0) • Windows Identity Foundation (WIF) 1.0 • Azure AppFabric Access Control Services (ACS) V2

  4. Une lecture recommandée à titre de complément • http://tinyurl.com/claimsguide

  5. L’authentification fédérée • L’exemple d’école http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf (page 17)

  6. De nombreuses alternatives en termes d’architecture (à partir de la page 17)

  7. Active Directory revendications nom : philber, groupes: … Contrôleur de domaine preuve Kerberos Service Ticket 1 Cadre de confiance 2 Client Partie de confiance

  8. Les limites d’Active Directory dans le contexte Appels au service d'annuaire entreprise Représentation limitée de l‘identité Applicationnon membre du domaine (DMZ, Cloud, externe) Les clients doivent être sur l’intranet (et ont besoin d'un compte AD) Applicationqui ne prend pas en charge l’authentification intégrée Windows

  9. L’authentification fédérée revendications nom: philber, rôles: … … Service de jetons de sécurité (STS) signature Cadre de confiance 1 Jeton 2 Client Partie de confiance

  10. Scénarios • Fournisseur d’identité interne • Fournisseur d’identité et STS-Ressource • Fédération avec des partenaires • Logiciel en tant que service (Software as a Service) • Solutions pour le Cloud

  11. Scénario 1 : Fournisseur d’identité interne • Service de jeton de sécurité (STS) qui émet des jetons contenant des informations d'identité • Connecté avec le service d‘annuaire • Réduit la quantité de "code de sécurité" dans les applications • Prérequis pour l’ensemble des autres scénarios (de fédération)

  12. Scénario 1 (illustré) revendications nom : philber, rôles : … … Service de jetons de sécurité(STS) signature 1 Cadre de confiance Jeton 2 Client Partie de confiance

  13. Démo 1 Délégation de l’authentification pour une application Fournisseur d’identité : STS WIF 1.0 avec authentification par formulaire (FBA) Partie de confiance : ASP.NET/WIF 1.0

  14. Scénario 1.1 : Revendications d’identité • Quelles sont les bonnes revendications d’identité ? • Information pour identifier de façon unique le client • Information "difficile" à acquérir pour les applications • NE PAS mélanger les informations d’identité et applicatives W I F 1.0 Identité Données d’entreprise Données applicatives

  15. Scénario 1.2 : Bénéfices additionnels (AD FS 2.0) • Passerelle entre les protocoles de fédération pour les applications • Accès aux ressources externes pour unifier les informations d'identité • Contrôle d’accès centralisé • Intégration avec les systèmes de gestion d’identité tiers

  16. Démo 2 Délégation de l’authentification pour une application Fournisseur d’identité : STS AD FS 2.0 avec authentification par formulaire (FBA) Partie de confiance : ASP.NET/WIF 1.0

  17. Scénario 1.3: Mobilité • Et si l’utilisateur avec un compte AD se trouve à l’extérieur de l’entreprise? • Et si le service exposé est à l’extérieur de l’entreprise ? Internet DMZ Interne 1 Client Proxy AD FS 2.0 AD FS 2.0 Cadre deconfiance 2 Partie de confiance

  18. Scénario 1.4 : Problèmes • Le fournisseur d’identité est une composante logique d‘Active Directory • Administré par les "Administrateurs d‘entreprise" • Les services de jetons (STS) peuvent fournir des services applicatifs utiles • Revendications à destination des applications • Autorisation centralisée • Conflit historique entre les administrateurs et les développeurs • Tout comme dans Active Directory aujourd’hui

  19. Scénario 2 : Fournisseur d’identité et STS-Ressource • Séparation des préoccupations • Revendications centrées sur l’identité vs. Revendications centrées sur l’application • Différents "domaines" d’administration • Réduction du jeu de revendications aux seules revendications pertinentes pour l'application Fournisseur d’identité STS-Ressource Revendications Identité Revendications Application Cadre de confiance Administrateurs de domaine Administrateurs de l‘application

  20. Scénario 2 (illustré) Fournisseur d‘identité • STS-Ressource Cadre de confiance 2 1 Cadre de confiance 3 4

  21. Scénario 2.1 : Revendications Ressource • Quelles sont les bonnes revendications Ressource ? • Informations de personnalisation/d’autorisation • Information (stockée de façon centralisée) qui est pertinente pour de multiple applications Information Identité Information centrale Application • Information locale Application

  22. Scénario 2.2 : Chaîner les services de jetons (STS) • Le chaînage des services de jetons (STS) permet des scénarios plus complexes Cadre de confiance Cadre de confiance Cadre de confiance Identité Enterprise Autorisation Site Données App Département Application

  23. Scénario 2.3 : Consommer des services externes • Les partenaires externes ont simplement besoin de faire confiance au fournisseur d‘identité de l’entreprise • Projection de l’identité d’entreprise vers les partenaires externes Partenaires externes Cadre de confiance Cadre de confiance Services Cloud

  24. Démo 3 Délégation de l’authentification par SharePoint 2010 Fournisseur d’identité : STS AD FS 2.0 + AD DS Partie de confiance : SharePoint 2010 (via STS interne SharePoint (= STS de ressources)) Cf. Session SEC2306 aujourd’hui de 16h00 à 17h00

  25. Scénario 3 : Consommer des identités externes • Fournir des services aux partenaires fédérés requiert une analyse • Quel protocole utiliser ? Avec quel type de jeton ? • Quelles revendications sont nécessaires ? • Comment gérer la confiance ? Et la maintenir dans le temps Partenaire 1 : nom, département Partenaire 2 : id, centre de coût Partenaire n : x, y Revendications requises:nom, département

  26. Scénario 3.1 : Passerelle de fédération • Passerelle pour traduire les protocoles, les types de jeton et de revendication • AD FS 2.0 comporte un langagede transformation/génération de revendications • Habituellement derrière un proxy DMZ Interne Partenaire 1 Cadre de confiance • Partenaire 2 • Partenaire n Revendications transformées Proxy AD FS 2.0 / UAG 2010 SP1 AD FS 2.0

  27. Scénario 3.2 : Découverte du domaine d’origine • Une problématique pour les applications Web fédérées • Comme l’application connait/détermine d’où vient l’utilisateur ? • Les pages d’authentification AD FS 2.0 peuvent être personnalisées

  28. Démo 4 Collaboration fédérée dans l’entreprise étendue Fournisseur d’identité : Partenaire (Shibboleth 2, fédération Renater) Partie de confiance : SharePoint 2010 (via STS interne SharePoint, puis STS AD FS 2.0 (= passerelle de fédération))

  29. Scénario 4 : Logiciel en tant que service (SaaS) • "Vendre du logiciel (dans un Cloud) à des organisations" comme modèle • La meilleure intégration possible au niveau du client est cruciale pour le succès • Conceptuellement similaire au scénario précédent, mais avec défis propres et additionnels • Typiquement des systèmes multi-locataires (multi-tenancy) • Intégration au sein de la gestion utilisateur et du système de sécurité client • Certains clients peuvent ne pas disposer de services de jetons de sécurité (STS) • Protection de la vie privée des clients

  30. Scénario 4 (illustré) Yahoo! Google Live ID Facebook … • Fournisseur d’identité • "Petits structures" 1 2 AD FS 2.0 3 Client "Petits structures" Cadre de confiance 1 2 App/ServicesWeb Clients Entreprise

  31. Une illustration : FabrikamShipping SaaS • http://www.fabrikamshipping.com/

  32. Démo 5 Mise en place d’une souscription avec Fabrikam Shipping SaaS Authentification via Google Account pour la souscription 2 Souscriptions : Entreprise vs. Small and Business

  33. Scénario 5 : Aller vers le Cloud • Le Cloud est une option de plus en plus populaire pour l’hébergement d'applications/services Web • La fédération en tant que telle n’est pas un problème • La même approche/technique que pour les applications en entreprise (on-premise) s‘applique • Les passerelle/STS-Ressource ont également besoin d’être "Cloud-ifié" • Pas d’AD FS pour le Cloud • Azure AppFabric Access Control Service (ACS) v2

  34. Démo 6 Accès à une application de l’entreprise dans Windows Azure Fournisseur d’identité : STS AD FS 2.0 + AD DS (authentification intégrée WIA) Partie de confiance : ASP.NET/WIF 1.0 dans Windows Azure

  35. Scénario 5.1 : Infrastructure fondée sur le Cloud • Fournisseur d’identité au niveau du site client • Passerelle de fédération et applications dans le Cloud Passerelle de fédération nuage Cadre de confiance Cadre de confiance • Application Cloud

  36. Scénario 5.2 : Fédération avec le service de contrôle d’accès (ACS v2) https://[servicenamespace].accesscontrol.windows.net/* Moteur de règles Multiples protocoles et types de jetons Type de jeton sélectionné API REST, outils de gestion * Points de terminaison multiples pour les divers protocoles (c.à.d. WS-Trust, WS-Federation, WRAP, OpenId)

  37. Démo 7 Accès à une application dans Windows Azure avec une identité sociale contrôlée par l’entreprise Fournisseur d’identité : myopenid (OpenID) Partie de confiance : ASP.NET/WIF 1.0 dans Windows Azure (via STS ACS 2.0 puis STS AD FS 2.0)

  38. Démo 8 Accès à une application dans Windows Azure avec une identité sociale Fournisseur d’identité : Facebook Partie de confiance : ASP.NET/WIF 1.0 dans Windows Azure (via STS ACS 2.0)

  39. Plateforme@ MTC Paris Internet Internet Yahoo! Facebook Application Azure Windows Live Google Azure AppFabric ACS IDMGT.DEMO IDMGT-OWA IDMGT-SPS SharePoint Server 2010,StarterSTS,SampleCustomerService Exchange Server 2010 renater.fr Windows Server 2008 R2 Windows Server 2008 R2 IDMGTEXT.DEMO IDMGT-IP0 Tomcat 6 Shibboleth AD LDS IDMGT-IP1 Tomcat 6 Shibboleth IDMGT-DC IDMGT-WIN7 Internet Explorer Office 2010 Visual Studio 2010 • Active Directory • AD DS • AD CS • AD FS Windows Server 2008 R2 Linux Debian Windows Server 2008 R2 Windows 7

  40. En guise de conclusion • Passer à un état d’esprit axé sur les revendications est crucial • Mais la migration en douceur est possible dans la plupart des situations • La fédération d’identité devient une nécessité et accompagne le passage au cloud • Sa mise en œuvre est simple à réaliser et à maintenir • Une phase de conception (topologie, revendications, protocoles, découvertes de domaines d’origine, etc.) s’impose

  41. Plus d’informations • Groupe "Forum des architectures applicatives Microsoft" • http://bit.ly/archiappms • Ce forum regroupe des architectes en informatique qui ont des choix de technologies à faire dans les projets pour lesquels ils travaillent. • L’architecte applicatif, en situation de projet, travaille typiquement aux côtés de la direction de projet pour choisir et assumer des choix techniques en fonction des contraintes du projet (fonctionnalités, délais, ressources). Pour effectuer ces choix à bon escient, il doit connaître ce que le marché offre en termes de technologies. Cela peut prend typiquement deux formes : veille technologique continue, recherches dans le cadre du projet. • L’architecte applicatif a aussi pour rôle de faire le lien entre les équipes de développement et les équipes d’infrastructure et d’exploitation de la future application. Il doit également veiller à ce que ses choix soient bien mis en œuvre pendant le développement. • Ce forum, à l’initiative de Microsoft France, a pour but d’aider les architectes applicatifs • A faciliter la connaissance de l’offre de Microsoft pour les projets en entreprise (envoi de liens vers des présentations, documents, webcasts, conférences, …), mais également • A échanger sur des problématique d’architecture ayant un rapport, même partiel, avec la plateforme Microsoft (est-ce que AD FS 2.0 fonctionne dans un environnement SAMLP 2, comment se passe la réversibilité d’une application développée pour l’informatique en nuage, quelles sont les implications d’un déploiement sur une ferme Web, …). • Cet espace est le vôtre, faites le vivre, nous sommes aussi et surtout là pour vous lire.

  42. Plus d’informations • Guide "A Guide to Claims–based Identity and Access Control" • http://tinyurl.com/claimsguide • Livres blancs "AD FS 2.0 Step-by-Step and How To Guides" • http://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(WS.10).aspx • Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 Technologies • Using AD FS 2.0 for Interoperable SAML 2.0-based Federated Web SSO • AD FS 2.0 Federation with Microsoft Office 365 Beta • Livres blancs Site Microsoft France Interopérabilité • http://www.microsoft.com/france/interop/ressources/documents.aspx • Méta-système et mash-up des identités avec les produits et technologies Microsoft • Exposing OWA 2010 with AD FS 2.0 to other organizations

  43. Plus d’informations • Identity Developer Training Kit • http://bit.ly/cWyWZ2 • Cours MSDN associé : http://bit.ly/hz3ERI • Windows Azure Platform Training Kit • http://bit.ly/dj1VZu • Cours MSDN associé : http://go.microsoft.com/fwlink/?LinkID=207018

  44. Plus d’informations • Portail Microsoft France Interopérabilité • http://www.microsoft.com/france/interop/ • Portail Microsoft Interopérabilité • http://www.microsoft.com/interop/ • Portail Port 25 • http://port25.technet.com/ • Portail "Interop Vendor Alliance" • http://interopvendoralliance.com/ • Portail "Interoperability Bridges and Labs Center" • http://www.interoperabilitybridges.com/ • Weblog Interopérabilité@Microsoft • http://blogs.msdn.com/b/interoperability/

  45. Questions / Réponses

  46. MSDN et TechNet: l’essentiel des ressources techniques à portée de clic • Portail administration et infrastructure pour informaticiens • Portail de ressources technique pour développeurs http://technet.com http://msdn.com

More Related