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

Philippe Beraud Consultant principal Direction Technologies et Sécurité © 2005 Microsoft Corporation Fédération didentité 1.

Présentations similaires


Présentation au sujet: "Philippe Beraud Consultant principal Direction Technologies et Sécurité © 2005 Microsoft Corporation Fédération didentité 1."— Transcription de la présentation:

1 Philippe Beraud Consultant principal Direction Technologies et Sécurité © 2005 Microsoft Corporation Fédération didentité 1

2 2 Quest-ce que lidentité numérique ? Un ensemble de claims qui caractérise une personne ou une « chose » (sujet numérique) dans le monde numérique Une claim est une déclaration faite sur quelquun/quelque chose par quelquun/quelque chose Une claim constitue une assertion de la vérité de quelquun/quelque chose Les claims sont exigées pour les transactions dans le monde réel et en ligne Les claims sont véhiculées dans des jetons de sécurité qui transitent entre les frontières de processus et de machines

3 3 Les leçons tirées de Passport Passport a été conçu pour résoudre deux problèmes Fournisseur didentité sur MSN +250 millions dutilisateurs, 1 milliard de logons par jour Fournisseur didentité sur Internet Un échec La leçon : la solution aux problèmes de la gestion des identités doit être différente de Passport

4 4 Quelques leçons du passé Une technologie unique avec un fournisseur unique de solution ne constitue pas une approche que le marché est prêt à accepter Une technologie unique avec de multiples fournisseurs na pas, à ce jour, été déployée de manière universelle Plusieurs fournisseurs avec plusieurs technologies implique immanquablement peu dinteropérabilité Ny a-t-il aucune solution envisageable ?

5 5 Les 7 lois de lidentité 1.Contrôle et consentement de lutilisateur 2.Divulgation minimale pour un usage défini 3.Présence justifiée des parties en présence 4.Support didentités publiques et privées 5.Pluralisme des opérateurs et des technologies 6.Prise en compte de lhumain 7.Expérience cohérente entre les contextes Rejoignez les discussions sur Etablies au travers dune dialogue avec lindustrie

6 6 Notion de méta-système didentité Aujourdhui : de multiples identités… et de multiples formats Un méta-système didentité est un cadre de travail qui unifie le monde de Plusieurs technologies didentité Plusieurs opérateurs Plusieurs implémentations Un méta-système didentité permet aux utilisateurs de gérer et de choisir leur(s) identité(s) dans un monde hétérogène Choix de la technologie Choix du fournisseur (soi-même, entreprise privée, état, etc.) Approche cohérente vis-à-vis de lutilisation de multiples systèmes didentité Supprime les frictions sans pour autant requérir que tout le monde saccorde sur une unique technologie didentité quelque soit lusage Capitalise sur les succès présents Offre un chemin de migration simple du passé au futur

7 7 Caractéristiques dun méta-système Possibilité de négociation Encapsulation Transformation des claims Expérienceutilisateur Permet au consommateur didentité, au sujet et au fournisseur didentité de négocier les exigences en termes de politiques techniques Mécanisme agnostique déchange des politiques et des preuves didentités entre fournisseur et consommateur didentité Mécanisme de confiance pour échanger les claims didentités quel que soit les formats des jetons didentité Interface homme – machine cohérente quels que soient les systèmes et les technologies Besoins dun méta-système didentité

8 8 WS-*, une architecture pour un méta-système didentité Architecture composable pour les services Web Large participation de lindustrie Architecture ouverte fondée sur des standards Disponible sans royalties Neutralité par rapport aux formats de jetons de sécurité La spécification OASIS WS-Security 2004 constitue la base x509, Kerberos, SAML 1.1, 1.2, 2.0, XrML, etc. Système dynamique pour échanger des claims WS-MetadataExchange, WS-SecurityPolicy, etc. Transformation de jetons et de claims WS-Trust définit une composante clé, le service de jetons de sécurité (Security Token Services ou STS) Toutes les spécifications principales sont des standards de lOASIS (ou du W3C) ou sur le point de lêtre

