Fédération d’identité

Présentation au sujet: "Fédération d’identité"— Transcription de la présentation:

1 Fédération d’identité
3/31/2017 9:55 PM Fédération d’identité Philippe Beraud Consultant principal Direction Technologies et Sécurité 1 © 2005 Microsoft Corporation 1 © Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

2 Qu’est-ce que l’identité 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 quelqu’un/quelque chose par quelqu’un/quelque chose Une claim constitue une assertion de la vérité de quelqu’un/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 Les leçons tirées de Passport
Passport a été conçu pour résoudre deux problèmes Fournisseur d’identité sur MSN +250 millions d’utilisateurs, 1 milliard de logons par jour Fournisseur d’identité 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 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 n’a pas, à ce jour, été déployée de manière universelle Plusieurs fournisseurs avec plusieurs technologies implique immanquablement peu d’interopérabilité N’y a-t-il aucune solution envisageable ?

5 Les 7 lois de l’identité Etablies au travers d’une dialogue avec l’industrie Contrôle et consentement de l’utilisateur Divulgation minimale pour un usage défini Présence justifiée des parties en présence Support d’identités publiques et privées Pluralisme des opérateurs et des technologies Prise en compte de l’humain Expérience cohérente entre les contextes Rejoignez les discussions sur

6 Notion de méta-système d’identité
Aujourd’hui : de multiples identités… et de multiples formats Un méta-système d’identité est un cadre de travail qui unifie le monde de Plusieurs technologies d’identité Plusieurs opérateurs Plusieurs implémentations Un méta-système d’identité 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 l’utilisation de multiples systèmes d’identité Supprime les frictions sans pour autant requérir que tout le monde s’accorde sur une unique technologie d’identité quelque soit l’usage Capitalise sur les succès présents Offre un chemin de migration simple du passé au futur

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

8 WS-*, une architecture pour un méta-système d’identité
Architecture composable pour les services Web Large participation de l’industrie 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 l’OASIS (ou du W3C) ou sur le point de l’être

9 Consommateur d’identité
S’identifie via un mécanisme cryptographique certain L’utilisateur peut décider si le consommateur d’identité est bien celui que l’utilisateur s’attend à être Les claims communiquées sont explicitement chiffrées à destination de cette identité Exprime les exigences en termes d’identité pour un service Une liste de claims Une liste de fournisseurs d’identité admissibles (y compris les auto-générés) Une liste des formats de jetons recevables Pour s’insérer dans le méta-système d’identité Définir une politique à l’aide 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 Fournisseur d’identité
Produit les jetons de sécurité Définit les conditions pour produire le jeton, à savoir les crédentiels nécessaires, si le consommateur d’identité doit être nommé Pour s’insérer dans le méta-système d’identité 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 s’intégrer avec un système d’identité existant S’adapter à un système SAML existant S’adapter à un déploiement de cartes à puces existant Peut s’exécuter sur n’importe quel périphérique Serveurs, PCs, périphériques mobiles

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

12 Carte 1306 - 2523 Fabrikam Jean Dupond Name: Jean’s Card
Expires: 9/15/2006 Image Issuer: Fabrikam Supported Claims: { GivenName LastName Address City … } Issuer Token Service EPRs Supported Token Type: { SAML 1.1 } … Exp 9/15/2006 Jean’s Card Les valeurs des claims sont détenues au niveau du fournisseur d’identité Fabrikam Fournisseur d’identité Service de jetons de sécurité

