Formation SSO / Fédération

Formation SSO / Fédération CYRIL GROSJEAN (cgrosjean@janua.fr) CONSULTANT JANUA

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

Terminologie - SSO SSO: Single Sign On esso: Enterprise Single Sign On CDSSO: Cross Domain Single Sign On pseudo-sso SLO: Single Logout

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..

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

Terminologie - Fédération SAML v2 (OASIS) Consortium Liberty Alliance (ID-FF, ID-WSF, ID-SIS) Shibboleth (Internet2) WS-Federation (Microsoft)

Architectures de SSO Avec agent (CAS,OpenSSO,JOSSO) Sans agent / portefeuille (Oracle esso,ssox) Avec reverse proxy (LemonLDAP,JOSSO,OpenSSO,CAS)

Architectures de SSO avec agent service base d' utilisateurs app. #1 app. #2 app. #3 serveur d' authentication identifiant / mot de passe navigateur Source: CSIER Février 2005

Architectures de SSO avec agent ID CAS server ST application ST TGC HTTPS ST navigateur TGC Source: CSIER Février 2005

Architectures de SSO sans agent Source: Oracle Enterprise SSO Technical Guide Juin 2009

Architectures de SSO : Reverse Proxy

Architectures de SSO : Reverse Proxy Source: http://lemonldap.adullact.net/ Juin 2009

Architectures de SSO: CDSSO Source: OpenSSO technical overview - 2008

Architectures de fédération SAML Fédération vs SSO multi-domaines / mono-domaine portabilité / 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 des Web services sécurisés / sécurité moindre sécurité accrue (signature, chiffrement), contrôle des informations divulguées et identifiants opaques

Architectures de fédération SAML v2 Liberty Alliance Shibboleth OpenID FederID WS-Federation

Architectures de fédération SAML Security Assertion Markup Language Objectifs: échanger des informations d'identités de façon sécurisée authentifier et autoriser portabilité inter-entreprises / inter-organismes Entités Sujet (Subject) Autorité SAML (SAML authority - IdP) Demandeur (SAML requester SP) Autorité d'attributs (AA)

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é de génération dynamique des identifiants single logout protocol chiffrement partiel ou total des assertions SAML protocoles d'échanges d'attributs service de découverte méta-données de la fédération support des périphériques mobiles

Architectures de fédération SAML Source: Présentation Aquarium Sun Microsystems Décembre 2008

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 sont les identités locales liées par la fédération? Les 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?

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

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.

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.

Architectures de fédération SAML fournisseur de service www.sp.com fournisseur d'identité www.idp.com Resource vérification d'accès service de consommation d'assertions service de SSO Accès ressource 1 7 Ressource renvoyée 2 Redirection avec <AuthnRequest 6 Requête POST signée Réponse signée en HTML 5 GET avec <AuthnRequest Authent. 4 3 Demande d'authent. Action Navigateur ou Utilisateur

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

Architectures de fédération SAML Protocoles SAML Assertion query and request protocol Artifact Resolution Protocol Name Identifier Management Protocol Name Identifier Mapping Protocol Single Logout Protocol

Architectures de fédération SAML Bindings SAML SAML SOAP binding Reverse SOAP binding HTTP Redirect binding HTTP Post binding HTTP Artifact binding SAML URI Binding

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 Query Profile Artifact Resolution Profiles Name Identifier

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>...

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 xsi:type= globalc:type > <globalc:badge color= white >453ABD34</globalC:badge> </saml:attributevalue> </saml:attribute> </saml:attributestatement>

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é

Architectures de fédération Liberty Source: Linagora groupe

Architectures de fédération Liberty x Source: Tutoriel Liberty Alliance Project v 2-2004

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

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

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 Configuration/Exploitation Choix d'une solution Processus de déploiement Support

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 sont gérées les habilitations des utilisateurs? Quelles sont les identités strictement internes et externes?

plan de communication Analyse métier source(s) d'autorité sécurité mise en oeuvre communiquer sur les enjeux, les bénéfices et les risques établir des relations de confiance entre individus conduite du changement prise en compte des processus, de l'existant modèle de gouvernance des SI culture d'entreprise