Authentification et Gestion des Identités Jean-Noël Colin jean-noel.colin@fundp.ac.be 1
Agenda Introduction Authentification Gestion distribuée d'identités Kerberos, CAS, OpenId, SAML, Shibboleth, Liberty Alliance 2
Agenda Introduction Authentification Gestion distribuée d'identités Kerberos, CAS, OpenId, SAML, Shibboleth, Liberty Alliance 3
Introduction Gestion d'identités (Rapport Gartner 2008) Administration des identités Création, modification des identités, rôles... 'User provisioning' Vérification Preuve de l'identité: authentification, SSO, Fédération...) Contrôle d'accès Autorisation et gestion des droits Surveillance Monitoring, journaux, audit... 4
Introduction Sujet d'actualité 25% des moyennes et grandes entreprises ont implémenté une solution 25% sont en phase d'évaluation (source: Gartner report, 2008) 5
Introduction Sujet complexe: augmentation constante Nombre d'applications à intégrer, nombre d'identités à gérer, nombre de ressources à protéger Pression règlementaire Risque de sécurité Coût de mise en oeuvre et de gestion 6
Introduction Sujet Entité pouvant être authentifiée Identité Ensemble homogène et cohérent de caractéristiques d'un sujet (attributs, préférences...) Identifiant Valeur permettant de référencer de manière univoque une entité Pseudonyme Identifiant préservant la confidentialité de l'identité du sujet Temporaire ou persistent 7
Introduction Quelques questions courantes D où venez-vous? Qui êtes-vous? Que puis-je savoir de vous? Puis-je vous croire? 8
Agenda Introduction Authentification Gestion distribuée d'identités Kerberos, CAS, OpenId, SAML, Shibboleth, Liberty Alliance 9
Authentification Authentification Identification Deux raisons pour authentifier L'identité est la base des décisions de contrôle d'accès L'identité est enregistrée dans les journaux de sécurité 10
Authentification Principe de base prouver mon identité au moyen de quelque chose que je connais password, PIN quelque chose que j ai token, smartcard quelque chose que je suis biométrie authentification multi-facteurs carte bancaire 11
Authentification Sécurité des mots de passe Politique de qualité des mots de passe (longueur, format, mots de passe faibles, historique) Mot de passe initial Réinitialisation du mot de passe Expiration forcée des mots de passe Nombre de tentatives infructueuses limité Délai imposé entre des tentatives infructueuses Modification des mots de passe par défaut Mémorisé si utilisé régulièrement Ne pas changer de mot de passe avant les vacances 12
Authentification taille alphabet 10 (chiffres) 26 (lettres) 62 (lettres M/m + chiffres) 90 (lettres M/m + chiffres + symboles) longueur mot de passe 4 7 10 8 10 16 8 10 16 8 10 16 longueur de clé équivalente (bits) 13 23 33 38 47 75 48 60 95 52 65 104 Ordre de grandeur du temps d énumération du dictionnaire des mots de passe possibles par un ordinateur personnel ~0 ~0 3 1h 1 mois 1 mois 500 ans 2 ans 20000 ans Source: Jean-Noël rapport Colin, University Règles of et Namur recommandations concernant les mécanismes d authentification de niveau de robustesse standard, Version 0.13 du 3 avril 2007, Secrétariat générale de la défense nationale de France. 13
Authentification Protection du mot de passe Lors du stockage Lors de la transmission Eviter de 'cacher' le mot de passe Attaque de type spoofing Fausse interface d'authentification destinée à collecter les mots de passe Contre-mesures Afficher l'historique des connexions Mécanisme sûr d'activation Authentification mutuelle 14
Authentification Attaques sur les mots de passe Problème Possédant son digest h, retrouver un mot de passe p parmi N choix possibles Ex: mots de passe de longueur 10, composés de lettres M/m et chiffres: 62 10 possibilités 8.4e17 Problème similaire Connaissant P et C, retrouver K tel que C = EK(P) De manière générale, inverser une fonction irréversible Paramètres considérés: T: nombre d opérations (hashage ou encryption) M: nombre de mots mémoire utilisés N: nombre de choix possibles (espace de clés) 15
Authentification Attaque brute force ou recherche exhaustive Principe: générer tous les mots de passe possibles en séquence, calculer leur hash et comparer celui-ci à h. En cas d égalité, le mot de passe recherché est trouvé En moyenne, le mot de passe sera trouvé en N/2 essais T = N, M = 1 16
Authentification Attaque par dictionnaire Principe: pré-calculer l empreinte de tous les mots de passe possibles et les stocker dans une table. rechercher h dans la table, ce qui permet de retrouver le mot de passe correspondant T = 1, M = N 17
Authentification Compromis temps-mémoire (time-memory trade-off) M. Hellman. A cryptanalytic time-memory trade-off. IEEE Transactions on Information Theory, 26(4):401 406, jul 1980. Idée: trouver le mot de passe (ou la clé) plus rapidement que la force brute tout en utilisant moins de mémoire que le dictionnaire Principes créer m chaines de t mots de passe le i ème mot de passe de la chaine est calculé à partir du (i-1) ème On ne mémorise que le premier et le dernier élément de chaque chaine 18
Authentification p 0,0 H R H R R H R h 0,0 p 0,1 h 0,1 p 0,2... p 0,t-2 h 0,t-2 p 0,t-1 =r p 1,0 h 1,0 p 1,1 h 1,1 p 1,2... p 1,t-2 h 1,t-2 p 1,t-1 p 2,0 h 2,0 p 2,1 h 2,1 p 2,2... p 2,t-2 h 2,t-2 p 2,t-1..................... r = pm-2,t-1... p m-2,0 h m-2,0 p m-2,1 h m-2,1 p m-2,2... p m-2,t-2 h m-2,t-2 p m-2,t-1 =r p m-1,0 h m-1,0 p m-1,1 h m-1,1 p m-1,2... p m-1,t-2 h m-1,t-2 p m-1,t-1 h i,j = H(p i,j ) i [0,m-1], j [0,t-1[ p i,j = R(h i,j ) i [0,m-1], j [1,t-1] H: fonction à inverser (hash ou chiffrement) R: fonction de réduction soit h, le hash du mot de passe à craquer calculer r = R(h) 19
Authentification p 0,0 H R H R R H R h 0,0 p 0,1 h 0,1 p 0,2... p 0,t-2 h 0,t-2 p 0,t-1 p 1,0 h 1,0 p 1,1 h 1,1 p 1,2... p 1,t-2 h 1,t-2 p 1,t-1 p 2,0 h 2,0 p 2,1 h 2,1 p 2,2... p 2,t-2 h 2,t-2 p 2,t-1........................ p m-2,0 h m-2,0 p m-2,1 h m-2,1 p m-2,2... p m-2,t-2 h m-2,t-2 p m-2,t-1 p m-1,0 h m-1,0 p m-1,1 h m-1,1 p m-1,2... p m-1,t-2 h m-1,t-2 p m-1,t-1 h i,j = H(p i,j ) i [0,m-1], j [0,t-1[ p i,j = R(h i,j ) i [0,m-1], j [1,t-1] H: fonction à inverser (hash ou chiffrement) R: fonction de réduction si r = R(h) ne se trouve pas dans la dernière colonne, on réessaie avec R(H(R(h))), puis avec R(H(R(H(R(h)))))... 20
Authentification Efficacité soit une table de m chaines de longueur t, soit m.t éléments M = m.m0 où m0 est l espace nécessaire pour stocker (pi,0,pi,t-1) cas défavorable: (t-1) opérations de hash nécessaires si tous les éléments de la table sont différents, la probabilité de trouver la clé est mt/n Hellman montre que: P table 1 N m t 1 i=1 j =0 1 it N j +1 21
Authentification Limitations collision et fusion de chaines collision: conséquence: doublons dans la table plus la table est grande, plus la probabilité de fusion est grande, donc l efficacité de la table décroit avec sa taille solution: générer l tables avec R0, R1,... Rl-1 dans ce cas: x, y x y R(x) = R(y) P table 1 1 1 N m t 1 i=1 j =0 1 it N j +1 l 22
Authentification p 0,0 Table arcs-en-ciel (rainbow table) - P. Oechslin fonction de réduction différente à chaque étape H R 0 H R 1 R t-3 H R t-2 h 0,0 p 0,1 h 0,1 p 0,2... p 0,t-2 h 0,t-2 p 0,t-1 p 1,0 h 1,0 p 1,1 h 1,1 p 1,2... p 1,t-2 h 1,t-2 p 1,t-1 p 2,0 h 2,0 p 2,1 h 2,1 p 2,2... p 2,t-2 h 2,t-2 p 2,t-1........................ p m-2,0 h m-2,0 p m-2,1 h m-2,1 p m-2,2... p m-2,t-2 h m-2,t-2 p m-2,t-1 p m-1,0 h m-1,0 p m-1,1 h m-1,1 p m-1,2... p m-1,t-2 h m-1,t-2 p m-1,t-1 h i,j = H(p i,j ) i [0,m-1], j [0,t-1[ p i,j = R(h i,j ) i [0,m-1], j [1,t-1] H: fonction à inverser (hash ou chiffrement) R i : fonction de réduction 23
Authentification Avantage cas défavorable: t(t-1)/2 opérations de hash nécessaires plus efficace que la méthode de Hellman: prenons t tables m.t (Hellman) et 1 table mt.t (Rainbow table), soit mt 2 mots de passe dans les deux cas les probabilités de succès sont approximativement égales T = t 2 (Hellman) vs T = t(t-1)/2 (Rainbow tables) http://www.kromcrack.com/rainbow-tables.php 24
Authentification Données biométriques Données physiologiques ou comportementales empreinte digitale, rétinienne, vocale, frappe clavier Collecte des modèles Identification: trouver 1 parmi n Authentification: vérifier la correspondance pour 1 Algorithme de correspondance avec seuil 25
Authentification One-Time Passwords (OTP) principe: le client génère un mot de passe et l envoie au serveur pour établir la session. Ce mot de passe est valable pour une seule session/transaction unique rend inutile toute tentative d attaque brute force, dictionnaire ou rejeu mot de passe peut circuler en clair généré automatiquement plus besoin de le mémoriser 26
Authentification One-Time Passwords (OTP) secret partagé entre client et serveur mode de génération de OTP OTP = f(secret partagé, horloge) OTP = f(secret partagé, n de séquence) OTP = f(secret partagé, challenge aléatoire) autres solutions liste papier matrice de mots de passe cryptographie asymétrique au lieu d un secret partagé 27
Authentification One-Time Passwords (OTP) Vulnérabilités Social engineering Phishing MITM 28
Authentification Social engineering Le Social engineering consiste à manipuler, influencer ou tromper une personne pour l amener à effectuer une action. Souvent, cette action consiste à révéler de l information confidentielle ou toute autre action au bénéfice de l attaquant. L être humain est le point faible Sensible à l autorité, la gentillesse, le sentiment d urgence, de similarité, sens des responsabilités Cibles typiques Personne peu concernée par la sécurité Rôles de support/aide Rôles privilégiés Personne avec connaissance spécifique Personne avec accès à des actifs de valeur (information ou économique) 29
Authentification Le facteur humain est le maillon faible 30
Authentification Types d attaques physique Fouille (dumpster diving), vol, extortion, desktop hacking sociale Basé sur la tromperie ou fausse relation Mixte Récolte d information Développement de la relation Exploitation de la relation Action pour atteindre l objectif 31
Authentification Méthode de protection Education Défis principaux Distinguer le vrai du faux, le bien du mal Critères et procédure de reporting Savoir quand et comment rapporter un problème Définir des politiques claires Définir des lignes de communication claires Coordination entre sécurité IT et sécurité organisation 32
Authentification Sources des identités Fichier Simple à implémenter Expressivité limitée Encryption des données sensibles Contrôle d'accès aux données Base de données Simple à implémenter Modèle de données flexible et extensible Encryption des données sensibles Contrôle d'accès aux données Souvent spécifique à une application 33
Authentification LDAP Lightweight Directory Access Protocol Définit un protocole d'accès et un modèle de données Dérivé du standard X.500 Organise l'information sous forme d'arbre: DIT Directory Information Tree Données stockées sous forme de noeuds organisés en arbre structure des noeuds définis dans un schéma extensible Éléments du schéma identifiés par un Object Identifier (OID) Root suffix: racine de l'arbre ex: dc=fundp, dc=ac, dc=be 34
Authentification LDAP Lightweight Directory Access Protocol Noeud = DSE Directory Service Entry Identifié par un nom (DN & RDN) Instantiation d'une ou plusieurs classes ObjectClass Définit les attributs obligatoires et optionnels Héritage de classes Représente un utilisateur, un groupe (statique ou dynamique) Ou une entité quelconque: il faut juste définir l'objectclass approprié 35
Authentification LDAP Lightweight Directory Access Protocol Protocole d'accès: session Bind (ouverture de session) authenticated or anonymous Opération(s) search, delete, modify (add ou update) Unbind (fermeture de session) Contrôle d'accès Access Control List définit name, target, permission, bind rules aci: (target="ldap:///uid=jnc,dc=example,dc=com") (targetattr="*")(version 3.0; acl "example aci"; allow (write) userdn="ldap:///self";) Souvent spécifique à une implémentation 36
Authentification Sources indépendantes Simple Isolation Multiplication des identités Risque d'incohérence 37
Authentification Sources partagées Une seule identité Si identité compromise, plusieurs services compromis 38
Authentification Synchronisation des sources Une seule identité Coût de synchronisation Implémentation spécifique 39
Authentification Service d'authentification Libère l'application de la gestion des identités et du processus d'authentification Requiert un protocole sûr Requiert la confiance, éventuellement interorganisations 40
Agenda Introduction Authentification Gestion distribuée d'identités Kerberos, CAS, OpenId, SAML, Shibboleth, Liberty Alliance 41
Gestion distribuée d'identités Principes Deux rôles Partie requérante (relying party) Fournisseur de service (Service provider) Partie certifiante (asserting party) Fournisseur d'identité (Identity provider) Relation de confiance Confiance: je crois ce que l autre me dit 42
Gestion distribuée d'identités Single Sign-On (SSO) Une seule authentification donne accès à plusieurs services Fédération d'identités Accord entre fournisseurs sur une manière commune de référencer un sujet Identifiant Attributs Définit un cercle de confiance (circle of trust) 43
Gestion distribuée d'identités Motivations Une source autoritaire de données Information sur les utilisateurs, privilèges Meilleur contrôle sur la vie privée Moins de travail de gestion des données des utilisateurs Sécurité Les données d'authentification ne sont jamais connues des Service Providers Coopération Accès aux ressources d'autres organisations de manière transparente 44
Gestion distribuée d'identités Motivations Satisfaction des utilisateurs Éviter les identifications et authentifications répétées Unifier la gestion des données d'identité Donner à l'utilisateur le contrôle sur la confidentialité de ses données (user centric) Architecture logicielle Décharger l'application des tâches d'authentification et de gestion des données personnelles Approche modulaire Abstraction du mécanisme d'authentification 45
Gestion distribuée d'identités Gestion distribuée requiert Standards flexibles et extensibles pour la représentation des données Protocoles d'échange d'information Indépendant de la technologie sous-jacente Préservant la confidentialité des données Interopérable Mécanismes de gestion de la confiance 46
Gestion distribuée d'identités Choix d une approche: Fonctionnalités Gestion des identités Unique, multiple? Qui gère? Utilisateur? Organisation? Respect de la vie privée Attributs Fédération ou délégation? Mécanisme de fédération Sur base des identifiants? Attributs? Pseudos? 47
Gestion distribuée d'identités Choix d une approche: Services Authentification Autorisation Attributs Pseudonyme/anonyme Service de découverte Journaux et audits 48
Gestion distribuée d'identités Choix d une approche: Gestion de la confiance Domaine unique? Cross-domain? Modèle de confiance? 49
Gestion distribuée d'identités Choix d une approche: Déploiement Protocoles utilisés Communication Sécurisation Authentification, autorisation Plateformes supportées, interopérabilité Code disponible, propriétaire ou non Résistance aux attaques: phishing, MITM, id de session 50
Gestion distribuée d'identités Lignes directrices de l OCDE limitation en matière de collecte qualité des données limitation de l'utilisation garanties de sécurité participation individuelle responsabilité 51
52 Kerberos
Needham-Schroeder Protocole d'authentification et d'échange de clé Alice (A) et Bob (B) veulent communiquer de manière sûre Échange d'un secret Authentification du partenaire Utilisation d'un tiers de confiance (T) Partage une clé différente avec chaque participant KAT = Clé secrète partagée par A et T Génération d'une clé de session K pour le dialogue entre Alice et Bob Utililisation de nombres aléatoires (nonce) pour contrer les attaques par rejeu 53
Needham-Schroeder Trent 1. A, B, R a 2. {Ra, B, K, {K, A}KBT }KAT 3. {K, A} KBT 4. {R b } K Alice 5. {R b -1} K Bob 54
Kerberos Objectif: authentifier un sujet tout en évitant la transmission de données qui permettraient de se faire passer pour ce sujet Système d'authentification distribué développé par le MIT Basé sur le protocole Needham-Schroeder Mécanisme de ticket: lorsqu'un client C veut accéder à un service S, il a besoin d'un ticket Tc,s pour prouver son identité Authentification du client par mot de passe Mot de passe conservé par le serveur Kerberos 55
Kerberos Cryptographie symétrique pour le chiffrement du mot de passe sur le serveur Le serveur est capable de déchiffrer les mots de passe Supporte Single Sign-On (SSO) Authentification mutuelle Renouvellement de ticket Délégation d'authentification 56
Kerberos Deux services Service d'authentification (aka KDC) Service de délivrance de ticket (Ticket Granting Service TGS) Deux phases Login Obtenir un TGT Ticket Granting Ticket Contient une clé de session + un ticket pour le TGS (TTGS) Demande d'accès à un service Obtenir un Ticket 57
Kerberos Remarques: Les mots de passe sont stockés uniquement sur le serveur Les mots de passe ne sont jamais transmis sur le réseau Les mots de passe constituent la base de l'authentification mutuelle entre le Client et le Service d'authentification 58
Kerberos Authentification 59
Kerberos Accès au service 60
Kerberos Authentification Cross-realm Établissement d'une relation de confiance entre les KDCs des deux realms, via un secret partagé Relation transitive: facilite la gestion des clés en définissant un chemin de confiance de realm en realm Délégation 61
Kerberos Tickets particuliers Tickets renouvellables Tickets postdatés Initialement invalides, date de validité dans le futur Tickets transmissibles Forme de TGT permettant de demander un nouveau ticket, mais avec une IP différente Notons encore que Kerberos ne protège pas contre une attaque brute force ou mots de passe faibles requiert un canal sûr pour établir le mot de passe 62
63 Yale's CAS
Central Authentication Service Objectif: service d'authentification centralisé, pour les applications Web Inspiré de Kerberos Basé sur le protocole HTTP(S) Développé par l'université de Yale Repris par le consortium jasig depuis 2004 Version 3 disponible, version 4 en préparation http://www.jasig.org/cas Supporté par de nombreuses plateformes (Moodle, uportal, Shibboleth, Liferay, Mantis...) 64
Central Authentication Service Architecture Serveur CAS Authentifie les utilisateurs Certifie les identités des utilisateurs envers les clients CAS Mécanismes d'authentification supportés: Client CAS AD, JAAS, JDBC, LDAP, RADIUS, X.509... Application Web, supportant l'authentification via CAS Librairies disponibles pour.net, Java, ColdFusion, Perl, PHP, Ruby, Zope... Browser 65
Central Authentication Service Première étape: authentification Authentication TGC: Ticket Granting Cookie 66
Central Authentication Service Deuxième étape: accès au Client Id ST TGC ST ST: Service Ticket 1. Demande d'accès 2. Redirection vers le serveur CAS et présentation du TGC 3. Obtention du ST 4. Validation du ST et récupération de l'id 67
Central Authentication Service Ticket Granting Cookie Equivalent du TGT de Kerberos Utilisé pour obtenir un ticket d'accés à un service Ne contient aucune information personnelle Cookie privé (seulement pour le CAS serveur) Durée de vie limitée Service Ticket Usage unique Délivré par le serveur CAS sur présentation du TGC Durée de vie très limitée (quelques secondes) Spécifique à un client et à un service 68
Central Authentication Service Validation du ST Si ticket valide Retourne l'identifiant de l'utilisateur Format texte brut ou xml Si ticket invalide, retourne une erreur Possibilité de retourner d'autres informations que l'identifiant Attributs 69
Central Authentication Service Gestion des services Depuis la version 3.1.1 Permet de définir: Quels services (clients) peuvent accéder au serveur Quelles informations de l'utilisateur peuvent être communiquées au client Meilleur contrôle sur la confidentialité des informations Premiers pas vers un mécanisme d'autorisation 70
Central Authentication Service CAS dans un environnement multi-couches Mécanisme de proxy Proxy CAS = Client CAS Problème: pour obtenir un ST pour un service, il faut le TGC, mais un Proxy CAS n'y a pas accès Solution: PGT Proxy Granting Ticket Equivalent pour le Proxy CAS du TGC pour le Browser Permet au Proxy CAS de demander au Serveur CAS un ticket (PT - Proxy Ticket) pour accéder à un Client Durée de vie limitée (quelques heures) Opaque 71
Central Authentication Service Mécanisme de Proxy Id PT PGT PT Id TGC ST ST PGT Service Backend PT 1. Demande d'accès 2. Redirection vers le serveur CAS et présentation du TGC 3. Obtention du ST 4. Validation du ST et récupération de l'id et du PGT 5. Demande d'accès au service backend et présentation du PGT 6. Obtention du PT et accès au service back-end 7. Validation du PT et récupération de l'id CAS Proxy 72
Central Authentication Service Mécanismes d'extension Authentification Front-end Fournisseur d'attributs Stockage des tickets 73
74 OpenId
OpenId 75
OpenId OpenID Provider (OP) Relying Party(RP) 76
OpenId Scénario simplifié 1. Mon identifiant est jn.colin.myopenid.com 3. C est vrai! Relying Party(RP) OpenID Provider(OP) 2. Est-ce vrai? 77
OpenId Scénario un peu plus complet 1. Mon identifiant est jn.colin.myopenid.com 4. C est vrai! 3. Validation et confirmation 2. Est-ce vrai? 78
OpenId En quelques mots OpenID propose un protocole ouvert pour une gestion décentralisée des identités, mettant l'utilisateur au centre des décisions le concernant http://openid.net OpenID est développé et supporté par la Fondation OpenId, organisée en chapitres locaux Acteurs privés importants: Google, Yahoo, Microsoft, IBM, Verisign Well-known OPs, like AOL, Google, and Yahoo! Exemple: http://www.livejournal.com 79
OpenId 80
OpenId Concepts OpenID Identifier URI (http ou https) ou XRI OpenID Provider (OP) Gère les identités Accessible via un service public (Endpoint URL) Atteste d'une authentification réussie OpenID Relying Party (RP) Demande la preuve d'une authentification du sujet par l'op 81
OpenId Types de communication Le protocole est basé sur HTTP Paramètres passés sous forme de paires (clé, valeur) Communication directe Initiée par le RP vers l'op HTTP POST Communication indirecte Au travers du navigateur Initiée aussi bien par le RP que par l'op HTTP Form submission ou HTTP Redirect 82
OpenId 83
OpenId Initialisation Utilisateur fournit un identifiant Soit le sien http://benoit.xvi.myopenid.com Soit celui d'un OP https://www.myopenid.com/ Normalisation 'Nettoyage' de l'identifiant fourni à la phase précédente en préparation de la phase de découverte' Détermine le type d'identifiant: XRI or URI? Résolution des redirections et règles rfc3986 84
OpenId Découverte A partir de l'identifiant normalisé, détermine l'information nécessaire pour établir une connexion avec un OP OP Endpoint URL Version(s) du protocole supportée(s) Identifiant peut être soit celui de l'utilisateur, soit celui de l'op 85
OpenId Découverte html > wget --save-headers http://jn.colin.myopenid.com HTTP/1.1 200 OK Date: Tue, 28 Jul 2009 07:34:06 GMT Server: Apache/2.2... X-XRDS-Location: http://jn.colin.myopenid.com/?xrds=1 Set-Cookie:... P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"... <html> <link rel="openid.server" href="http://www.myopenid.com/server" /> <link rel="openid2.provider" href="http://www.myopenid.com/server" /> <link rel="stylesheet" href="http://www.myopenid.com/static/idpages/idpage.css" /> 86
OpenId Découverte XRDS > wget --save-headers http://jn.colin.myopenid.com/?xrds=1 <?xml version="1.0" encoding="utf-8"?> <xrds:xrds xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD version="2.0"> <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type> <Type>http://openid.net/srv/ax/1.0</Type> <URI>http://www.myopenid.com/server</URI> <LocalID>http://jn.colin.myopenid.com/</LocalID> </Service> 87
OpenId Découverte XRDS <Service priority="1"> <Type>http://openid.net/signon/1.1</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type> <Type>http://openid.net/srv/ax/1.0</Type> <URI>http://www.myopenid.com/server</URI> <openid:delegate>http://jn.colin.myopenid.com/</openid:delegate> </Service>... </XRD> </xrds:xrds> 88
OpenId Requête d authentification Key openid.ns openid.mode openid.claimed_id openid.identity openid.assoc_handle openid.return_to openid.realm Value http://specs.openid.net/auth/2.0 checkid_setup http://jn.colin.myopenid.com/ http://jn.colin.myopenid.com/ {HMAC-SHA1}{4bbb1d7b}{/Hxxkw==} http://www.livejournal.com/openid/login.bml? oic.time=1271157871-8dbf9c9e61031949de0f http://www.livejournal.com/ 89
OpenId Key Authentication Response openid.ns openid.mode openid.op_endpoint openid.claimed_id openid.identity openid.return_to openid.response_nonce openid.assoc_handle openid.signed openid.sig Value http://specs.openid.net/auth/2.0 id_res http://www.myopenid.com/server http://jn.colin.myopenid.com/ http://jn.colin.myopenid.com/ hhttp://www.livejournal.com/openid/login.bml? oic.time=1271157871-8dbf9c9e61031949de0f 2010-04-13T11:33:58ZVA0pwk {HMAC-SHA1}{4bbb1d7b}{/Hxxkw==} assoc_handle,claimed_id,identity,mode,ns,op_endpoint,response_ nonce,return_to,signed F2xCeQ6Cc8sJw9Bn890+ABFGkCM= 90
OpenId Version URL http://www.myopenid.com/server?openid.ns=http://specs.openid.net/auth/ 2.0&openid.return_to=http://www.livejournal.com/openid/login.bml%3Foic.time %3D1248696343-762ba9d4502cab7675ca&openid.claimed_id=http:// jn.colin.myopenid.com/&openid.identity=http://jn.colin.myopenid.com/ &openid.mode=checkid_setup&openid.realm=http://www.livejournal.com/ &openid.assoc_handle=%7bhmac-sha1%7d%7b4a5c2323%7d%7btxx1ha %3D%3D%7D 91
OpenId Version URL http://www.livejournal.com/openid/login.bml? oic.time=1248696343-762ba9d4502cab7675ca&openid.assoc_handle=%7bhmac- SHA1%7D%7B4a5c2323%7D%7BTxx1HA%3D%3D%7D&openid.claimed_id=http%3A %2F%2Fjn.colin.myopenid.com%2F&openid.identity=http%3A%2F %2Fjn.colin.myopenid.com%2F&openid.mode=id_res&openid.ns=http%3A%2F %2Fspecs.openid.net%2Fauth%2F2.0&openid.op_endpoint=http%3A%2F %2Fwww.myopenid.com %2Fserver&openid.response_nonce=2009-07-27T12%3A08%3A48Z1giwoS&openid.return_t o=http%3a%2f%2fwww.livejournal.com%2fopenid%2flogin.bml%3foic.time %3D1248696343-762ba9d4502cab7675ca&openid.sig=QK87KjU0snL30D %2BP8XkswydJLPs%3D&openid.signed=assoc_handle%2Cclaimed_id%2Cidentity %2Cmode%2Cns%2Cop_endpoint%2Cresponse_nonce%2Creturn_to%2Csigned 92
OpenId En cas d échec Key openid.ns openid.mode Value http://specs.openid.net/auth/2.0 cancel Version URL http://www.livejournal.com/openid/login.bml?oic.time=1248696997- b0656f4a4e6bb38a2d17&openid.mode=cancel&openid.ns=http%3a%2f %2Fspecs.openid.net%2Fauth%2F2.0 HTTP/1.1 93
OpenId Validation Du côté de l'op Authentifier l'utilisateur (ou valider une authentification antérieure) Validation complémentaire Vérification de l'url de retour avec le service endpoint du RP Du côté du RP Vérification: URL de retour (openid.return_to) correspond à l'url qui traite l'assertion Vérification de l'information découverte Vérification du nonce 94
OpenId Sécurité des messages Objectif: garantir l'intégrité de la communication Signature des réponses par OP HMAC-SHA1 ou HMAC-SHA256 Vérification de la signature par RP 95
OpenId Mode 'smart' Etablissement préalable à tout échange d'une Association (secret partagé) entre RP et OP Message direct 'associate' Clé MAC établie Soit par l'op Fortement recommandé d'utiliser SSL!! Soit négociée par Diffie-Hellman Valeurs par défaut pour le générateur et le modulus 96
OpenId Requête d'association Mode de signature: HMAC-SHA256 Type de session: DH-SHA256 openid.ns=http%3a%2f%2fspecs.openid.net%2fauth %2F2.0&openid.mode=associate&openid.session_type=DH- SHA256&openid.assoc_type=HMAC- SHA256&openid.dh_consumer_public=BoRbXby16PkQ3K39HrOUMmc QkXEHunfYnTffz6wFsAmGbHBDvDk0Cp99P3h2fll04DhJ%2BlOlApH %2BN%2B9WiyimtSEI9o8Z9xeCziWqZ2eu3Wpto5h%2BKExT0mNCc %2FsQGMyeok45JmOTAoye9o8%2Bznl1eM7aJERoav3gAWq44jHTfgc %3D 97
OpenId Réponse d'association assoc_handle:{hmac-sha256}{4a6dae6e}{wa0maq==} assoc_type:hmac-sha256 dh_server_public:u +IqMuc91HB3Nl4fJwA893XcnlSAwGUXGZSzT3PU77FqlePqMtsiuhAL5PeZfPpK T/776APjsPmU8gj/Iedd6J0y+tyLlQgHW/wTi+kriMj5esah +csntlbyid2j8usaxq120ibpj4hcbvbnl19yjbopngvqlogra2ogn8kervy= enc_mac_key:gd1v4ixgni7jrrt1aho9o4knoc0tgyf4adit6s2chdy= expires_in:1209600 ns:http://specs.openid.net/auth/2.0 session_type:dh-sha256 98
OpenId Mode 'dumb' Pas de gestion des associations au niveau du RP Validation a posteriori de la réponse via une communication directe entre le RP et l'op Message direct 'check_authentication' Copie exacte des champs reçus dans la réponse d'authentification OP valide sa propre signature OP ne peut pas valider plus d'une fois une réponse d'authentification Plus lourd en terme d'échanges 99
OpenId Mesures de sécurité Utilisation de SSL pour se protéger d'une écoute illicite (eavesdropping) Utilisation d'un nonce pour se protéger d'une attaque par rejeu Utilisation de signature digitale pour garantir l'authenticité et l'intégrité des réponses de l'op MITM possible durant la phase de découverte et les communications directes (association et validation directe) Possibilité de signer les données découvertes pour garantir leur authenticité 100
OpenId Mécanisme d'extension Utilise les mêmes messages que le protocole de base Définit de nouveaux champs pour les messages Identifiés par un 'namespace' Ex: openid.ns.<extension_alias>=http://openid.net/srv/ax/1.0 101
OpenId Extension SREG: Simple Registration Objectif: obtenir des informations sur le sujet Etend la requête d'authentification openid.sreg.required openid.sreg.optional openid.sreg.policy_url Champs valides: nickname, email, fullname, dob, gender, postcode, country, language, timezone Valeurs ajoutées à la réponse d'authentification Valeurs retournées par l'op doivent être signées 102
OpenId Extension AX: Attribute Exchange Objectif: échanger des informations sur le sujet Etend le protocole d'authentification Définit deux méthodes: fetch: demande d'attribut(s) du RP vers OP store: envoi d'attribut(s) du RP vers OP Support pour attributs obligatoires, facultatifs et multivalués 103
OpenId Extension PAPE: Provider Authentication Policy Objectif: permettre à RP de spécifier à OP le mode d'authentification à utiliser, et à l'op de le communiquer Etend le protocole d'authentification Requête max_auth_age, preferred_auth_policies, niveaux d'authentification spécifiques Réponse auth_policies, auth_time, niveaux d'authentification spécifiques 104
105 SAML
SAML Security Assertion Markup Language SAML est un standard de l'organization for the Advancement of Structured Information Standards (OASIS) IBM, Microsoft, Oracle, Sun,... Plusieurs centaines de contributeurs Autres standards OASIS: ebxml, XACML,, SPML, UDDI, WS- Security, WS-Trust, WS-Federation,... SAML v1.0 (11/2002), SAML v1.1 (9/2003), SAML v2.0 (3/2005) 106
SAML Motivations Interopérabilité Cross-Domain SSO Interopérabilité de solutions SSO Sécurité des Web Services Fédération d'identités A la base ou intégré dans de nombreuses autres solutions Shibboleth, Liberty Alliance... 107
SAML SAML définit un format de messages un protocole de communication permettant d'échanger entre partenaires des informations d'authentification, d'attributs et d'autorisation de manière sécurisée mais aussi Des scénarios d'utilisation 108
SAML Modèle en couches Profiles Bindings Protocoles Assertions 109
SAML Assertion Ensemble d'affirmations (statements) Emis par une autorité (issuer) A propos d'un sujet (subject) Conditions de validité Temporelles, audience, proxy Information complémentaire 110
111
SAML Différents types d identifiants Durée de vie Temporaire, persistant, permanent Transparence Opaque, transparent Ciblé Révocable Réutilisable 112
SAML 3 types de statements Authentication Statement Affirme qu'un sujet a été authentifié Attribute Statement Affirme qu'un sujet possède un attribut Authorization Decision Statement Affirme qu'un sujet a reçu l'autorisation d'effectuer une action 113
SAML Authentication Statement Certifie qu'un sujet a été authentifié à un moment précis par un mécanisme donné SubjectLocality 114
115
SAML Contexte d'authentification Définit les conditions d'authentification Permet à RP de déterminer le niveau de confiance à placer dans l'assertion Couvre les concepts suivants: Méthodes d'identification Mesures techniques de protection du 'secret' (données d'authentification) Mesures opérationnelles de protection (audit, archivage...) Méthodes d'authentification Cadre légal et réglementaire 116
117
SAML Méthodes d'identification 118
SAML Mesures techniques de protection 119
SAML Mesures opérationnelles de protection 120
SAML Méthodes d'authentification Password, token, smartcard, pin... Méthode crypto, adresse IP, signature digitale... HTTP, SSL, IPSec, ADSL, PSTN... 121
SAML Cadre légal et réglementaire 122
SAML Classe de Contexte d'authentification Définit un sous-ensemble de contexte d'authentification Correspond à une pratique courante Facilite le dialogue et l'accord sur des méthodes entre RP et AP Ex: password, kerberos, PasswordProtectedTransport, Public Key X.509, Public Key PGP,... 123
SAML Attribute Statement Certifie qu'un sujet possède les attributs spécifiés 124
SAML Attribute Profile Raffine le protocole (flexible) en spécifiant de manière détaillée et complète le nommage et la syntaxe des attributs Objectif: assurer l interopérabilité Exemples: LDAP <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="givenName"> <saml:attributevalue xsi:type="xs:string" x500:encoding="ldap">steven</saml:attributevalue> </saml:attribute Mais aussi: UUID, GUID, XACML, DEC PAC 125
SAML Authorization Decision Statement Certifie qu'une requête d'accès pour une ressource donnée Identifiée par un URI pour une action donnée par le sujet a résulté dans la décision spécifiée Permit, Deny, Indeterminate Figé dans la version 2.0. XACML désigné comme successeur 126
SAML Authorization Decision Statement 127
SAML Intervenants Fournisseur d'identité - Identity Provider (IdP) Système qui certifie une information concernant un sujet Aka Asserting Party Fournisseur de service - Service Provider (SP) Système qui consomme l'information fournie par l'idp Aka Relying Party 128
SAML Composants Identity Repository SP IdP Browser 129
SAML Protocole d'échange Protocole requête/réponse Demande d'assertion Requête par référence: AssertionIDRequest Requête par sujet: Query Demande des assertions contenant des statements relatif au sujet AuthnQuery: quelles assertions concernant des statements d'authentification sont disponibles pour le sujet? AttributeQuery: envoi des attributs demandés AuthzQuery: l'action demandée est-elle permise pour le sujet sur la ressource spécifiée? 130
SAML Requête d authentification Demande à l IdP d authentifier un sujet donné Et de retourner l identifiant dans un format donné Et d authentifier le sujet selon des mécanismes définis... 131
SAML AuthnRequest ForceAuthn IsPassive AssertionConsumerServiceIndex AssertionConsumerServiceURL ProtocolBinding AttributeConsumingServiceIndex ProviderName 132
SAML Autres protocoles Artifact Resolution Protocol Utilisé pour récupérer un message SAML par référence plutôt que par valeur Name Identifier Management Protocol Utilisé pour informer de la modification ou de la suppression d'un identifiant pour un sujet Single Logout Protocol Utilisé pour terminer la session de manière quasi-simultanée avec tous les participants Name Identifier Mapping Protocol Utilisé pour établir des correspondances de nom pour un sujet 133
SAML Réponse: liste de 0-N assertions 134
SAML Binding SAML définit une manière de transmettre les messages (requête et réponse) définis dans les protocoles entre un SAML Requester et un SAML Responder Authentification de l'origine optionnelle Intégrité des messages optionnelle Confidentialité des messages optionnelle 135
SAML SAML SOAP Binding Transmet les messages SAML dans le corps d'un message SOAP Sur HTTP: Requête Encapsulation d'une requête SAML dans une requête SOAP Transmission de la requête SOAP dans le corps d'une requête HTTP (POST) Réponse Encapsulation de la réponse SAML dans une réponse SOAP Transmission de la réponse SOAP dans le corps de la réponse HTTP à la requête 136
SAML Reverse SOAP Binding (PAOS) Requête SAML encapsulée dans un message SOAP transmis dans une réponse HTTP Réponse SAML encapsulée dans un message SOAP transmis dans une requête HTTP Utilisé par ex. pour le ECP profile HTTP Redirect Binding Communication via le user-agent (browser) SAML Requester redirige le browser (HTTP 3xx) vers le SAML Responder Requête et réponse SAML encodée dans l'en-tête 'Location' de la réponse HTTP 137
SAML HTTP Post Binding Communication via le user-agent (browser) SAML Requester renvoie au browser un formulaire html contenant le message SAML et dont l action pointer vers le SAML Responder Formulaire soumis automatiquement HTTP Artifact Binding Communication via le user-agent (browser) Impossibilité d envoyer l entièreté du message SAML via l intermédiaire Envoi d un artefact Nécessite la résolution de l artefact via un échange supplémentaire synchrone (SOAP binding par ex.) 138
SAML Profile combine assertions, protocoles et bindings pour réaliser des use-cases SSO Fédération d identités Gestion d attributs Single Logout spécifie de manière plus restrictive leur utilisation dans un contexte particulier 139
SAML Différents types de 'profiles' Profile SSO Profile de fédération d identités Profile Résolution d'artifact Profile d'obtention d'assertion Profile de correspondance de noms Profil d'attributs 140
SAML Web Browser SSO Profile permet le single sign-on d'un client (browser) peut être initié par le SP ou l'idp basé sur le protocole Authentication Request 141
SAML Web Browser SSO Profile Identity Repository SP IdP Access Check ACS SSO Service ❶ ❻ ❺ ❸ ❷ ❹ ❶ Demande d accès ❷ Requête d authentification ❸ & ❹ Authentification ❺ Réponse d authentification ❻ Accès à la ressource Browser 142
SAML Web Browser SSO Profile Identity Repository Access Check SP ACS IdP SSO Service ❺ ❹ ❸ ❶ ❷ ❶ & ❷ Authentification ❸ Demande d accès ❹ Réponse d authentification ❺ Accès à la ressource Browser 143
SAML ECP Enhanced Client or Proxy SSO Use cases clients intelligents Connaissance de l IdP Client = IdP Clients limités Pas de redirect par ex. Serveurs proxy (passerelle WAP pour appareils mobiles) Cas particuliers où les bindings standards ne peuvent être utilisés Utilise le binding PAOS (SOAP à l envers) 144
SAML ECP SSO Profile Identity Repository Access Check SP ACS IdP SSO Service ❶ ❶ Demande d accès ❷ Requête d authentification (PAOS request) ❷ ❸ Requête d authentification ❹ Réponse d authentification ❺ Réponse d authentification (PAOS response) ❻ Accès à la ressource ❻ ❺ ECP Device ❸ ❹ 145
SAML Single Logout Profile Identity Repository Access Check SP ACS ❷ ❸ IdP SSO Service ❹ ❶ ❶ Demande de déconnexion globale ❷ LogoutRequest ❸ LogoutResponse ❹ Déconnecté! Browser 146
SAML Fédération d identités Etablissement d une correspondance entre des identités Identity auprès d un IdP et d un SP Repository SP IdP SP Utilisateur: jncolin Utilisateur: jnc Utilisateur: jn.colin Pseudo: xy96ahq Pseudo: hq5e4a Browser 147
SAML Fédération d identités Etablissement du pseudonyme Hors-ligne De manière persistente De manière temporaire Utilise le protocole de requête d authentification Dé-fédération d identités Interruption de la correspondance entre les identités Utilise le protocole de gestion des noms 148
SAML Fédération d identités xy96ahq Identity Repository Access Check SP ACS Utilisateur: jncolin Utilisateur: jnc IdP SSO Service ❷ ➑ ❶ ➐ ❻ ❺ ❹ ❸ ❶ Demande d accès ❷ Requête d authentification + demande de pseudo ❸ & ❹ Authentification comme jnc ❺ Réponse d authentification avec pseudo xy96ahq ❻ & ❼ Authentification comme jn.colin + fédération ❽ Accès à la ressource Browser 149
SAML Dé-fédération d identités xy96ahq Identity Repository Access Check SP ACS Utilisateur: jncolin ❶ ❷ Utilisateur: jnc IdP SSO Service Browser ❶ ManageNameIDRequest ❷ ManageNameIDResponse 150
SAML Meta-données Définissent les caractéristiques d'une entité SAML identification clés cryptographiques URL des points de service Basées sur le concept de rôles obtenues par Publication directe ( well-known location ) Accessible par requête http sur l identifiant du Provider Résolution DNS Tout autre moyen 151
SAML Meta-données 152
SAML Identity Provider 153
SAML Service Provider 154
SAML Conclusion SAML définit un cadre Use cases pré-définis Extensible Base d interopérabilité 155
156 Shibboleth
Shibboleth Système SSO ouvert et libre Pour applications Web Fonctionnalités avancées pour l échange d attributs Basé sur des standards ouverts (principalement SAML) Utilisé dans l enseignement supérieur http://shibboleth.internet2.edu/ Intégré dans de nombreux services Fournisseurs d information, LMS, blogs, Zope, Plone Cas d utilisation typique: L utilisateur visite le SP SP requiert l authentification en redirigeant l utilisateur vers l IdP IdP répond avec une réponse d authentification plus des attributs 157
Shibboleth Gestion des attributs Attribute resolver Collecte les attributs d une identité depuis les sources de données Attribute filter Limite les attributs transmis au SP Discovery Service basé sur SAML Structure de la Fédération définie dans des méta-données Service endpoints Profils supportés Paramètres cryptographiques IdP disponible en Java, SP disponible en C++ Supporte IIS, Apache 158
159 Liberty Alliance
Liberty Alliance Consortium fondé en 2001 Quelques membres: AMEX, Ericsson, France Telecom, GM, HP, Intel, Nokia, Novell, Sun... http://www.projectliberty.org/ The vision of Liberty Alliance is to enable a networked world based on open standards where consumers, citizens, businesses and governments can more easily conduct online transactions while protecting the privacy and security of identity information. 160
Liberty Alliance Cercle de confiance (CoT Circle of Trust) Work Profile Home Profile SP IdP IdP SP SP SP SP SP SP 161
Liberty Alliance Fédération d identités Établissement d une correspondance entre des identités gérées par des IdPs et SPs distincts au sein d un cercle de confiance (domaine de confiance) Scénario typique: L utilisateur s authentifie auprès de l IdP L IdP propose à l utilisateur de le présenter aux membres du CoT L utilisateur visite un SP du CoT Le SP propose à l utilisateur de fédérer son identité locale avec son identité sur le IdP Dé-fédération d identités Destruction de la correspondance entre identité 162
Liberty Alliance Un ensemble de spécifications Liberty Multi-Device SSO Deployment Guide 1.0 Draft Liberty Alliance Identity Assurance Framework (IAF) 1.1 Specification and Associated Read Me First 1.0 White Paper Liberty Alliance Identity Governance Framework (IGF) 1.0 Specifications ID-WSF Advanced Client 1.0 Specifications ID-FF 1.2, the Identity Federation Framework ID-WSF 1.1, the Identity Web Services Framework ID-WSF 2.0, the Identity Web Services Framework, including Errata v1.0 Updates ID-SIS 1.0, a collection of Identity Services Interface Specifications Liberty Basic SOAP Binding v1.0 Draft Liberty Liberty ID-WSF Advanced Client Implementation and Deployment guidelines for SIM/UICC Card environment 163
Liberty Alliance Définit 3 groupes de spécifications: Identity Federated Framework (ID-FF 1.2) Convergence avec SAML 2.0 avec extension Single Sign-On and Federation Name Registration Federation Termination Notification Single Logout Identity Provider Introduction Name Identifier Mapping Name Identifier Encryption 164
Liberty Alliance Identity Web-Services Framework (ID-WSF 2.0) Defines a framework for building interoperable identity services, permission-based attribute sharing, identity service creation, description, discovery and invocation Discovery Service Data Services Template Subscriptions and notifications Interaction Service Identity Service Interface Specification (ID-SIS 1.0) Further specifies Data Services Template Presence Service, Personal Profile Service, Contact Book Service, Directory Access Service, Geolocation Service, Employee Profile Service 165