9 9 Consommateur didentité Sidentifie via un mécanisme cryptographique certain Lutilisateur peut décider si le consommateur didentité est bien celui que lutilisateur sattend à être Les claims communiquées sont explicitement chiffrées à destination de cette identité Exprime les exigences en termes didentité pour un service Une liste de claims Une liste de fournisseurs didentité admissibles (y compris les auto-générés) Une liste des formats de jetons recevables Pour sinsérer dans le méta-système didentité Définir une politique à laide de WS-SecurityPolicy Supporter la consultation de la politique via le protocole WS- MetadataExchange Véhiculer les jetons de sécurité dans le protocole applicatif via le protocole WS-Security

10 10 Fournisseur didentité Produit les jetons de sécurité Définit les conditions pour produire le jeton, à savoir les crédentiels nécessaires, si le consommateur didentité doit être nommé Pour sinsérer dans le méta-système didentité Implémenter un service de jetons de sécurité Supporter le protocole WS-Trust Request for Security Token (RST) Request for Security Token Response (RSTR) Peut sintégrer avec un système didentité existant Sadapter à un système SAML existant Sadapter à un déploiement de cartes à puces existant Peut sexécuter sur nimporte quel périphérique Serveurs, PCs, périphériques mobiles

11 11 Sélecteur didentité Affiche lidentité du consommateur didentité Facilite lauthentification à 2 sens Obtient les exigences du consommateur didentité Affiche la politique dusage du consommateur didentité Affiche les identités numériques disponibles vis-à-vis des consommateurs didentité (depuis les fournisseurs didentité) sous forme de carte Fondé sur la métaphore du monde réel des cartes physiques Carte didentité, permis de conduire, carte bancaire, carte de membre, etc. Lutilisateur sélectionne la carte à présenter au consommateur didentité Expérience cohérente et prédictible quels que soient les fournisseurs et consommateurs didentité Lutilisateur doit donner son consentement avant de divulguer ses claims « Contrôle et consentement de lutilisateur » – 1ère Loi de lidentité

12 12 Carte Fournisseurdidentité Service de jetons de sécurité Fabrikam Les valeurs des claims sont détenues au niveau du fournisseur didentité Name: Jeans Card Expires: 9/15/2006 Image Issuer: Fabrikam Supported Claims: { GivenName LastName AddressCity … } Issuer Token Service EPRs Supported Token Type: { SAML 1.1 } … Jean Dupond Exp 9/15/2006 Jeans Card Fabrikam

13 13 Carte Représentation visuel dune identité numérique Une carte nest PAS un jeton de sécurité Artefact qui représente la relation de délivrance dun jeton entre lutilisateur et le fournisseur didentité correspondant Une carte contient des métadonnées pour lobtention dun jeton de sécurité dun fournisseur didentité Type de jetons de sécurité, Claims supportés, Adresse du fournisseur didentité, Crédentiels exigés Le jeton de sécurité délivré par le fournisseur didentité est soumis au consommateur didentité par lutilisateur Fait de lutilisateur un participant actif de lutilisation didentité Consentement et contrôle Etablit une confiance mutuelle entre lutilisateur et les services accédés Atténue le risque de phishing et de vol didentité Expérience utilisateur cohérente Entre les cartes auto-générées et les cartes gérées Entre les scénarios « A la maison » et « Au travail » (domaine and sans domaine)

14 14 Comment tout cela fonctionne-t-il ? Applicationcliente Consommateur didentité Politique Fournisseurdidentité Service de jetons de sécurité Politique 2 Lecture de la politique définissant les preuves requises et les fournisseurs didentité : « Je souhaiterais recevoir un jeton contenant givenName et lastName dont le tokenType est SAML 1.1, émis par nimporte qui » Sélecteur didentité 3 Filtrage des cartes qui pourraient satisfaire les exigences du consommateur didentité 4 Lutilisateur sélectionne une carte depuis la liste des identités appropriées dans le sélecteur didentité 6 Le fournisseur didentité produit le jeton de sécurité contenant les preuves requises Jeton 1 Accès à la Ressource 7 Lapplication relaye le jeton de sécurité au consommateur didentité 5 Le sélecteur didentité présente les crédentiels au fournisseur didentité et demande un jeton de sécurité Crédentiels

15 15 Protocoles utilisés Fournisseurdidentité Service de jetons de sécurité Consommateur didentité Politique Applicationcliente WS-SecurityPolicy WS-SecurityPolicy WS-MetadataExchange,WS-Security WS-MetadataExchange, WS-Security, WS-Trust Sélecteur didentité

