Sso fédération

1 897 vues

Publié le

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 897
Sur SlideShare
0
Issues des intégrations
0
Intégrations
490
Actions
Partages
0
Téléchargements
73
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Sso fédération

  1. 1. Formation SSO / Fédération CYRIL GROSJEAN (cgrosjean@janua.fr) CONSULTANT JANUA
  2. 2. Agenda Objectifs du SSO ● Terminologie, acronymes et protocoles ● Présentation d'architectures de SSO ● Présentation d'architectures de fédération ● Exemples de déploiement ● Méthodologie d'approche d'un projet SSO ● Questions / Réponses ● © copyright Janua 2009
  3. 3. Terminologie - SSO SSO: Single Sign On ● eSSO: Enterprise Single Sign On ● CDSSO: Cross Domain Single Sign On ● pseudo-SSO ● SLO: Single Logout ●
  4. 4. Objectifs d'une solution de SSO Ergonomie: simplifier la navigation de l'utilisateur ● Simplification de la gestion de l'authentification: une interface/un serveur d'authentification unique en opposition à plusieurs bases et/ou interfaces d'authentification ● Sécurisation de l'authentification: les mots de passe ne circulent plus, ils sont remplacés par des jetons ● Possibilité d'étendre facilement les services offerts: gestion des mots de passe, fédération, contrôle d'accès, transmission d'informations de session .. ●
  5. 5. Terminologie - Fédération Solution permettant: ● –d'établir un SSO entre des entités (entreprises, organismes) distinctes –d'assurer le contrôle d'accès aux ressources fédérées –d'échanger des informations entre les entités fédérées IdP / Fournisseur d'identité ● SP / Fournisseur de service ● PKI / IGC ●
  6. 6. Terminologie - Fédération SAML v2 (OASIS) ● Consortium Liberty Alliance (ID-FF, ID-WSF, ID-SIS) ● Shibboleth (Internet2) ● WS-Federation (Microsoft) ●
  7. 7. Architectures de SSO Avec agent (CAS,OpenSSO,JOSSO) ● Sans agent / portefeuille (Oracle eSSO,SSOX) ● Avec reverse proxy (LemonLDAP,JOSSO,OpenSSO,CAS) ●
  8. 8. Architectures de SSO avec agent base d' utilisateurs service app. #2 app. #3 serveur d' authentication id en t m / ifia nt pa ot de ss e app. #1 navigateur Source: CSIER Février 2005
  9. 9. Architectures de SSO avec agent ID CAS server application ST TGC HTTPS ST ST navigateur Source: CSIER Février 2005 TGC
  10. 10. Architectures de SSO sans agent Source: Oracle Enterprise SSO Technical Guide – Juin 2009
  11. 11. Architectures de SSO : Reverse Proxy
  12. 12. Architectures de SSO : Reverse Proxy Source: http://lemonldap.adullact.net/ – Juin 2009
  13. 13. Architectures de SSO: CDSSO Source: OpenSSO technical overview - 2008
  14. 14. Architectures de fédération – SAML Fédération vs SSO ● –multi-domaines –portabilité / mono-domaine / solutions propriétaires –inter-opérabilité / pas d'inter-opérabilité native –identités multiples mais fédérées / identité unique –contrôle utilisateur sur les informations échangées / rien –protocole modulaire, plusieurs façons standard d'échanger / pas de standard –support –sécurité des Web services sécurisés / sécurité moindre accrue (signature, chiffrement), contrôle des informations divulguées et identifiants opaques
  15. 15. Architectures de fédération SAML v2 ● Liberty Alliance ● Shibboleth ● OpenID ● FederID ● WS-Federation ●
  16. 16. Architectures de fédération – SAML Security Assertion Markup Language ● Objectifs: ● –échanger des informations d'identités de façon sécurisée –authentifier –portabilité et autoriser inter-entreprises / inter-organismes Entités ● –Sujet (Subject) –Autorité SAML (SAML authority - IdP) –Demandeur –Autorité (SAML requester – SP) d'attributs (AA)
  17. 17. Architectures de fédération – SAML Nouveautés SAML v2 ● –inspirées de Shibboleth et Liberty Alliance => convergence des standards de fédération –pseudonymes: identifiants opaques échangés entre les fournisseurs de service et d'identités –possibilité –single de génération dynamique des identifiants logout protocol –chiffrement –protocoles –service partiel ou total des assertions SAML d'échanges d'attributs de découverte –méta-données –support de la fédération des périphériques mobiles
  18. 18. Architectures de fédération – SAML Source: Présentation Aquarium – Sun Microsystems– Décembre 2008
  19. 19. Architectures de fédération – SAML Définition: une identité est fédérée entre plusieurs fournisseurs d'identité ou de service lorsque ils sont tombés d'accord sur un ensemble d' identifiants et d'attributs par lesquels se référer à l'identité ● Questions adressées dans l'accord: ● –Quelles –Les sont les identités locales liées par la fédération ? identifiants fédérés sont-ils pré-établis ou dynamiques ? –Le consentement de l'utilisateur pour fédérer ses comptes est-il nécessaire ? –Des attributs utilisateur ont-ils besoin d'être échangés ? –Doit-on utiliser des identifiants temporaires (supprimés en fin de session) ? –Les échanges d' informations doivent-ils être chiffrés ?
  20. 20. Architectures de fédération – SAML Exemple de fédération/liaison de compte (account linking) ● 1.Michel Durand consulte sa BAL michel.durand@laposte.net par WebMail (HTTP/HTTPS) 2.Il consulte ensuite le site "Colissimo". Colissimo détecte que Mr Durand n'est pas authentifié mais qu'il a précédemment consulté le site partenaire LaPoste.Net (éventuellement grâce au service de découverte SAML v2) 3.Colissimo demande donc à Mr Durand s'il serait d'accord pour fédérer son compte local avec (son compte sur) LaPoste.Net 4.Mr Durand accepte de fédérer son compte, son navigateur est redirigé sur le site WebMail qui lui crée un nouveau pseudonyme tkijsH3e6 à utiliser lorsqu'il visite Colissimo. Ce pseudonyme est lié à son compte michel.durand@laposte.net
  21. 21. Architectures de fédération – SAML 5.Mr Durand est ensuite redirigé vers Colissimo avec une assertion SAML indiquant que l'utilisateur représenté par l'identifiant fédéré tkijsH3e6 s'est authentifié auprès du fournisseur d'identité LaPoste.Net . 6.S'agissant de la première connexion de Mr Durand sur Colissimo avec l'identifiant fédéré, celui-ci n'a pas encore de correspondance avec un compte local. Mr Durand doit donc d'abord se connecter avec son compte Colissimo, micheldurand. 7.Colissimo lie ensuite le compte local micheldurand à l'identifiant fédéré tkijsH3e6 à utiliser avec le fournisseur d'identité LaPoste.Net . 8.Les comptes locaux de Mr Durand sur LaPoste.Net et Colissimo sont donc désormais liés, c'est à dire rattachés à l'identifiant fédéré tkijsH3e6 .
  22. 22. Architectures de fédération – SAML 9.Mr Durand se connecte ensuite à son compte de la banque postale. Le processus précédent se répète:il est redirigé vers le site WebMail qui lui crée un nouveau pseudonyme jqp46Se0 à utiliser lorsqu'il visite la banque postale. Ce pseudonyme est lié à son compte michel.durand@laposte.net 10.Mr Durand est redirigé vers la banque postale avec une nouvelle assertion SAML. Il doit s'authentifier une fois avec son compte local sur ce site (mdurand), qui lie ensuite ce compte à l'identifiant fédéré jqp46Se0 à utiliser avec le fournisseur d'identité LaPoste.Net. 11.Les comptes michel.durand@laposte.net sur le site LaPoste.Net et mdurand à la banque postale sont maintenant liés par l'identifiant fédéré jqp46Se0 .
  23. 23. Architectures de fédération – SAML fournisseur de service www.sp.com fournisseur d'identité www.idp.com Resource service de consommation d'assertions vérification d'accès 2 7 Accès ressource 1 6 Redirection avec <AuthnRequest Ressource renvoyée service de SSO Réponse signée en HTML Requête POST signée 5 3 Authent. GET avec <AuthnRequest Action Navigateur ou Utilisateur 4 Demande d'authent.
  24. 24. Architectures de fédération – SAML Profiles: combinaison d'assertions, de protocoles et de règles de liaisons (bindings) pour supporter divers scénari Bindings: règles de correspondance entre le protocole SAML et les protocoles de transport/messagerie standards Protocoles: règle et format d'envoi des requêtes et réponses permettant de véhiculer les assertions de sécurité Assertions: messages d'authentification, d'autorisation et d'échange d'attributs
  25. 25. Architectures de fédération – SAML Protocoles SAML ● –Assertion –Artifact query and request protocol Resolution Protocol –Name Identifier Management Protocol –Name Identifier Mapping Protocol –Single Logout Protocol
  26. 26. Architectures de fédération – SAML Bindings SAML ● –SAML SOAP –Reverse binding SOAP binding –HTTP Redirect binding –HTTP Post binding –HTTP Artifact –SAML URI binding Binding
  27. 27. Architectures de fédération – SAML Profiles SAML ● –Profile Web Browser SSO –Profile Enhanced Client and Proxy (ECP) –Profile Identity Provider Discovery –Profile Single Logout –Profile Assertion –Profile Artifact –Profiles Query Resolution Name Identifier
  28. 28. Architectures de fédération – SAML Exemples d'assertion SAML: autorisation ● –<saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” Version="2.0" –IssueInstant="2009-03-15T13:30:00Z"> –<saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity>http://www.globalc.com –</saml:Issuer> –<saml:Subject> –<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> –b.hill@globalc.com –</saml:NameID> –</saml:Subject> –<saml:Condition NotBefore="2009-03-15T13:30:00Z" –NotOnOrAfter="2009-03-15T13:45:00Z"> –</saml:Conditions> –<saml:AuthnStatement AuthnInstant="2009-03-15T13:30:00Z" –SessionIndex="79830261179"> –<saml:AuthnContext> –....
  29. 29. Architectures de fédération – SAML Exemples d'assertion SAML: échange d'attributs ● –<saml:AttributeStatement> –<saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" –NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri“ Name="urn:oid:2.5.4.42" –FriendlyName="displayName"> –<saml:AttributeValue xsi:type="xs:string“ –x500:Encoding="LDAP">John Mc Enroe</saml:AttributeValue> –</saml:Attribute> –<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" –Name="LastName"> –<saml:AttributeValue xsi:type="xs:string">Mac Enroe</saml:AttributeValue> –</saml:Attribute> –<saml:Attribute NameFormat=http://globalcompany.com/attr-formats Name=“AccountNumber”> –xmlns:smithco=”http://www.globalcompany.com/company-schema.xsd” –<saml:AttributeValue –<globalC:badge xsi:type=“globalC:type”> color=“white”>453ABD34</globalC:badge> –</saml:AttributeValue> –</saml:Attribute> –</saml:AttributeStatement>
  30. 30. Architectures de fédération – SAML Aspects sécurité ● –intégrité des messages garanties par signature XML des requêtes et réponses –échange des clés publiques en ligne ou hors-ligne –possibilité de chiffrer les échanges par SSL / TLS –possibilité d'associer un niveau de sécurité aux différents bindings –possibilité d'utiliser des identifiants opaques pour préserver la confidientialité
  31. 31. Architectures de fédération – Liberty Source: Linagora groupe
  32. 32. Architectures de fédération – Liberty x Source: Tutoriel Liberty Alliance Project v 2 - 2004
  33. 33. Architectures de fédération – Liberty Recommandations de la DGME ● –Utiliser SAML v2 ou ID-FF 1.2 pour fédérer des services –Utiliser ID-WSF 1.1 pour échanger des attributs entre services fédérés Source: Tutoriel Liberty Alliance Project v 2 - 2004
  34. 34. Architectures de fédération – WS-* Spécifications conçues par BEA, CA, IBM, Microsoft, Novell, Verisign en marge de SAML, Shibboleth & Liberty ● Supporté par Active Directory Federation Service ● Intéressant dans le cas d'une intégration avec les solutions Microsoft. Problèmes d'inter-opérabilité à prévoir sinon ● Source: Tutoriel Liberty Alliance Project v 2 - 2004
  35. 35. Méthodologie projet 1 2 3 4 Compréhension du besoin Analyse métier Analyse de l'existant Besoins / Exigences Spécifications Architecture logique Mise en oeuvre Déploiement Définition du périmètre Recensement du parc Fonctionnelles Maquette Besoin (SSO,CDSSO,SLO) Serveurs Web Applications / Interfaces Install / Config SSO Applications / Protocoles Serveurs d'applications Alimentation , synchros Développements Gestion des mots de passe Applis. Client / Serveur Règles d'accès Intégrations Gestion des droits Clients (OS, browser, hard) Gestion des mot de passe Recette Définition des livrables Sources de données Techniques Déploiement Cahier des charges Annuaires, SGBD, Fichiers Architecture Application(s) pilote(s) Spécifications Types d'authentifcation Configuration produit Formation Cahier de recette Rôles et droits applicatifs Exploitation Assistance au démarrage Choix d'une solution Processus de déploiement Configuration/Exploitation Support
  36. 36. Analyse métier impacts organisationnels ● –Quels sont les utilisateurs (salariés, stagiaires, prestataires de services, partenaires, clients …) ? –Qui est à l’origine de l’identité des utilisateurs (ressources humaines, directions métiers, services généraux, DSI,…) ? –Comment le cycle de vie de l’identité des utilisateurs est-il géré (création, modification, suppression, suspension ...) ? –Comment –Quelles sont gérées les habilitations des utilisateurs ? sont les identités strictement internes et externes ?
  37. 37. Analyse métier plan de communication ● –source(s) –sécurité d'autorité mise en oeuvre –communiquer –établir sur les enjeux, les bénéfices et les risques des relations de confiance entre individus conduite du changement ● prise en compte des processus, de l'existant ● –modèle –culture de gouvernance des SI d'entreprise

×