code session : arc203

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 BeraudArchitecteDirection TechniqueMicrosoft [email protected]

Benjamin GuinebertièreArchitecteDPEMicrosoft [email protected]

Stéphane GoudeauArchitecteDPEMicrosoft [email protected]

4

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

5

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

6

Une lecture recommandée à titre de complément

• http://tinyurl.com/claimsguide

7

L’authentification fédérée

• L’exemple d’école

http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf (page 17)

8

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

9

Active Directory

Client Partie de confiance

Contrôleur de

domaine

1

2

KerberosServiceTicket

preuve

revendications nom : philber, groupes: …

Cadre de confiance

10

Les limites d’Active Directory dans le contexte

Représentation limitée de l‘identité

Appels au service d'annuaire entreprise

Application non membre du domaine(DMZ, Cloud, externe)

Application qui ne prend pas en charge l’authentification intégrée Windows

Les clients doivent être sur l’intranet (et ont besoin d'un compte AD)

11

L’authentification fédérée


Service de jetons de sécurité

(STS)

1

2

Jeton

signature

revendications nom: philber, rôles: … …

Cadre de confiance

12

Scénarios

1. Fournisseur d’identité interne2. Fournisseur d’identité et STS-Ressource3. Fédération avec des partenaires4. Logiciel en tant que service (Software as a

Service)5. Solutions pour le Cloud

13

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)

14

Scénario 1 (illustré)


Service de jetons de sécurité

(STS)

1

2

Jeton

signature

revendications nom : philber, rôles : … …

Cadre de confiance

15

Démo 1Dé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

16

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

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 d’accès centralisé• Intégration avec les systèmes de gestion d’identité

tiers

18

Démo 2Dé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

19

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 ?

DMZ Interne

Cadre deconfiance

Proxy AD FS 2.0 AD FS 2.0

Internet

1

2

Client

Partie de confiance

20

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

21

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

Cadre de confiance

Revendications Identité Revendications Application

Administrateurs de domaine Administrateurs de l‘application

22


Fournisseur d‘identité STS-Ressource

12

3

4

Cadre de confiance

Cadre de confiance

23

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

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é Enterprise Autorisation Site Données App Département

Cadre de confiance

Cadre de confiance

Application

Cadre de confiance

25

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

Cadre de confiance

Cadre de confiance

Partenaires externes

Services Cloud

26

Démo 3Dé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

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

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

DMZ Interne

Cadre de confiance

Proxy AD FS 2.0/ UAG 2010 SP1 AD FS 2.0

29

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

30

Démo 4Collaboration 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))

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


Cadre de

confiance

App/Services Web

Clients Entreprise

AD FS 2.0

Fournisseur d’identité"Petits structures"

Client "Petits structures"

1

2

3

1

2

Yahoo!GoogleLive IDFacebook …

34

Une illustration : FabrikamShipping SaaS

• http://www.fabrikamshipping.com/

35

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

36

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

37

Démo 6Accè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

38

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

Cadre de confiance

Passerelle de fédération nuage

ApplicationCloud

Cadre de confiance

39

Scénario 5.2 : Fédération avec le service de contrôle d’accè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

Démo 7Accè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)

41

Démo 8Accè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)

42

Internet

Plateforme

@ 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, SampleCustomerService

Tomcat 6ShibbolethAD LDS

Windows Server 2008 R2

Linux Debian




Windows 7

Tomcat 6ShibbolethInternet

ExplorerOffice 2010Visual Studio 2010

Internet

Application

Azure

43

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

44

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.

45

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

46

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

47

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/

48

Questions / Réponses

49

MSDN et TechNet : l’essentiel des ressources techniques à portée de clic

http://technet.com http://msdn.com

Portail administration et infrastructure pour informaticiens

Portail de ressources technique pour développeurs

code session : arc203

Documents