16 16 « InfoCard » comme sélecteur didentité Permet à lutilisateur de participer dans le méta-système didentité Composant de Windows Communication Foundation (WCF) dans WinFX Utilisable par nimporte quelle application, implémenté comme sous-système sécurisé Dialogue de crédentiels Windows commun Axes de conception Respect des « Lois de lidentité » Respect de la vie privée Par défaut, le fournisseur didentité napprend rien des habitudes dun utilisateur entre les différents services et sites Lutilisateur est conscient de lutilisation faite de ses données Sécurité Chiffrement du stockage Chiffrement du jeton à destination du consommateur didentité Exécution dans un bureau distinct Ouverture Utilisation de protocoles standards et ouverts Neutralité par rapport aux formats de jetons de sécurité de façon à faciliter les rendez-vous entre consommateurs et fournisseurs didentité Jeu de claims extensible

17 17 InfoCard en action Consommateur didentité Runtime WCF Application Cliente (App WCF) IHello:Say() + Retourne : « Hello World, Jean! » Jeton Depuis « InfoCard » WS-Mex : WSDL, Politique WSDL + Politique Le message est sécurisé via le certificat Certificat organisationnel pour afficher les logos sujet et émetteur Point de Terminaison Point de Terminaison Mex

18 18 Implémentation Microsoft Complètement interopérable avec les protocoles publiés Avec dautres implémentations de sélecteur didentité Avec dautres implémentations de consommateur didentité Avec dautres implémentations de fournisseur didentité Disponibilité dun guide de mise en œuvre détaillé co-publié avec Ping Identity « A Guide to Integrating with InfoCard v1.0 », Août c5dcb86af6de/infocard-guide-beta2-published.pdf c5dcb86af6de/infocard-guide-beta2-published.pdf « A Technical Reference for InfoCard v1.0 in Windows », Août d47f91b66228/infocard-techref-beta2-published.pdf d47f91b66228/infocard-techref-beta2-published.pdf Ping Identity et dautres ont annoncé le support sur Linux, Unix, Apache, et dautres plateformes PingSTS

19 19 Construire un service consommateur didentité avec WCF WCF offre une implémentation de WS-MetadataExchange Limplémentation du service MEX est lURL de ladresse du point de terminaison du service suivi de /mex Consommateur didentité Runtime WCF Application Cliente (App WCF) IHello:Say() + Retourne : « Hello World, Jean! » Jeton Depuis « InfoCard » WS-Mex : WSDL, Politique WSDL + Politique Le message est sécurisé via le certificat Certificat organisationnel pour afficher les logos sujet et émetteur Point de Terminaison Point de Terminaison Mex

20 20 Construire un service consommateur didentité avec WCF Configurer un certificat InfoCard utilise le certificat pour le dialogue RIP (Réputation, Identité et Politique) Le jeton à destination du service sera chiffré avec la clé publique du service Spécifier le type de jeton dans la politique Type de jeton, jeu de preuves, exigences en termes de clés, émetteur, etc. Traiter le jeton Vérifier la signature de lémetteur, traiter les preuves, prendre des décisions dautorisation

21 21 Etape 1 - Configurer un certificat Informer WCF comment trouver le certificat du service …

22 22 Etape 1 - Configurer un certificat Inclure le certificat comme composante de lEPR du service Utilisé pour afficher le dialogue RIP sur le client Converti comme encodage base64 sur le réseau … … Le jeton de sécurité sera chiffré avec cette clé publique Le certificat avec les logos sujet/émetteur sera affiché dans le dialogue RIP

23 23 Etape 1 - Configurer un certificat Lier (1) wsHttpBinding (2) le comportement personnalisé du service et (3) lidentité ajoutée dans le point de terminaison … … …

24 24 Etape 2 - Spécifier le type de jeton dans la politique Ajouter la sécurisation des messages dans le « binding » Version courte avec wsHttpBinding et le type de crédentiels client « InfoCard » Le runtime WCF traduit le type de crédentiels client « InfoCard » en Emetteur : (Self) Preuves exigées : Address Type de jeton : SAML 1.1 Type de clé : symétrique, Taille de clé: 128 …

