De plus en plus d’organisations mettent en place un point d’accès unique pour l’accès à leurs portails web et à leurs applications internes. Un seul point d’accès est plus simple à gérer et sécuriser. Autre avantage pour la convivialité et la sécurité, les utilisateurs n’ont plus besoin de recourir aux post-its (habilement cachés sous leur clavier) pour se souvenir de leur (trop) nombreux mots de passe. Toutefois, avec l’essor des services dans le “cloud”, on voit de plus en plus d’applications être hébergées sur des serveurs distants, souvent pour ses propres applications, quelque fois par des partenaires ou simplement sur des plateformes de service type SalesForce. Et donc, retour à la case départ. Les développeurs doivent créer et maintenir du code SSO custom pour chaque application; les utilisateurs doivent réinvestir dans les postits (sauf si, consciencieux de réutiliser le même mot de passe partout, il préfère les exposer sur des plateformes non maitrisées); les help desks doivent intervenir sur de multiples systèmes avec des outils plus ou moins adaptés. Pour unifier tous ces nouveaux fournisseurs d’identité et services, et permettre le SSO sur des plateformes de tiers, il faut relever de nouveaux défis et résoudre de nouveaux problèmes. Ainsi, si une entreprise veut implémenter le SSO dans un tel contexte, il est peu probable de trouver une solution du marché capable de couvrir tous les besoins. Très vite, on se heurte à la multiplicité et l’hétérogénéité des protocoles d’authentification et au manque de souplesse des solutions qui ciblent très souvent des cas d’utilisation trop particuliers. Il faut alors avoir recours à un panachage de solution. Mais pas n’importe comment! Non seulement, il faut que le panachage couvre l’ensemble des besoins mais aussi il faut que les fonctionnalités retenues puissent cohabiter, l’une avec l’autre, avec les applications et services à intégrer, et enfin, avec l’infrastructure et l’organisation de l’entreprise.

1. Quels sont les défis de la
fédération d’identités?
Sébastien Bischof
Consultant / ELCA Informatique SA
Application Security Forum - 2013
Western Switzerland
15-16 octobre 2013 - Y-Parc / Yverdon-les-Bains
http://www.appsec-forum.ch

2. 2
Bio
 Consultant en sécurité informatique @ ELCA
 Ethical hacker
 Il n’aime pas les biographies trop longues
– Mais il aime des sujets variés allant des rootkits aux
fédérations d’identité

3. 3
Agenda






Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiques
Leçons apprises

4. 4
Problématique générale
1.
2.
3.
4.
5.
6.
7.
Voici Mr Tartempion
Il arrive au bureau et
se log sur son PC
Puis se connecte à un
portail collaboratif
Et d’autres services
Le soir il doit vite
valider un rapport et
se connecte sur
l’extranet
Mais il a oublié de
récupérer le dit
rapport dans son email
Finalement, il doit
vérifier certains points
dans une base de
connaissance

5. 5
Pourquoi la fédération d’identités
 Prérequis pour faire du Single-Sign-On (SSO)
 Franchir les frontières du réseau et donner accès
à des partenaires
 Pour préserver la chevelure de Mr. Tartempion
– En lui fournissant un accès simplifié et sécurisé (SSO)
aux applications.
Merci!

6. Bénéfices de la Fédération et du SSO
Federation & Single Sign On
Bénéfices
simplifier la
navigation de
l'utilisateur
Ergonomie
Un service unique
d’authentification
Simplifier
L’accès
Utilisation du standard
SAML qui traverse les
réseaux
Plus de mot passe
mais des jetons qui
transitent
Sécuriser
L’accès
Company Logo
Faciliter
l’intégration

7. TRUST
TRUST
Quelques explications
TRUST

8. Fonctionnement d’un trust entre 2 IDP SP
IdP et
XML File
Metadata
Endpoints URLs
IDP Public Key
Service Provider
IDP B
XML File
Metadata
Endpoints URLs
IDP administrator
IDP B Public Key
SP Public Key
IDP
IDP B administrator
SP administrator