13 Carte Représentation visuel d’une identité numérique
Une carte n’est PAS un jeton de sécurité Artefact qui représente la relation de délivrance d’un jeton entre l’utilisateur et le fournisseur d’identité correspondant Une carte contient des métadonnées pour l’obtention d’un jeton de sécurité d’un fournisseur d’identité Type de jetons de sécurité, Claims supportés, Adresse du fournisseur d’identité, Crédentiels exigés Le jeton de sécurité délivré par le fournisseur d’identité est soumis au consommateur d’identité par l’utilisateur Fait de l’utilisateur un participant actif de l’utilisation d’identité Consentement et contrôle Etablit une confiance mutuelle entre l’utilisateur et les services accédés Atténue le risque de phishing et de vol d’identité 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 Comment tout cela fonctionne-t-il ?
7 L’application relaye le jeton de sécurité au consommateur d’identité 6 Le fournisseur d’identité produit le jeton de sécurité contenant les preuves requises Jeton Fournisseur d’identité Service de jetons de sécurité Consommateur d’identité Politique Politique 5 Le sélecteur d’identité présente les crédentiels au fournisseur d’identité et demande un jeton de sécurité Crédentiels 1 Accès à la Ressource 2 Lecture de la politique définissant les preuves requises et les fournisseurs d’identité : « Je souhaiterais recevoir un jeton contenant givenName et lastName dont le tokenType est SAML 1.1, émis par n’importe qui » Application cliente Sélecteur d’identité 3 Filtrage des cartes qui pourraient satisfaire les exigences du consommateur d’identité 4 L’utilisateur sélectionne une carte depuis la liste des identités appropriées dans le sélecteur d’identité

15 Consommateur d’identité
Protocoles utilisés Fournisseur d’identité Service de jetons de sécurité Consommateur d’identité Politique Politique WS-MetadataExchange, WS-Security WS-SecurityPolicy WS-SecurityPolicy WS-MetadataExchange, WS-Security, WS-Trust Application cliente Sélecteur d’identité

16 « InfoCard » comme sélecteur d’identité
Permet à l’utilisateur de participer dans le méta-système d’identité Composant de Windows Communication Foundation (WCF) dans WinFX Utilisable par n’importe quelle application, implémenté comme sous-système sécurisé Dialogue de crédentiels Windows commun Axes de conception Respect des « Lois de l’identité » Respect de la vie privée Par défaut, le fournisseur d’identité n’apprend rien des habitudes d’un utilisateur entre les différents services et sites L’utilisateur est conscient de l’utilisation faite de ses données Sécurité Chiffrement du stockage Chiffrement du jeton à destination du consommateur d’identité 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 d’identité Jeu de claims extensible

17 InfoCard en action 3/31/2017 9:55 PM 17 WS-Mex : WSDL, Politique
Consommateur d’identité WS-Mex : WSDL, Politique Point de Terminaison Mex Certificat organisationnel pour afficher les logos sujet et émetteur WSDL + Politique Application Cliente (App WCF) Runtime WCF Jeton IHello:Say() + Point de Terminaison Depuis « InfoCard » Retourne : « Hello World, Jean! » Le message est sécurisé via le certificat 17 © Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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

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

20 Construire un service consommateur d’identité 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 d’autorisation

21 Etape 1 - Configurer un certificat
Informer WCF comment trouver le certificat du service <configuration> <system.serviceModel> <bindings>…</bindings> <services>…</services> <behaviors> <behavior configurationName=“MyServiceBehavior” returnUnknownExceptionsAsFaults=“true” > <serviceCredentials> <serviceCertificate findValue=“Fabrikam” storeLocation=“LocalMachine” storeName=“TrustedPeople” x509FindType=“FindBySubjectName” /> </serviceCredentials> </behavior> </behaviors> </system.serviceModel> </configuration>