25 25 Etape 2 - Spécifier le type de jeton dans la politique Ajouter la sécurisation des messages dans le « binding » (serveur) Version complète avec wsFederationBinding Permet de spécifier un émetteur, un type de jeton, un jeu de preuves, un type de clé et dautres propriétés … … … … WS-SecurityPolicy vient ici

26 26 Etape 2 - Spécifier le type de jeton dans la politique Ajouter la sécurisation des messages dans le « binding » (serveur) Version complète avec wsFederationBinding …

27 27 Etape 3 - Traiter le jeton Lire le jeton de sécurité Ajouter une référence pour lassemblage System.Security.Authorization.dll « Using » pour C# : « Using » pour C# : using System.Security.Authorization; Modifier limplémentation de Hello:Say() public const String ClaimType =http://schemas.microsoft.com/ws/2005/05/identity/claims/ address;http://schemas.microsoft.com/ws/2005/05/identity/claims/ address public string Say() { AuthorizationContext ctx = OperationContext.Current.ServiceSecurityContext.AuthorizationContext; String identity = ; for(int i=0; i < ctx.Count; i++) { foreach(Claim claim in ctx[i]) { if (claim.ResourceType == ClaimType) { identity += claim.Resource.ToString(); break; } return Hello World + identity; }

28 28 Construire le client avec WCF Mettre en œuvre le « Runtime Binding » Ajouter une référence pour lassemblage System.Security.dll Utiliser le MetadataResolver pour obtenir le WSDL à laide de WS- MetadataExchange Le certificat du service est dynamiquement récupéré depuis les métadonnées du point de terminaison et ajouter aux crédentiels du canal La confidentialité et lintégrité sont assurées selon les exigences de la politique du service

29 29 Construire le client avec WCF Mettre en œuvre le « Runtime Binding » using System.ServiceModel.Design; … ChannelFactory cnFactory = null; // Create a MetadataResolver for retrieving metadata. EndpointAddress mexAddress = new EndpointAddress(http://www.fabrikam.com:4123/myService/mex);http://www.fabrikam.com:4123/myService/mex MetadataResolver mexProxy = new MetadataResolver(mexAddress); // Retrieve the metadata for all endpoints using metadata exchange protocol (mex). ServiceEndpointCollection endpoints = mexProxy.RetrieveEndpoints(); foreach (ServiceEndpoint ep in endpoints) { if (ep.Contract.Name.Equals(typeof(IHello).Name)) { cnFactory = new ChannelFactory (ep.Address, ep.Binding); // Set the server certificate as part of client's channel behavior ClientCredentials credentials = new ClientCredentials(); credentials.ServiceCertificate.Certificate = ((X509CertificateIdentity)ep.Address.Identity).Certificates[0]; cnFactory.Description.Behaviors.Add((IChannelBehavior)credentials); IHello chn = cnFactory.CreateChannel(); Console.WriteLine(chn.Say()); break; }

30 30 Construire un service fournisseur didentité avec WCF Créer un fichier carte (.CRD) pour chaque utilisateur La carte doit être signée La carte est délivrée en dehors de lexpérience utilisateur « InfoCard » Construire un service de jetons de sécurité (Security Token Service ou STS) Créer une politique (à savoir préciser comment le client sauthentifie, construire les exigences) Authentifier le client Traiter la demande de jeton, et créer le jeton

31 31 Etape 1 - Créer la carte …http://www.w3.org/2000/09/xmldsig# … … …Mmq95KmzT=ZxVp… … … … [EPR][,[Auth]]… … Inclus le certificat et la valeur de la signature Limage de la carte image apparaît dans « InfoCard » EPRs STS et comment sauthentifier

32 32 Etape 2 – Construire un service de jetons de sécurité Quest-ce quun service de jetons de sécurité (STS) ? Un service qui échange un jeton de sécurité pour un autre Ces deux jetons sont potentiellement différents (preuves, nombre de preuves, émetteur, type de jeton) Un STS qui implémente WS-Trust Request for Security Token (RST) Request for Security Token Response (RSTR) Le service Consommateur dIdentité peut se référer à un STS via le champs dans sa politique de sécurité De même, un STS peut également se référer à un autre STS Les fournisseurs et consommateurs didentité peuvent sappuyer sur N STSes

33 ded dc c&displaylang=en ded dc c&displaylang=en « Microsoft Federated Identity and Access Resource Kit for Sept 2005 Community Technology Preview »

