sso fédération
DESCRIPTION
TRANSCRIPT
© copyright Janua 2009
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
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
navigateur
app. #1 app. #2 app. #3
service
serveur d'authentication
base d'utilisateurs
iden
tifia
nt
/
mot d
e
passe
Source: CSIER Février 2005
Architectures de SSO avec agent
navigateur
CASserver
TGC
HT
TP
Sapplication
TGCST
ST
ST
ID
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 [email protected] 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 [email protected]
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 [email protected]
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 [email protected] 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 – SAMLfournisseur de service
www.sp.com
Resource
vérificationd'accès
service deconsommation
d'assertions
fournisseur d'identitéwww.idp.com
service deSSO
Action Navigateur ou Utilisateur
Accèsressource
1
2
Redirection avec <AuthnRequest
3
Demanded'authent.
Authent.
GET avec <AuthnRequest
Réponse signéeen HTML
5Requête POSTsignée
6
Ressourcerenvoyée
7
4
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 SAMLet les protocoles de transport/messagerie standards
Protocoles:règle et format d'envoi des requêtes et réponsespermettant 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">
–</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
Source: Tutoriel Liberty Alliance Project v 2 - 2004
●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
Architectures de fédération – WS-*
Source: Tutoriel Liberty Alliance Project v 2 - 2004
●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
Méthodologie projet
Mise en oeuvreDéploiement
SpécificationsArchitecture logique
Analyse de l'existantBesoins / Exigences
Compréhension du besoinAnalyse métier
1
Définition du périmètre
Besoin (SSO,CDSSO,SLO)
Applications / Protocoles
Gestion des droits
Définition des livrables
Cahier des charges
Spécifications
Cahier de recette
Recensement du parc
Serveurs Web
Serveurs d'applications
Applis. Client / Serveur
Sources de données
Rôles et droits applicatifs
Types d'authentifcation
Annuaires, SGBD, Fichiers
Choix d'une solution
Clients (OS, browser, hard)
Fonctionnelles
Applications / Interfaces
Alimentation , synchros
Règles d'accès
Techniques
Architecture
Configuration produit
Exploitation
Processus de déploiement
Maquette
Install / Config SSO
Développements
Intégrations
Recette
Déploiement
Application(s) pilote(s)
Assistance au démarrage
Support
Formation
2 3 4
Configuration/Exploitation
Gestion des mots de passe
Gestion des mot de passe
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 ?
Analyse métier
●plan de communication–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