22 Etape 1 - Configurer un certificat
Inclure le certificat comme composante de l’EPR du service Utilisé pour afficher le dialogue RIP sur le client Converti comme encodage base64 sur le réseau <configuration> <system.serviceModel> <bindings>…</bindings> <services> <service type=“MyFirstHelloApp.Hello”> <endpoint address=“endpoint1” contract=“MyFirstHelloApp.IHello” binding=“wsHttpBinding” bindingConfiguration=“myBinding”> <identity> <certificateReference findValue=“Fabrikam” storeLocation=“LocalMachine” storeName=“TrustedPeople” x509FindType=“FindBySubjectName” /> </identity> </endpoint> </service> </services> <behaviors>…</behaviors> </system.serviceModel> </configuration> 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 Etape 1 - Configurer un certificat
Lier (1) wsHttpBinding (2) le comportement personnalisé du service et (3) l’identité ajoutée dans le point de terminaison <configuration> <system.serviceModel> <bindings>…</bindings> <services> <service type=“MyFirstHelloApp.Hello” behaviorConfiguration=“MyServiceBehavior” > … </service> </services> <behaviors>…</behaviors> </system.serviceModel> </configuration>

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 <configuration> <system.serviceModel> <bindings> <wsHttpBinding> <binding configurationName=“myBinding”> <security mode=“Message”> <message clientCredentialType=“InfoCard” /> </security> </binding> </wsHttpBinding> </bindings> … </system.serviceModel> </configuration>

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 d’autres propriétés <configuration> <system.serviceModel> <bindings> <wsFederationBinding> <binding configurationName=“FedBinding”> <security mode=“Message”> <message issuedTokenType=“urn:oasis:names:tc:SAML:1.0:assertion” defaultProtectionLevel=“EncryptAndSign”> <requiredClaimTypes> <add claimType=“ <!-- add more claims here --> </requiredClaimTypes> </tokenRequestParameters> <xmlElement>…</xmlElement>…<xmlElement>…</xmlElement> <issuer address=“ </message> </security> </binding> </wsFederationBinding> </bindings> <services>…</services> <behaviors>…</behaviors> </system.serviceModel> </configuration> WS-SecurityPolicy vient ici

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 <configuration> <system.serviceModel> <bindings>…</bindings> <services> <service type=“MyFirstHelloApp.Hello” behaviorConfiguration=“MyServiceBehavior” > <endpoint address=“endpoint1” contract=“MyFirstHelloApp.IHello” binding=“wsFederationBinding” bindingConfiguration=“FedBinding”> <identity> <certificateReference findValue=“Fabrikam” storeLocation=“LocalMachine” storeName=“TrustedPeople” x509FindType=“FindBySubjectName” /> </identity> </endpoint> </service> </services> <behaviors>…</behaviors> </system.serviceModel> </configuration>

27 Etape 3 - Traiter le jeton
Lire le jeton de sécurité Ajouter une référence pour l’assemblage System.Security.Authorization.dll « Using » pour C# : using System.Security.Authorization; Modifier l’implémentation de Hello:Say() public const String ClaimType =“ 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 Construire le client avec WCF
Mettre en œuvre le « Runtime Binding » Ajouter une référence pour l’assemblage System.Security.dll Utiliser le MetadataResolver pour obtenir le WSDL à l’aide 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 l’intégrité sont assurées selon les exigences de la politique du service

29 Construire le client avec WCF
Mettre en œuvre le « Runtime Binding » using System.ServiceModel.Design; … ChannelFactory<IHello> cnFactory = null; // Create a MetadataResolver for retrieving metadata. EndpointAddress mexAddress = new EndpointAddress(“ 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<IHello>(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 Construire un service fournisseur d’identité 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 l’expé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 s’authentifie, construire les exigences) Authentifier le client Traiter la demande de jeton, et créer le jeton

31 Etape 1 - Créer la carte <Object Id=“_Object_InfoCard”>
<Signature xmlns=“ … <Object Id=“_Object_InfoCard”> <InfoCard xmlns:ic= “ > <ic:InfoCardReference> <ic:CardId>…</ic:CardId> </ic:InfoCardReference> <ic:CardName>…</wsid:CardName> <ic:CardImage>…Mmq95KmzT=ZxVp…</ic:CardImage> <ic:IssuerName>…</ic:IssuerName> <ic:TimeIssued>…</ic:TimeIssued> <ic:TokenServiceReference> <ic:TokenService> … [EPR][,[Auth]]… </ic:TokenService> </ic:TokenServiceReference> <ic:InfoCardPolicy> <SupportedTokenTypes> <TokenType Uri= “…” /> <SupportedTokenTypes> <SupportedClaims> <Claim Uri= “ />… <Claim …/> </ic:InfoCardPolicy> </ic:InfoCard > </Object> </Signature> Inclus le certificat et la valeur de la signature L’image de la carte image apparaît dans « InfoCard » EPRs STS et comment s’authentifier .CRD

