V20110111b date

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

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.

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

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

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

L’authentification fédérée 3/31/2017 5:37 AM L’authentification fédérée L’exemple d’école http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf (page 17) © 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

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

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

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

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

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

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)

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

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 date

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

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

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

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 de confiance 2 Partie de confiance

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

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

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

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

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

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

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

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

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

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 https://corp.sts.microsoft.com/onboard/adfsonboard.htm date

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

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

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

Scénario 4.1: Découverte du domaine d‘origine 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] Recherche Id vers URI https://rsts/adfs/ls/?wa=wsignin1.0&wtrealm=https://www.saas.com&whr=[uri_émetteur_du_client]

Une illustration : FabrikamShipping SaaS http://www.fabrikamshipping.com/ date

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

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

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

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

Scénario 5.2 : Fédération avec le service de contrôle d’accès (ACS v2) https://[servicenamespace].accesscontrol.windows.net/* Multiples protocoles et types de jetons Moteur de règles 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)

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)

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)

Plateforme @ MTC Paris Internet Internet Yahoo! Application Azure Facebook Application Azure Windows Live Google IDMGT.DEMO Azure AppFabric ACS IDMGT-OWA IDMGT-SPS Exchange Server 2010 SharePoint Server 2010, StarterSTS, SampleCustomerService 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

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

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.

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

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

Plus d’informations Portail Microsoft France Interopérabilité 3/31/2017 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/ © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. 47

Questions / Réponses SPEAKERS PLEASE NOTE: our standard timing for your availability for Q&A at the Ask- the-Experts pavilion will be the next lunch-break following your session, and variations from this standard will be scheduled based on your availability and for all Friday afternoon sessions.

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