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.
ASFWS 2013 - Quels sont les défis de la fédération d’identité dans le Cloud ? par Sebastien Bischof
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é
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
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
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)
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
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
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 »
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