La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

2 Architecture des applications et des services fondés sur la fédération d'identité et les revendications : une introduction Code Session : ARC203 Philippe.

Présentations similaires


Présentation au sujet: "2 Architecture des applications et des services fondés sur la fédération d'identité et les revendications : une introduction Code Session : ARC203 Philippe."— Transcription de la présentation:

1

2 2 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 Benjamin Guinebertière Architecte DPE Microsoft France Stéphane Goudeau Architecte DPE Microsoft France

3 3 Description de la session Les applications et les services sont de plus en plus déployés sur Internet plutôt que sur le réseau de l'entreprise et il devient donc nécessaire d'authentifier et d'autoriser à l'échelle de l'Internet non seulement sur la base d'identités d'entreprise et également vis-à-vis d'identités numériques sociales/grand public (Windows Live ID, Google, Facebook, Yahoo!, etc.). Les revendications (claims), jetons et la fédération sont les nouveaux moyens de modéliser l'authentification, le contrôle d'accès et la personnalisation pour d'applications et de services désormais distribuées. Les possibilités ainsi offertes sont vastes, mais il existe certains modèles (patterns) bien établis pour répondre à des scénarios de sécurité typiques. Il s'agit de lignes directrices pour l'utilisation de revendications, de fournisseurs d'identité, de services jeton de sécurité ressources, de passerelles de fédération et de "multi-tenancy". Cette session s'intéresse à des architectures courantes et montre comment utiliser Active Directory Federation Services 2.0, Azure AppFabric Access Control Services et Windows Identity Foundation (WIF) pour exploiter la puissance d'une sécurité basée sur les revendications.

4 4 La fédération didentité dans le cadre des Microsoft TechDays 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

5 5 Les technologies Microsoft qui rendent possible lidentité 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

6 6 Une lecture recommandée à titre de complément

7 7 Lauthentification fédérée Lexemple décole

8 8 De nombreuses alternatives en termes darchitecture (à partir de la page 17)

9 9 Active Directory ClientPartie de confiance Contrôleur de domaine 1 2 Kerberos Service Ticket preuve revendications nom : philber, groupes: … Cadre de confiance

10 10 Les limites dActive Directory dans le contexte Représentation limitée de lidentité Appels au service d'annuaire entreprise Application non membre du domaine (DMZ, Cloud, externe) Application qui ne prend pas en charge lauthentification intégrée Windows Les clients doivent être sur lintranet (et ont besoin d'un compte AD)

11 11 Lauthentification fédérée ClientPartie de confiance Service de jetons de sécurité (STS) 1 2 Jeton signature revendications nom: philber, rôles: … … Cadre de confiance

12 12 Scénarios 1.Fournisseur didentité interne 2.Fournisseur didentité et STS-Ressource 3.Fédération avec des partenaires 4.Logiciel en tant que service (Software as a Service) 5.Solutions pour le Cloud

13 13 Scénario 1 : Fournisseur didentité interne Service de jeton de sécurité (STS) qui émet des jetons contenant des informations d'identité Connecté avec le service dannuaire Réduit la quantité de "code de sécurité" dans les applications Prérequis pour lensemble des autres scénarios (de fédération)

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

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

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

17 17 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 daccès centralisé Intégration avec les systèmes de gestion didentité tiers

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

19 19 Scénario 1.3: Mobilité Et si lutilisateur avec un compte AD se trouve à lextérieur de lentreprise? Et si le service exposé est à lextérieur de lentreprise ? DMZInterne Cadre de confiance Proxy AD FS 2.0 AD FS 2.0 Internet 1 2 Client Partie de confiance

20 20 Scénario 1.4 : Problèmes Le fournisseur didentité est une composante logique dActive Directory Administré par les "Administrateurs dentreprise" 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 aujourdhui

21 21 Scénario 2 : Fournisseur didentité et STS-Ressource Séparation des préoccupations Revendications centrées sur lidentité vs. Revendications centrées sur lapplication Différents "domaines" dadministration Réduction du jeu de revendications aux seules revendications pertinentes pour l'application Fournisseur didentité STS-Ressource Cadre de confiance Revendications Identité Revendications Application Administrateurs de domaine Administrateurs de lapplication

22 22 Scénario 2 (illustré) Fournisseur didentitéSTS-Ressource Cadre de confiance

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

24 24 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 Identité EnterpriseAutorisation SiteDonnées App Département Cadre de confiance Application Cadre de confiance

25 25 Scénario 2.3 : Consommer des services externes Les partenaires externes ont simplement besoin de faire confiance au fournisseur didentité de lentreprise Projection de lidentité dentreprise vers les partenaires externes Cadre de confiance Partenaires externes Services Cloud

