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

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. Terminologie - SSO
SSO: Single Sign On
●
eSSO: Enterprise Single Sign On
●
CDSSO: Cross Domain Single Sign On
●
pseudo-SSO
●
SLO: Single Logout
●

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. 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. Terminologie - Fédération
SAML v2 (OASIS)
●
Consortium Liberty Alliance (ID-FF, ID-WSF, ID-SIS)
●
Shibboleth (Internet2)
●
WS-Federation (Microsoft)
●

7. Architectures de SSO
Avec agent (CAS,OpenSSO,JOSSO)
●
Sans agent / portefeuille (Oracle eSSO,SSOX)
●
Avec reverse proxy (LemonLDAP,JOSSO,OpenSSO,CAS)
●

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. Architectures de SSO avec agent
ID
CAS
server
application
ST
TGC
HTTPS
ST
ST
navigateur
Source: CSIER Février 2005
TGC

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

11. Architectures de SSO : Reverse Proxy

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

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

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. Architectures de fédération
SAML v2
●
Liberty Alliance
●
Shibboleth
●
OpenID
●
FederID
●
WS-Federation
●

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. 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. Architectures de fédération – SAML
Source: Présentation Aquarium – Sun Microsystems– Décembre 2008

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Architectures de fédération – Liberty
Source: Linagora groupe

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

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