32 Etape 2 – Construire un service de jetons de sécurité
Qu’est-ce qu’un 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 d’Identité peut se référer à un STS via le champs <issuer> dans sa politique de sécurité De même, un STS peut également se référer à un autre STS Les fournisseurs et consommateurs d’identité peuvent s’appuyer sur N STSes

33 « Microsoft Federated Identity and Access Resource Kit
for Sept 2005 Community Technology Preview »

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 d’authentification Nom d’utilisateur/Mot de passe, Kerberos, certificat X509, carte auto-générée public const string ns = " 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 Messages RST/RSTR Request Security Token (RST) <S:Header> ... token here (WS-Security: UsernameToken, BinarySecurityToken) </S:Header> <S:Body> <wst:RequestSecurityToken> <wst:TokenType>urn:oasis:names:tc:SAML:1.1</wst:TokenType> <wst:RequestType> <ic:InfoCardReference> <ic:CardId>…[Card GUID Here] …</</ic:CardId > </ic:InfoCardReference> <wst:Claims><ic:Claim … /><ic:Claim … />…</wst:Claims > <ic:RequestDisplayToken> </wst:RequestSecurityToken> </S:Body>

36 Messages RST/RSTR <saml:Assertion ...>...</saml:Assertion>
Request Security Token Response (RTSR) <S:Header> … </S:Header> <S:Body> <wst:RequestSecurityTokenResponse> <wst:TokenType>urn:oasis:names:tc:SAML:1.1</wst:TokenType> <wst:Lifetime>…</wst:Lifetime> <wst:RequestedSecurityToken> <saml:Assertion ...>...</saml:Assertion> </wst:RequestedSecurityToken> <ic:RequestedDisplayToken> <ic:DisplayToken> <ic:DisplayClaim Uri=“ > <ic:DisplayTag>…</ic:DisplayTag> <ic:DisplayValue>…</ic:DisplayValue> </ic:DisplayClaim> … </ic:RequestedDisplayToken> </wst:RequestSecurityTokenResponse> </S:Body>

37 Mettre tout ensemble 3/31/2017 9:55 PM 37 37
© Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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 d’un consommateur d’identité à un autre Futur : Active Directory STS Active Directory Federation Service (ADFS) de Windows Server 2003 R2 préfigure AD-STS

39 Active Directory Federation Services (ADFS)
Intégrer aujourd’hui le browser (client passif) dans le méta-système d’identité 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 S’intègre avec les autorisations Authorization Manager (AzMan) Bel exemple de méta-systèmes d’identité pour les clients passifs Fournisseur/Consommateur d’identité interopérable Aujourd’hui : 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 d’identité interopérable Quest VSJ, Centrify Direct Control, BMC Disponible ce mois

40 Web SSO fédéré avec ADFS
Forêt intranet Forêt DMZ Pare-feu Fédération FS-A [6] [6] Demande de validation du jeton par FS-P R Construction par FS-R d’un jeton(R) à partir du jeton(A) FS-R [4] Obtention des attributs par FS-A et construction du jeton(A) [4] FS-P A (ext) FS-P A (int) [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 [3] Redirection HTTP 302 vers FS-P A (int) Authentification de l’utilisateur et demande de jeton [3] [2] Redirection HTTP 302 vers FS-P R Découverte du Royaume d’Appartenance [2] FS-P R Client [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 [1] HTTP GET par le browser à destination du serveur Web (WS) [1] WS Pare-feu Pare-feu Pare-feu Relation de confiance établie « out-of-band » par l’échange de certificats X.509 et de politiques de claims Articulation de l’ensemble de l’authentification autour du client pour les clients Browser

41 Web SSO fédéré avec ADFS
3/31/2017 9:55 PM Web SSO fédéré avec ADFS 41 41 © Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

42

43 © 2005 Microsoft Corporation. Tous droits réservés.
3/31/2017 9:55 PM © 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. 43 © Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.