1 / 47

Fédération d'identité et ADFS de Windows Server 2003 R2

Fédération d'identité et ADFS de Windows Server 2003 R2. Philippe Beraud Consultant Principal Microsoft France. Excellence de l’engineering. Mise à jour avancée. Conseils, Outils, Réponse. Isolation et résilience. La stratégie sécurité de Microsoft. Authentification,

elvin
Download Presentation

Fédération d'identité et ADFS de Windows Server 2003 R2

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. Fédération d'identité et ADFS de Windows Server 2003 R2 Philippe Beraud Consultant Principal Microsoft France

  2. Excellence de l’engineering Mise à jour avancée Conseils, Outils, Réponse Isolation et résilience La stratégie sécurité de Microsoft Authentification, Autorisation, Audit

  3. Sommaire • Tendances en matière d’identité • Identité et gestion du cycle de vie • Fédération d’identité • Active Directory Federation Services (ADFS) • Architecture et composants • Gestion des accès avec les Claims (Attributs Utilisateur) • Démonstration • Modèles de déploiement et de programmation • ADFS et héritage des spécifications des services Web avancés WS-* • Interopérabilité multi fournisseurs

  4. Tendances en matière d’identité • Le domaine de la gestion de l’identité numérique est en cours de consolidation avec des services et produits d’intégration d’identité • Gestion du cycle de vie et intégration sur-mesure • « Provisioning », « deprovisioning », synchronisation de l’identité (intégration/agrégation), modification de l’identité, audit, gestion des mots de passe, etc. • Mais il reste encore de nombreux domaines d’amélioration possibles • Annuaire virtuel, « Single Sign-On » d’entreprise, authentification à plusieurs facteurs, etc. • Au coeur des zones d’innovation et d’investissement se trouve la fédération d’identité • Face à l’adoption massive des services Web, l’arrivée des architectures fédérées est inévitable… • Car les services Web sont par essence des agents autonomes • Cette nature autonome des services Web met l’accent sur la gestion explicite des relations de confiance entre les applications • Cette nature autonome des services Web nécessite que des processus ou des systèmes qui étaient centralisés évoluent vers un système fédéré • Ceci s’applique non seulement aux identités de sécurité mais aussi aux annuaires de services et à l’administration des systèmes

  5. Vos Clients Vers la construction des systèmes connectés Vos Fournisseurs Votre Entité etvos Collaborateurs Vos Collaborateurs itinérants Vos Partenaires

  6. The agreements, standards, and technologies that make identity and entitlements portable across autonomous domains. The Burton Group Federated Identity allows customers, partners and end-users to use Web services without having to constantly authenticate or identify themselves to the services within their federation. This applies both within the corporation and across the Internet. Michael Beach, The Boeing Company, Catalyst 2003 Fédération d’identité • Crée une meilleure efficacité opérationnelle • Procure de nouvelles opportunités « business » pour les entreprises • Scénarios B2B émergeant de collaboration et de partage de données • Est au cœur de la problématique de la mise en place de l’administration électronique • Alimente naturellement la croissance du marché de la gestion de l’identité numérique • Services et produits de fédération interopérables

  7. Fédération d’identité • Nécessite de définir les termes de la relation de confiance entre entités • Relation « business », conditions et termes contractuels, gestion des clés, assertions, partage de politique, assurances techniques, exigences d’audit, etc. • Difficile à mesurer et à calibrer aujourd’hui • Trop ou pas assez de confiance placée dans l’autre entité • D’un point de vue technique, demande des mécanismes pour • Matérialiser la relation de confiance entre entités • Partage de clés symétriques, confiance dans une chaîne de certificats X509 • Pour valider que l’identité reçue (jetons de sécurité/assertions) provient d’un fournisseur d’identité de confiance et donc pour attester de l’authenticité de l’identité fournie • Nécessite de « parler » un protocole de sécurité commun • Typiquement des protocoles de sécurité standardisés via des organismes comme IETF, OASIS

  8. Active Directory Federation Services (ADFS) • Annoncé au TechEd’04 à SanDiego • Vision en termes d’authentification et d’accès Une ouverture de session unique et un accès sécurisé à tout (fonction de ses habilitations, accréditations et permissions) • Deux philosophies connexes complémentaires au sein de l’entreprise • Capitaliser sur l’identité Windows (Kerberos) aussi loin que possible • Étendre vers les « injoignables » avec des approches d’intégration d’identité comme Microsoft Identity Integration Server (MIIS) • Gestion du cycle de vie de l’identité • Version 1.0 disponible avec la version Windows Server 2003 Refresh (R2) au second semestre 2005 • Actuellement en Bêta 2 • Support des scénarios de gestion fédérée d’identité pour l’accès sécurisé aux applications Web du SI pour les partenaires (, fournisseurs) et clients en dehors de leur royaume de sécurité (p. ex. domaine/forêt) • « Étendre Active Directory au-delà de la forêt » • Livre blanc « Active Directory Federation Services: A Path to Federated Identity and Access Management » • http://download.microsoft.com/download/3/a/f/3af89d13-4ef4-42bb-aaa3-95e06721b062/ADFS.doc

  9. Quelques définitions… • Jetons de sécurité • Bases pour une authentification et une autorisation distribuées • Les jetons de sécurité définissent des affirmations (claims) faites au sujet d’une identité, d’aptitude ou de privilèges • Nom, adresse mèl, clé, groupe, rôle, etc. • Attributs/propriétés de sécurité • Quelques exemples • Signé • Certificat X.509, ticket Kerberos, assertion SAML, licence XrML, etc. • Exigence ou non d’une preuve de possession • Clé secrète, mot de passe

  10. Quelques définitions… • Service de jetons de sécurité • Un service de jetons émet des jetons de sécurité • Un service de jeton peut « échanger » des jetons lorsque la requête traverse les frontières de royaumes de sécurité Centre de distribution des clés Ticket Kerberos contenant des claimsSID= S-1-5-21-3485267726-192398...UPN=johndoe@adatum.com Service de jetons de sécurité Jeton SAML contenant des assertions Company=A.DatumRole=Purchasing Agent

  11. Portail Fédération d’identité en action Claimsapplicatifs Claims de fédération SIDs/Attributs Serveur de fédération Serveur de fédération Active Directory Eric Serveur Web Trey Research Inc. A. DatumCorp • L’utilisateur A. Datum accède le portail A. Datum pour accéder à l’application Ordering de Trey Research • L’utilisateur A. Datum est redirigé vers le STS A. Datum • Authentification transparente avec Active Directory et l’authentification intégrée Windows (ticket Kerberos) • L’utilisateur A. Datum obtient du STS A. Datum une assertion SAML pour le STS Trey Research • Claimsde fédération relatifs au cadre de confiance entre A. Datum et Trey Research • L’utilisateur A. Datum obtient du STS Trey Research une assertion SAML pour l’application • Claimsspécifiques à l’application Ordering de Trey Research • L’utilisateur A. Datum accède à l’application Ordering de Trey Research

  12. ComposantesADFS v1.0

  13. Composantes ADFS v1.0 • Active Directory ou Active Directory Application Mode (AD/AM) • Fournisseur d’identités • Authentification des utilisateurs • Gestion des attributs utilisés pour constituer les claims • Support des forêts Windows 2000 et 2003 • Federation Service (FS) • Service de jetons de sécurité • Gestion des politiques de confiance de fédération • Federation Service Proxy (FS-P) • Proxy client pour les demandes de jetons • Web Server SSO Agent (Agent SSO) • Agent d’authentification • S’assure de l’authentification utilisateur • Constitue le contexte utilisateur d’autorisation

  14. Agent SSO Composantes ADFS LPC/Méthodes Web Authentification Kerberos/LDAP • Notes • Les composantes FS et FS-P sont co-logés par défaut et peuvent être dissociés • Les composantes FS, FS-P et SSO Agent requièrent la version IIS 6.0 de Windows 2003 R2 FS FS-P Active Directory ou AD/AM HTTPS Application WS

  15. ADFS Federation Service (FS) Service hébergé par ASP.NET sous IIS 6.0 – Windows 2003 Server R2 • Gestion de la politique de fédération • Établissement de la confiance pour les jetons de sécurité signés via la distribution de clés basés sur les certificats • Définition des types de jeton/claimet de l’espace de noms partagés pour les royaumes de sécurité fédérés • Génération des jetons de sécurité • Obtention des attributs utilisateur pour la génération des claimsdepuis AD (ou ADAM) via LDAP • Transformation des claims (si requis) entre les espaces de noms interne et de fédération • Construction d’un jeton de sécurité SAML signé et envoi au FS-P • Construction du contenu du cookie d’authentification SSO générique (« Authentication cookie ») et envoi au FS-P • Authentification utilisateur

  16. ADFS Federation Service Proxy (FS-P) Service hébergé par ASP.NET sous IIS 6.0 – Windows 2003 Server R2 • Authentification utilisateur • Interface graphique pour la Découverte du Royaume d’Appartenance et l’ouverture de session • Authentification des utilisateurs (Forms, Windows intégrée, SSL Client) • Écriture du cookie de royaume («  Account Partner cookie ») pour le Browser • Écriture du cookie d’authentification SSO générique (« Authentication cookie ») pour le Browser (similaire au TGT Kerberos) • Traitement des jetons de sécurité • Demande d’un jeton de sécurité pour le compte d’un client au FS • Routage du jeton vers le serveur Web via une « redirection POST »au travers du Browser

  17. Web Server SSO Agent Extension ISAPI pour IIS 6.0 – Windows 2003 Server R2 • Authentification utilisateur • Interception des requêtes URL GET et redirection des clients non authentifiés vers le FS-P • Écriture du cookie d’authentification WebSSO («  Web Server SSO ») au niveau du Browser (similaire au ticket de service Kerberos) Service Windows • Authentification utilisateur • Création du jeton NT pour l’usurpation d‘identité (utilisateurs AD seulement) Module HTTP .NET • Traitement du jeton de sécurité – Applications non « Claims aware »  • Validation du jeton de sécurité utilisateur et parcours desclaimsdans le jeton • Autorisation utilisateur • Peuplement du contexte ASP.NET GenericPrincipal avec les claims pour le support de IsInRole() • Fourniture desclaimsbrutes à l’application

  18. Interopérabilité avec d’autres serveurs Web • Disponibilité de solutions tierces « ADFS aware » disponibles lors de la sortie d’ADFS pour les serveurs non Microsoft • VintelaServices for Java (VSJ) • http://www.vintela.com/products/vsj • Centrify DirectControl • http://www.centrify.com/directcontrol/overview.asp

  19. Gestion fédérée d’identité ADFS « Projette » les identités Active Directory dans d’autres royaumes de sécurité Entité A Entité B Fédération Serveur de fédération Serveur de fédération • Émission de jetons de sécurité • Gestion de • la confiance – Clés • la sécurité – Jetons/Claims nécessaires • la confidentialité -- Jetons/Claims autorisés • l’audit -- Identités , autorités Espace de noms privés Espace de noms privés

  20. Traitement des jetons et des claims Demande de jeton Parcours et validation Magasins d’identités Queue IIS Ouverture de session Contenu ? AD • Ouverture de session • Extraction des claims ADAM Queue interne Cookie Claims Extracteur de claims Magasins de politiques Cache des politiques de confiance Transformation des claims Primaire Secondaire Création et signature du jeton SAML Jeton en réponse

  21. Support des jetons de sécurité • Type de jetons émis • Exclusivement des assertions SAML 1.1 (Security Assertion Markup Language) dans la version 1.0 d’ADFS • OASIS Security Services (SAML) TC • http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security • Aucun chiffrage des jetons • L’ensemble des messages est véhiculé sur HTTPS • Signature des jetons • Par défaut – Signature avec la clé privée RSA et signature vérifiée avec la clé publique du certificat X.509 correspondant • Optionnel – Signature avec la clé de session Kerberos • Concerne uniquement les jetons FS-R pour le Web Server SSO Agent • Exécution du Service Windows du Web Server SSO Agent avec un compte de service de domaine et avec un SPN configuré (identification du service lors de la séquence d’authentification Kerberos • Utilisation de SetSpn.exe du Kit de Ressources Techniques • http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en

  22. Types de claims supportés • Types de claim interopérables WS-Federation • Identité • User Principal Name (UPN) • Adresse mèl • Common Name (toute chaîne de caractères) • Groupe • Personnalisé (paire nom/valeur, exemple SS=1 99 01 75 111 001 22) • Données authZ seulement pour ADFS-vers-ADFS • SIDs • Permet d’éviter les comptes fantômes (pour les collaborateurs) en Extranet DMZ • Transmission des SIDs dans l’élément Advice du jeton SAML • Claims organisationnels • Ensemble commun de claims à travers des magasins d’identité et des partenaires • Marquer les claims organisationnels comme « auditable » si la valeur du claim ne doit pas être loguée

  23. Extensibilité du traitement des claims • Une interface permet à des modules Plug-in d’être développés pour des transformations de claim personnalisées • ADFS v1 supporte un module unique de transformation de claims, Pas de pipeline pour de multiples modules • Autorise des consultations dans un magasin LDAP ou SQL • Support des transformations de claim complexes exigeant du calcul

  24. Flot des claims ADFS de fédération Partenaire - Compte Peuplement Transformation Claims organisationnels Compte Claims en sortie Magasin AD Transmission des claims Application - Ressource Activation Transformation Claims organisationnels Ressource Claims en entrée Application

  25. Modèles de déploiement et de programmation ADFS

  26. Scénario B2B – Web SSO fédéréAbsence de compte local pour les partenaires Applications Web de commandes et de contrôle d’inventaire Les utilisateurs A. Datum utilisent leur compte AD A. Datum Intranet : Web SSO à l’issue de l’ouverture de session Windows Internet : Web SSO à l’issue de l’ouverture de sessionFormsou d’une authentification SSL cliente Forêt intranet Pare-feu Fédération FS-A FS-R Client SW Acheteur interne FS-P A (ext) Pare-feu Pare-feu Pare-feu Client Trey Research Inc. A. Datum Corp. Agent d’inventaire

  27. Scénario B2E – Web SSO ExtranetSSO pour l’interneet les utilisateurs itinérants Application Web de commandes en lignedans la DMZ Tous les utilisateurs Acme Sporting Goods ont leur compte dans l’AD intranet Intranet : Web SSO à l’issue de l’ouverture de session Windows Internet : Web SSO à l’issue de l’ouverture de sessionFormsou d’une authentification SSL cliente Forêt intranet Forêt DMZ Relation de confiance Windows Fédération FS-R FS-A Client FS-P A (ext) Commercial Gestionnaire de stock Pare-feu Application Web Acme Sporting Goods Pare-feu

  28. Scénario B2C – Web SSO « en ligne »WebSSO classique pour les internautes Site de commerce en ligne et services client associés Les clients disposent de comptes dans la DMZ (AD ou AD/AM) Internet : Web SSO à l’issue de l’ouverture de sessionForms Forêt intranet Forêt DMZ AD/AM FS Client Pare-feu SW Acme Sporting Goods Pare-feu

  29. Modèle de programmation de sécurité ADFS • Concerne le Web Server SSO Agent • Authentification des utilisateurs pour l’application • Création du contexte d’autorisation pour l’application • (Impersonation NT et) ACLs • Modèle de contrôle d’accès basés sur les rôles • Role-based Access Control ou RBAC • Méthode ASP.NET IsInRole() • Logique d’autorisation bâtie sur la correspondance de chaîne • Intégration Authorization Manager (AzMan) • « Designing Application-Managed Authorization » • http://msdn.microsoft.com/library/en-us/dnbda/html/damaz.asp • Ajout des claims Rôle/Groupe au contexte AzMan • Évolution des APIs AzMan dans Windows 2003 SP1 • API ASP.NET de bas niveau pour les claims • System.Web.Security.SingleSign(.Authorization)

  30. SIDs/Attributs Portail Claims de fédération Claims applicatifs Rôles AzMan (RBAC) Fédération ADFS avec RBAC • Intégration ADFS avec AzMan FS-A FS-R Active Directory Eric Application Ordering A. Datum Corp Trey Research

  31. Héritage des spécifications des services Web avancés * Interopérabilité * Extensibilité

  32. Fédération et services Web • Tous les deux offrent une capacité d’intégration à couplage lâche entre domaines autonomes (au sein d’une même entreprise ou entre entreprises) • Les services Web doivent s’identifier et s’authentifier eux-mêmes, et/ou l’utilisateur pour le compte duquel ils agissent Modèle actuel Modèle émergeant/futur Web SSO pour les browser avec SSL/TLS et les cookies Web Services Security, SAML, et d’autres jetons pour les clients SOAP WS-* Services Web SOAP avec une authentification HTTP Basic, SSL/TLS ou intégrée

  33. Spécifications des services Web • WS-* Web Service Architecture (WSA) • Pile WS-*, STAR pour Secure, Transactional, Asynchronous, Reliable • « An Introduction to the Web Services Architecture and Its Specifications » • http://msdn.microsoft.com/library/en-us/dnwebsrv/html/introwsa.asp Service Composition BPEL4WS, Management Composable Service Assurances Reliable Messaging Transactions Security XSD, WSDL, UDDI, Policy, MetadataExchange Description Messaging XML, SOAP, Addressing Transports HTTP, HTTPS, SMTP, etc.

  34. WS-Federation • « Web Services Federation Language » • BEA, IBM, Microsoft, RSA Security, VeriSign, Juillet 2003 • http://msdn.microsoft.com/ws/2003/07/ws-federation • Vision • Livre blanc « Federation of Identities in a Web Services World  » • http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-federation-strategy.asp • Définit les messages permettant à des royaumes de sécurité de fédérer et d’échanger des jetons de sécurité • Authentification unique entre domaines de confiance • Ouverture de session (Sign in) • Fermeture de session (Globalsign out) • Définit l’utilisation de services fédérés d’attributs et de pseudonymes dans ce cadre • Supporte différentes topologies de confiance • Modélisation des pratiques commerciales existantes • Capitalisation sur l’infrastructure existante • Supporte différents modèles de fédération • Avec ou sans mappage/liaison d’identité • Fixe, par couple, « aléatoire », etc.

  35. Un protocole, plusieurs liaisons • Un protocole commun : « Web Services Trust Language » (WS-Trust) • Actional, BEA Systems, CA, IBM, L7T, Microsoft, Oblix, OpenNetwork, PingId, Reactivity, RSA, Verisign, Février 2005 • http://msdn.microsoft.com/ws/2005/02/ws-trust • Définition de deux « profils » • Clients passifs (Browser) – HTTP/S • Clients intelligents (Smart) actifs – SOAP • Support des services Messages HTTP Récepteur HTTP Service de Jetons de sécurité Messages SOAP Récepteur SOAP

  36. Passive Requestor Profile • « Web Services Federation Language: Passive Requestor Profile» • BEA, IBM, Microsoft, RSA Security, Juillet 2003 • http://msdn.microsoft.com/ws/2003/07/ws-passive-profile • Supporté par ADFS v1 dans Windows Server 2003 R2 • Support de WS-Trust et WS-Federation pour les clients passifs (browser) • Adhésion implicites aux politiques en suivant les redirections 302 • Acquisition implicite de jetons via les messages HTTP • Requiert un transport sécurisé (HTTPS) pour l’authentification • Aucune fourniture de « preuve de possession » pour les jetons • Mise à cache limitée (durée) des jetons • Les jetons PEUVENT être rejoués

  37. Redirect to requestor’s IP/STS Login Return identity token Return resource token Redirect to resource’s IP/STS Return secured response Detect realm Passive Requestor Profile Requesting Browser Requestor’s IP/STS Target Resource Target’s IP/STS Get resource GET https://res.resource.com/app HTTP/1.1 HTTP/1.1 302 Found Location: https://sts.resource.com/sts?wa=wsignin1.0&wreply=http://res.resource.com/app&wct=2004-12-03T19:06:21Z HTTP/1.1 200 OK . . . <html xmlns="https://www.w3.org/1999/xhtml"> <head> <title>Working...</title> </head> <body> <form method="post" action="https://res.resource.com/app"> <p> <input type="hidden" name="wa" value="wsignin1.0" /> <input type="hidden" name="wresult" value="&lt;RequestSecurityTokenResponse&gt;...&lt;/RequestSecurityTokenResponse&gt;" /> <button type="submit">POST</button> <!-- included for requestors that do not support javascript --> </p> </form> <script type="text/javascript"> setTimeout('document.forms[0].submit()', 0); </script> </body> </html> HTTP/1.1 200 OK . . . <html xmlns="https://www.w3.org/1999/xhtml"> <head> <title>Working...</title> </head> <body> <form method="post" action="https://sts.resource.com/sts"> <input type="hidden" name="wa" value="wsignin1.0" /> <input type="hidden" name="wctx" value="https://res.resource.com/app" /> <input type="hidden" name="wresult" value="&lt;RequestSecurityTokenResponse&gt;...&lt;/RequestSecurityTokenResponse&gt;" /> <button type="submit">POST</button> <!-- included for requestors that do not support javascript --> </form> <script type="text/javascript"> setTimeout('document.forms[0].submit()', 0); </script> </body> </html> GET https://sts.resource.com/sts?wa=wsignin1.0&wreply= https://res.resource.com/app&wct=2004-12-03T19:06:21Z HTTP/1.1 HTTP/1.1 302 Found Location: https://sts.account.com/sts?wa=wsignin1.0&wreply=https://sts.resource.com/sts&wctx= https://res.resource.com/app&wct=2004-12-03T19:06:22Z&wtrealm=resource.com GET https://sts.account.com/sts?wa=wsignin1.0&wreply=https://sts.resource.com/sts&wctx=https://res.resource.com/app&wct=2004-12-03T19:06:22Z&wtrealm=resource.com HTTP/1.1 POST https://sts.resource.com/sts HTTP/1.1 …. . . wa=wsignin1.0 wctx=https://res.resource.com/app wresult=<RequestSecurityTokenResponse>...</RequestSecurityTokenResponse> POST https://res.resource.com/app HTTP/1.1 ... wa=wsignin1.0 wresult=<RequestSecurityTokenResponse>...</RequestSecurityTokenResponse>

  38. Interopérabilité WS-Federation • Ateliers/liste de distribution publics WS-* afin de préparer les spécifications WS-* à la soumission à des organismes de standardisation • http://groups.yahoo.com/group/WS-Security-Workshops • WS-Federation Passive Requestor Profile Interoperability Workshop • 29 mars 2004 • Concerne le Passive Requestor Profile et les assertions SAML • Interopérabilité au sens service de jetons de sécurité • Livre blanc« Federated Identity Management Interoperability » • http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wsfedinterop.asp • « WS-Federation Passive Requestor Interoperability Profile » • http://download.microsoft.com/download/e/9/0/e90f1994-91be-4cf8-be5e-6ab54206192d/2004.03.Fed_passive_profile_interop_workshop_invite_pack.zip • 100% d’interopérabilité atteinte par l’ensemble des participants • Microsoft, IBM, RSA, Oblix, PingID, Open Network, Netegrity • Annonce de solutions WS-Federation et présentation des pré versions lors de TechEd’04 à SanDiego • « Leading Identity Management Vendors Join Microsoft to Demonstrate Federated Identity Using Web Services » • http://www.microsoft.com/presspass/press/2004/may04/05-25IMVRallyPR.asp

  39. Active (Smart) Requestor Profile • ADFS v2.0 avec Longhorn • Support de WS-Trust et WS-Federation pour les clients actifs (« conscients » de SOAP/XML) • Détermination explicite des jetons nécessaires à partir des politiques • Demande explicite de jetons via des messages SOAP • Authentification forte de l’ensemble des demandes • Peut fournir une preuve de possession pour les jetons • Support de la délégation • Les clients peuvent fournir un jeton à un service Web afin que ce dernier l’utilise en leur nom • Mise à cache évoluée des jetons au niveau du client • Amélioration de l’expérience utilisateur et des performances • Mise à disposition d’une infrastructure de sécurité pour les services Web avancés (Indigo) • Première étape vers Active Directory comme service pour les architectures orientées services • Rendre possible les scénarios de gestion fédérée d’identité pour les services Web WS-* sécurisés inter opérables

  40. Active (Smart) Requestor Profile Requesting Service Requestor’s IP/STS Target Service Target’s IP/STS Acquire policy Request token Return token Request token Return token Send secured request Return secured response

  41. Modèle de fédération piloté par les méta données Les services comprennent des jetons spécifiques, les services de jetons de sécurité traduisent les jetons (de ce que le principal possède à ce que l’application a besoin) et WS-* fournit une pile standard et l’enveloppe Politique de fédération Service Cible Politique d’accès Services de pseudonymes et d’attributs Service de jetons de sécurité (le service de contrôle d’accès fournit les jetons de permission) Service d’identité

  42. Interopérabilité avec Liberty Alliance • Spécification Liberty Alliance ID-FF 1.2 • http://www.projectliberty.org/resources/specifications.php#box1 • Fournit les liaisons de comptes via l’échange d’informations obscurcies et d’autres éléments ajoutés par rapport à OASIS SAML 1.x • Méta données de fermeture de session (Globallogout) notamment • Spécifications de Web SSO entre ID-FF 1.2 et WS-Federation annoncées le 13 mai dernier lors de la conférence de presse Microsoft/Sun • « Microsoft and Sun Publish Web Single Sign-On (SSO) Identity Specifications » • http://xml.coverpages.org/ni2005-05-16-a.html • « Web Single Sign-On Metadata Exchange Protocol» (Web SSO MEX), « Web Single Sign-On Interoperability Profile» (Web SSO Interop Profile) • http://msdn.microsoft.com/library/en-us/dnglobspec/html/wssecurspecindex.asp • http://developers.sun.com/techtopics/identity/interop/index.html

  43. Vers un méta système d’identité • Framework unifiant un monde composé de • Multiples technologies d’identité, de multiples opérateurs et de multiples implémentations • Permet aux utilisateurs de gérer leur identité dans un monde hétérogène • En respectant les lois de l’identité • « The Laws of Identity » • http://msdn.microsoft.com/library/en-us/dnwebsrv/html/lawsofidentity.asp • « Microsoft's Vision for an Identity Metasystem» • http://msdn.microsoft.com/library/en-us/dnwebsrv/html/identitymetasystem.asp

  44. Résumé de la session ADFS délivre • De la collaboration B2B sur Internet • Du Web SSO pour les utilisateurs internes et externes • De l’interopérabilité entre plateformes • Un modèle de programmation flexible et simplifié pour une approche de contrôle d’accès s’appuyant sur les rôles (RBAC)

  45. Pour plus d’informations • « Active Directory Federation Services: A Path to Federated Identity and Access Management » • http://download.microsoft.com/download/3/a/f/3af89d13-4ef4-42bb-aaa3-95e06721b062/ADFS.doc • « The .NET Show: ADFS » • http://msdn.microsoft.com/theshow/episode047/default.asp Rejoignez les discussions surhttp://www.identityblog.com

  46. Microsoft France 18, avenue du Québec 91 957 Courtaboeuf Cedex www.microsoft.com/france 0 825 827 829 msfrance@microsoft.com

More Related