26 26 Démo 3 Délégation de lauthentification par SharePoint 2010 Fournisseur didentité : STS AD FS AD DS Partie de confiance : SharePoint 2010 (via STS interne SharePoint (= STS de ressources) ) Cf. Session SEC2306 aujourdhui de 16h00 à 17h00

27 27 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 Revendications requises : nom, département Partenaire 2 : id, centre de coût Partenaire n : x, y

28 28 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 langage de transformation/génération de revendications Habituellement derrière un proxy Partenaire 1 Partenaire 2 Partenaire n Revendications transformées DMZInterne Cadre de confiance Proxy AD FS 2.0 / UAG 2010 SP1 AD FS 2.0

29 29 Scénario 3.2 : Découverte du domaine dorigine Une problématique pour les applications Web fédérées Comme lapplication connait/détermine doù vient lutilisateur ? Les pages dauthentification AD FS 2.0 peuvent être personnalisées

30 30 Démo 4 Collaboration fédérée dans lentreprise étendue Fournisseur didentité : 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 ))

31 31 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

32 32 Scénario 4 (illustré) Cadre de confiance App/Services Web Clients Entreprise AD FS 2.0 Fournisseur didentité "Petits structures" Client "Petits structures" Yahoo! Google Live ID Facebook …

33 33 Scénario 4.1: Découverte du domaine dorigine et respect de la vie privée Peut-être que vous ne voulez pas exposer la liste de vos clients Peut-être est-ce même une exigence métier Pas une problématique pour les clients actifs Le paramètre WS-Federation home realm peut aider dans les scénarios passifs https://www.saas.com/[id_client_genere] https://rsts/adfs/ls/?wa=wsignin1.0&wtrealm=https://www.sa as.com&whr=[uri_émetteur_du_client] Recherche Id vers URI

34 34 Une illustration : FabrikamShipping SaaS

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

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

37 37 Démo 6 Accès à une application de lentreprise dans Windows Azure Fournisseur didentité : STS AD FS AD DS (authentification intégrée WIA) Partie de confiance : ASP.NET/WIF 1.0 dans Windows Azure

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

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

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

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

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

43 43 En guise de conclusion Passer à un état desprit axé sur les revendications est crucial Mais la migration en douceur est possible dans la plupart des situations La fédération didentité 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 dorigine, etc.) simpose

44 44 Plus dinformations Groupe "Forum des architectures applicatives Microsoft" Ce forum regroupe des architectes en informatique qui ont des choix de technologies à faire dans les projets pour lesquels ils travaillent. Larchitecte 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. Larchitecte applicatif a aussi pour rôle de faire le lien entre les équipes de développement et les équipes dinfrastructure et dexploitation de la future application. Il doit également veiller à ce que ses choix soient bien mis en œuvre pendant le développement. Ce forum, à linitiative de Microsoft France, a pour but daider les architectes applicatifsCe forum, à linitiative de Microsoft France, a pour but daider les architectes applicatifs A faciliter la connaissance de loffre de Microsoft pour les projets en entreprise (envoi de liens vers des présentations, documents, webcasts, conférences, …), mais égalementA faciliter la connaissance de loffre 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 darchitecture 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é dune application développée pour linformatique en nuage, quelles sont les implications dun déploiement sur une ferme Web, …).A échanger sur des problématique darchitecture 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é dune application développée pour linformatique en nuage, quelles sont les implications dun déploiement sur une ferme Web, …). Cet espace est le vôtre, faites le vivre, nous sommes aussi et surtout là pour vous lire.Cet espace est le vôtre, faites le vivre, nous sommes aussi et surtout là pour vous lire.

45 45 Plus dinformations Guide "A Guide to Claims–based Identity and Access Control" Livres blancs "AD FS 2.0 Step-by-Step and How To Guides" 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é 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

46 46 Plus dinformations Identity Developer Training Kit Cours MSDN associé : Windows Azure Platform Training Kit Cours MSDN associé :

47 47 Plus dinformations Portail Microsoft France Interopérabilité Portail Microsoft Interopérabilité Portail Port 25 Portail "Interop Vendor Alliance" Portail "Interoperability Bridges and Labs Center" Weblog

48 48 Questions / Réponses

49 49 MSDN et TechNet : lessentiel des ressources techniques à portée de clic Portail administration et infrastructure pour informaticiens Portail de ressources technique pour développeurs

50


Télécharger ppt "2 Architecture des applications et des services fondés sur la fédération d'identité et les revendications : une introduction Code Session : ARC203 Philippe."

Présentations similaires


Annonces Google