9. Architecture générique - LAN
9

10. Architecture générique - Internet
10

11. Architecture générique - Partenaire
11

12. Architecture générique - Social
12

13. Architecture générique
13

14. 14
Agenda






Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiques
Leçons apprises

15. 15
Standards & tendances

SAML
– Standard OASIS pour le SSO
– Sécurité basée sur un échange de clés publiques entre 2 organisations (relation de confiance entre 2
organisations)
– Largement répandu (certains y réfèrent en tant que “standard clé” pour les fédérations)

WS-Fed
– Spécification faite par divers acteurs du Web (notamment Microsoft)
– Sécurité basée sur un échange de clés publiques, similaire à SAML car la relation de confiance est
entre 2 organisations
– Largement répandu

OpenID
– Protocole d’authentification décentralisé
– La confiance est déléguée à l’utilisateur (pour en bénéficier, l’utilisateur doit explicitement l’autoriser)

Oauth
– Protocole libre d’autorisation
– Donne l’autorisation à une application d’accéder aux données de l’utilisateur (à sa place)
– Largement répandu à cause/grâce aux terminaux mobiles (qui ne supportent pas forcément le SAML)

16. 16
Agenda






Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiques
Leçons apprises

17. 17
Cas d’utilisation théoriques
1.
“Because there are no passwords associated with a SAML assertion, which
virtually eliminates the risk of password theft due to phishing or other
hacking attacks.”
– Lu sur le site d’un “Federation vendor”
2.
Avec la fédération il est possible de faire du SSO sur les applications
3.
Avec la fédération la gestion des comptes utilisateurs devient plus aisée et on
peut donner accès à des applications aux partenaires. De plus, on est plus
obligés de gérer / payer des licences pour les comptes des partenaires
4.
L’interopérabilité entre les différentes plateformes et protocoles de SSO est
possible.
5.
Il est possible de permettre aux utilisateurs de se connecter avec leurs logins
sociaux

18. 18
Agenda






Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiques
Leçons apprises

19. 19
La réalité – Quelques exemples (1)
 “Because there are no passwords associated with a SAML assertion,
which virtually eliminates the risk of password theft due to phishing
or other hacking attacks.”
– Lu sur le site d’un “Federation vendor”
–
–
–
–
C’est techniquement juste, mais…
QUID des attaques par rejeu?
QUID des attaques cryptographiques?
QUID du faux sentiment de sécurité ?
 La façon dont est impémenté le standard est vraiment
importante
– Création du jeton (IdP)
– Validation du jeton (SP, SAML XSW)

20. 20
La réalité - Quelques exemples (2)
 Avec la fédération il est possible de faire du SSO sur les
applications
– Oui mais…
– Il faut un identifiant unique pour toutes les applications (c’est un
projet en soi)
– Attention aux applications qui dépendent d’accès à un annuaire,
l’impact peut être fort
• L’IdP doit être adapté pour faire du just-in-time provisionning pour ces
applications (developpement custom)
– QUID des applications Legacy ?
• Possible avec un WAF SAML qui peut faire le SSO (en envoyant les
crédentiels en NTLM, basic, « form replay », etc.)
– QUID des applications propriétaires non SAML/WS-Fed?
– QUID de la vérification des certificats?

21. 21
La réalité - Quelques exemples (3)
 Avec la fédération la gestion des comptes utilisateurs
devient plus aisée et on peut donner accès à des
applications aux partenaires. De plus, on est plus obligé de
gérer / payer des licences pour les comptes des partenaires
– Oui mais…
– Comment peut-on s’assurer que les partenaires font bien la
gestion des comptes ?
• Question de confiance / contrat
• Il y a un Attribut « AuthnContext » ou « level of assurance » qui peut
être utilisé. Mais il faut le vérifier et l’implémenter correctement. (côté
SP et IdP)

