Quels sont les défis de la
fédération d’identités?
Sébastien Bischof
Consultant / ELCA Informatique SA

Application Securi...
2

Bio
 Consultant en sécurité informatique @ ELCA
 Ethical hacker
 Il n’aime pas les biographies trop longues
– Mais i...
3

Agenda







Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiqu...
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 con...
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 e...
Bénéfices de la Fédération et du SSO
Federation & Single Sign On

Bénéfices

simplifier la
navigation de
l'utilisateur

Er...
TRUST

TRUST

Quelques explications

TRUST
Fonctionnement d’un trust entre 2 IDP SP
IdP et
XML File
Metadata
Endpoints URLs

IDP Public Key

Service Provider
IDP B

...
Architecture générique - LAN

9
Architecture générique - Internet

10
Architecture générique - Partenaire

11
Architecture générique - Social

12
Architecture générique

13
14

Agenda







Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiq...
15

Standards & tendances


SAML
– Standard OASIS pour le SSO
– Sécurité basée sur un échange de clés publiques entre 2 o...
16

Agenda







Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiq...
17

Cas d’utilisation théoriques
1.

“Because there are no passwords associated with a SAML assertion, which
virtually eli...
18

Agenda







Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiq...
19

La réalité – Quelques exemples (1)
 “Because there are no passwords associated with a SAML assertion,
which virtually...
20

La réalité - Quelques exemples (2)
 Avec la fédération il est possible de faire du SSO sur les
applications
– Oui mai...
21

La réalité - Quelques exemples (3)
 Avec la fédération la gestion des comptes utilisateurs
devient plus aisée et on p...
22

La réalité - Quelques exemples (4)
 L’interopérabilité entre les différentes
plateformes et protocoles de SSO est pos...
23

La réalité - Quelques exemples (5)
 Il est possible de permettre aux utilisateurs de se connecter
avec leurs logins s...
24

Exemple « pont d’authentification »
• En général, il faut personaliser
chaque module «social» pour
qu’il demande les
i...
25

Agenda







Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiq...
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é...
27

Agenda







Problématique générale
Standards & tendances
Cas d’utilisation théoriques
La réalité
Bonnes pratiq...
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
fair...
29

Questions?
30

Références
 https://www.oasisopen.org/committees/download.php/18104/SAMLOverview.pdf
 https://www.oasis-open.org/com...
31

Merci/Thank you!
Contact:

sebastien.bischof@elca.ch
32

Histoire de SAML
Prochain SlideShare
Chargement dans…5
×

ASFWS 2013 - Quels sont les défis de la fédération d’identité dans le Cloud ? par Sebastien Bischof

812 vues

Publié le

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.

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
812
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
25
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Executivesummary SAML: https://www.oasis-open.org/committees/download.php/13525
  • Mais comme le blog est pas trop a jour…
  • On verra si je laisse le lien vers mon twitter… 
  • Source image : SAML: https://www.oasis-open.org/committees/download.php/18104/SAML-Overview.pdf
  • ASFWS 2013 - Quels sont les défis de la fédération d’identité dans le Cloud ? par Sebastien Bischof

    1. 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. 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. 3 Agenda       Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
    4. 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. 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. 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. 7. TRUST TRUST Quelques explications TRUST
    8. 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. 9. Architecture générique - LAN 9
    10. 10. Architecture générique - Internet 10
    11. 11. Architecture générique - Partenaire 11
    12. 12. Architecture générique - Social 12
    13. 13. Architecture générique 13
    14. 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. 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. 16 Agenda       Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
    17. 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. 18 Agenda       Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
    19. 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. 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. 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. 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. 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. 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. 25 Agenda       Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
    26. 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. 27 Agenda       Problématique générale Standards & tendances Cas d’utilisation théoriques La réalité Bonnes pratiques Leçons apprises
    28. 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. 29 Questions?
    30. 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. 31 Merci/Thank you! Contact: sebastien.bischof@elca.ch
    32. 32. 32 Histoire de SAML

    ×