sso fédération

Formation SSO / Fédération

CYRIL GROSJEAN ([email protected])

CONSULTANT

JANUA

© 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]

mailto:[email protected]



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 .


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


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

–[email protected]

–</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 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: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


x

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


●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

sso fédération

Technology