22. 22
La réalité - Quelques exemples (4)
 L’interopérabilité entre les différentes
plateformes et protocoles de SSO est possible.
– Oui mais…
– Il faut implémenter un “pont” d’authentification qui
permet de faire la conversion
• Possible avec des produits commerciaux (Ping federate,
Azure, etc.) – out of the box ?
• Et des produits opensource (SimpleSAMLphp) – on peut les
customiser mais cela demande du travail.

23. 23
La réalité - Quelques exemples (5)
 Il est possible de permettre aux utilisateurs de se connecter
avec leurs logins sociaux
– Oui mais…
• Chaque provider de login social fait un peu comme il veut avec son
implémentation de OAUTH
• Il faut créer des « modules » pour chaque provider de login social
• On est dépendant du service offert par le provider social
– QUID des changements « inopinés » ? *
– Il n’y a pas d’API « unifiée » excepté OpenID
– Il faut que l’application SSO-isée soit compatible avec le
protocole du provider social
• Ou créer un pont d’authentification qui fait la conversion en SAML par
exemple.

24. 24
Exemple « pont d’authentification »
• En général, il faut personaliser
chaque module «social» pour
qu’il demande les
informations dont on a besoin
pour identifier la personne
(ex: e-mail)
• Une fois l’authentification faite
chez le provider social, on
reçoit les attributs de
l’utilisateur
• Il faut convertir ces attributs
(différents pour chaque
provider social:
facebook.email, linkedin.
emailAddress, etc.) en
attributs «génériques»
• Puis les ajouter à l’assertion
SAML

25. 25
Agenda






Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiques
Leçons apprises

26. 26
Bonnes pratiques
 Défense en profondeur
– La sécurité est importante au niveau de l’IdP et du SP
• Sécurité de la clé privée de l’IdP (éviter l’impersonation)
• Validation de l’assertion côté SP (éviter le token replay)
 Bien réfléchir aux cas d’utilisation en amont
– Définir une stratégie « SSO »
• P.Ex: Uniformiser les méthodes d’authentification vers un
standard unique (SAML)
 Intégrer un produit qui convient au client (pas une usine à
gaz)
 Impacts opérationnels, pécuniers et d’intégration
 Pas de « silver bullet »

27. 27
Agenda






Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiques
Leçons apprises

28. 28
Leçons apprises
 Gestion des clés.
– Si la clé privée de l’IDP est compromise…. On peut générer des jetons et se
faire passer pour n’importe qui
– Empêcher les exports de clés sur les serveurs
• Peut-on l’empêcher techniquement ? (ex: export avec Mimikatz)
– Séparation des tâches (segregation of duty), audit sur le serveur, etc.
 Dans certains cas, l’IDP doit être publié sur internet, comment le protège-t-on ?


On peut utiliser un WAF.
Mais attention à l’intégration
 Attention à l’impact sur les applications lorsqu’on les SSO-ise
 La fédération d’identités réduit l’effort de gestion des identités mais ne
l’annule pas
 Les choix d’implémentation sont extrêmement importants
 Lorsque l’on intègre les logins sociaux, il peut y avoir des surprises

29. 29
Questions?

30. 30
Références
 https://www.oasisopen.org/committees/download.php/18104/SAMLOverview.pdf
 https://www.oasis-open.org/committees/download.php/13525
 https://www.usenix.org/system/files/conference/usenixsecurity
12/sec12-final91.pdf
 https://www.elca.ch/secutalk/?p=650
 http://en.wikipedia.org/wiki/Separation_of_duties
 http://en.wikipedia.org/wiki/OpenID
 http://en.wikipedia.org/wiki/Oauth
 http://en.wikipedia.org/wiki/SAML
 http://en.wikipedia.org/wiki/WS-Fed

31. 31
Merci/Thank you!
Contact:
sebastien.bischof@elca.ch

32. 32
Histoire de SAML