34 34 Etape 2 – Construire un service élémentaire Avec Windows Communication Foundation Requête RST pour un jeton de sécurité « InfoCard » supporte 4 mécanismes dauthentification Nom dutilisateur/Mot de passe, Kerberos, certificat X509, carte auto-générée public const string ns = "http://schemas.xmlsoap.org/ws/2005/02/trust"; public const string IssueAction = ns + "/RST/Issue"; public const string IssueResponseAction = ns + "/RSTR/Issue"; [OperationContract(Action=IssueAction,ReplyAction=IssueResponseAction)] Message Issue(Message m) { RequestSecurityToken rst = RequestSecurityToken.CreateFrom( m.GetReaderAtBodyContents());... RequestSecurityTokenResponse rtsr = new RequestSecurityTokenResponse(…);... m.CreateReplyMessage(IssueResponseAction, rstr); }

35 35 Messages RST/RSTR Request Security Token (RST)... token here (WS-Security: UsernameToken, BinarySecurityToken) urn:oasis:names:tc:SAML:1.1 …[Card GUID Here] … …

36 36 Messages RST/RSTR Request Security Token Response (RTSR) … urn:oasis:names:tc:SAML:1.1 …... … …

37 37 Mettre tout ensemble 37

38 38 Implémentation Microsoft des services de jetons de sécurité Service de jetons de sécurité local InfoCard Emetteur : Type auto-généré, stocké localement Type de jeton supporté : SAML 1.1 Claims supportés : 12 claims Type de preuve de possession : symétrique, asymétrique Fonctionnalité de respect de la vie privé : La clé de signature varie dun consommateur didentité à un autre Futur : Active Directory STS Active Directory Federation Service (ADFS) de Windows Server 2003 R2 préfigure AD-STS

39 39 Active Directory Federation Services (ADFS) Intégrer aujourdhui le browser (client passif) dans le méta-système didentité Web Single Sign-On Intranet, Extranet et fédéré Applications « Claims-aware » Applications nécessitant un jeton NT Fonctionne avec les déploiements AD, AD/AM existants Extensible et interopérable Utilise WS-Trust pour la transformation des jetons Supporte les jetons Kerberos, X.509 et SAML 1.1 Sintègre avec les autorisations Authorization Manager (AzMan) Bel exemple de méta-systèmes didentité pour les clients passifs Fournisseur/Consommateur didentité interopérable Aujourdhui : BMC Federated Identity Manager/Web Access Manager, IBM Tivoli Federated Identity Manager, Oracle COREid Federation, Ping Identity PingFederate Courant 2006 : Citrix Access Suite, Computer Associates Identity Federation Solutions, d'Internet2 Shibboleth et RSA Federated Identity Manager/ClearTrust Consommateur didentité interopérable Quest VSJ, Centrify Direct Control, BMC Disponible ce mois

40 40 [1] HTTP GET par le browser à destination du serveur Web (WS)[1] Web SSO fédéré avec ADFS FS-A FS-P R WS FS-R Forêt intranet Forêt DMZ Fédération Pare-feu Client Relation de confiance établie « out-of-band » par léchange de certificats X.509 et de politiques de claims Articulation de lensemble de lauthentification autour du client pour les clients Browser FS-P A (int) FS-P A (ext) [2] Redirection HTTP 302 vers FS-P R Découverte du Royaume dAppartenance[2] [3] Redirection HTTP 302 vers FS-P A (int) Authentification de lutilisateur et demande de jeton[3] [4] Obtention des attributs par FS-A et construction du jeton(A)[4] [5] [5] Renvoi par FS-P A (int) du jeton(A) au browser HTTP POST par le browser du jeton(A) vers FS-P R [6] [6] Demande de validation du jeton par FS-P R Construction par FS-R dun jeton(R) à partir du jeton(A) [7] [7] Renvoi par FS-P R du jeton(R) au browser HTTP POST par le browser du jeton(R) à WS [8] [8] Renvoi par WS de la page

41 41 Web SSO fédéré avec ADFS 41

42 42

43 43 © 2005 Microsoft Corporation. Tous droits réservés. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.


Télécharger ppt "Philippe Beraud Consultant principal Direction Technologies et Sécurité © 2005 Microsoft Corporation Fédération didentité 1."

Présentations similaires


Annonces Google