Embed Size (px)
DESCRIPTION
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.
Citation preview
Application Security Forum - 2013Western Switzerland
15-16 octobre 2013 - Y-Parc / Yverdon-les-Bainshttp://www.appsec-forum.ch
Quels sont les défis de la fédération d’identités?
Sébastien BischofConsultant / ELCA Informatique SA
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
Agenda
Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
Problématique générale1. Voici Mr Tartempion 2. Il arrive au bureau et se
log sur son PC3. Puis se connecte à un
portail collaboratif4. Et d’autres services5. Le soir il doit vite
valider un rapport et se connecte sur l’extranet
6. Mais il a oublié de récupérer le dit rapport dans son e-mail
7. Finalement, il doit vérifier certains points dans une base de connaissance
4
5
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.
Pourquoi la fédération d’identités
Merci!
Company Logo
Bénéfices de la Fédération et du SSOFederation & Single Sign On
Bénéfices
Ergonomie SimplifierL’accès
SécuriserL’accès
Faciliterl’intégration
simplifier la navigation de l'utilisateur
Un service unique d’authentification
Plus de mot passe mais des jetons qui transitent
Utilisation du standard SAML qui traverse les réseaux
Quelques explicationsTR
UST
TRUST
TRU
ST
IDP B Public KeyIDP B Public Key
IDP B administratorIDP B administrator
Fonctionnement d’un trust entre IdP et SP
XML File
Metadata
Endpoints URLs
IDP Public KeyIDP Public Key
SP Public KeySP Public Key
XML File
Metadata
Endpoints URLs
IDP administratorIDP administrator
SP administratorSP administrator
IDPIDP
Service ProviderService ProviderIDP BIDP B
IDP B Public KeyIDP B Public Key
2 IDP
9
Architecture générique - LAN
10
Architecture générique - Internet
11
Architecture générique - Partenaire
12
Architecture générique - Social
13
Architecture générique
14
Agenda
Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
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
Agenda
Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
17
Cas d’utilisation théoriques1. “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
Agenda
Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
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
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
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
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
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.
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
24
25
Agenda
Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
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
Agenda
Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
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
Questions?
30
Références https://
www.oasis-open.org/committees/download.php/18104/SAML-Overview.pdf
https://www.oasis-open.org/committees/download.php/13525 https://
www.usenix.org/system/files/conference/usenixsecurity12/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
32
Histoire de SAML
