Authentification unique

Authentification unique SSO : du poste de travail au Web Vincent HURTEVENT Octobre 2012

Sommaire 1 Rappels Cryptographie 2 X.509 3 SSL & TLS 4 SSO Définitions Pour qui? Prérequis Du poste de travail au Web 5 Kerberos Fonctionnement Usages Exemples à l Université Critiques & limites

Sommaire 6 SSO Web Objectifs 7 Central Authentication Server Historique Fonctionnement Clients CAS-conclusions 8 Et des informations? Approches Vocabulaire 9 SAML - Shibboleth Métadonnées Fonctionnement 10 OpenID 11 SSO de bout en bout

Rappels Cryptographie Cryptographie Fonction de Hashage Calcul d une empreinte Chiffrement sans clef (mot de passe) Compresser pour signature Unicité Intégrité Ex : MD4, MD5, SHA-1, SHA-2, SHA-3

Rappels Cryptographie Cryptographie Cryptographie symétrique Chiffrement à clef partagée Nécessite un canal sécurisé Ex : DES, AES

Rappels Cryptographie Cryptographie Cryptographie asymétrique Plus de clef partagée Clef privée / Clef Publique Ne nécessite pas de canal sécurisé Ex : RSA, Rabin

X.509 X.509 Norme de cryptographie La structure d un certificat électronique Algorithme de validation d un chemin de certification

X.509 X.509 Structure d un certificat Carte d identité numérique signée Informations d identification Dates de validité Clef publique Signature

X.509 X.509 Structure d un certificat Version Numéro de série Algorithme de signature du certificat DN (Distinguished Name) du délivreur (autorité de certification) Validité (dates limite) Pas avant Pas après DN du détenteur du certificat

X.509 X.509 Structure d un certificat Informations sur la clé publique : Algorithme de la clé publique Clé publique proprement dite Identifiant unique du signataire (optionnel, X.509v2) Identifiant unique du détenteur du certificat (optionnel, X.509v2) Extensions (optionnel, à partir de X.509v3) Liste des extensions Signature des informations ci-dessus par l autorité de certification

X.509 Exemple Certificat de clef publique pour le domaine cas.univ-lyon1.fr Certificate: Data: Version: 3 (0x2) Serial Number: 01:3c:26:a7:81:73:2f:d4:b5:7e:01:c5:8f:86:45:82 Signature Algorithm: sha1withrsaencryption Issuer: C=NL, O=TERENA, CN=TERENA SSL CA Validity Not Before: May 25 00:00:00 2012 GMT Not After : May 25 23:59:59 2015 GMT Subject: C=FR, O=Universite Lyon 1 Claude Bernard, CN=cas.univ-lyon1.fr Subject Public Key Info: Public Key Algorithm: rsaencryption Public-Key: (2048 bit) Modulus: 00:bc:23:49:15:ec:d2:8c:47:22:8a:6a:70:7e:10:

X.509 Exemple Certificat de clef publique pour le domaine cas.univ-lyon1.fr Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:0c:bd:93:68:0c:f3:de:ab:a3:49:6b:2b:37:57:47:ea:90:e3:b9:ed X509v3 Subject Key Identifier: 4C:93:2A:E3:2D:BF:5A:4C:73:4D:32:C1:AE:66:52:30:36:CE:83:71 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.6449.1.2.2.29 X509v3 CRL Distribution Points: Full Name: URI:http://crl.tcs.terena.org/TERENASSLCA.crl Authority Information Access: CA Issuers - URI:http://crt.tcs.terena.org/TERENASSLCA.crt OCSP - URI:http://ocsp.tcs.terena.org X509v3 Subject Alternative Name: DNS:cas.univ-lyon1.fr, DNS:dsi-auth-cas-01.univ-lyon1.fr, DNS:dsi-auth-cas-02.univ-lyon1.fr Signature Algorithm: sha1withrsaencryption 73:60:31:4b:c3:c0:ff:32:90:59:a2:9c:57:7a:9a:15:d3:e8:

X.509 Validation du chemin de certification Autorité de certification (AC) L AC signe le certificat - vérification de la signature Plusieurs autorité peuvent être chaînées On devra alors présenter les certificats de chacune des autorités Comment l AC s assure de la légitimité du demandeur DV : Domain Validation EV : Extended Validation

X.509 Validation du chemin de certification Révocation d un certificat Un utilisateur peut demander la révocation d un certificat Une AC peut révoquer, pour des raisons de sécurité, des certificats précédemment émis Mécanismes Certificate Revocation List - CRL Online Certificate Status Protocol - OCSP OCSP Stapling Prise en charge Les éditeurs ne font pas tous confiance aux mêmes autorités, et n implémente pas forcément tous les mécanismes. Incidents récents 2011 : Comodo, Diginotar

SSL & TLS SSL & TLS Protocole pour la sécurisation des échanges applicatifs Objectifs Authentification du serveur Chiffrement de la communication Intégrité des messages Versions SSLv1 > SSLv2 > SSLv3 > TLS 1.0 > TLS 1.1

SSL & TLS SSL & TLS Avantages Spontané Non intrusif et transparent vis a vis de la couche application

SSL & TLS SSL & TLS

SSL & TLS Sommaire 6 SSO Web Objectifs 7 Central Authentication Server Historique Fonctionnement Clients CAS-conclusions 8 Et des informations? Approches Vocabulaire 9 SAML - Shibboleth Métadonnées Fonctionnement 10 OpenID 11 SSO de bout en bout

SSO Définitions Identification Connaître l identité d une entité Une personne : login, certificat, URL, etc Un service : URL Identifiant Dans une stratégie SSO, faire le choix de l identifiant, pourquoi?

SSO Définitions Authentification Vérifier l identité d une entité Facteurs d identification Utiliser une information que seul l utilisateur connaît Utiliser une information unique que seul l utilisateur possède Utiliser une information qui caractérise l utilisateur dans un contexte donné Utiliser une information que seul l utilisateur peut produire

SSO Définitions Autorisation Vérification des droits d une ressource authentifiée Les droits peuvent être fonction De l authentification D informations associées à la ressources Séparer authentification et autorisation

SSO Définitions A l origine

SSO Définitions Informations centralisées

SSO Pour qui? Pour qui? L utilisateur L organisation Le concepteur, développeur

SSO Pour qui? Utilisateur Objectifs 1 seul compte/identité, facilité de mémorisation 1 seule saisie ou acte d authentification (idéalement SSO de bout en bout)

SSO Pour qui? Organisation Objectifs Simplifier la gestion des profils utilisateurs Mise en oeuvre d une politique de sécurité Politique de mot de passe Maîtrise de la circulation de mot de passe Gestion des droits et des accès Contrôle et communication

SSO Pour qui? Développeur Objectifs S abstraire de la gestion des comptes Utilisation de spécifications et protocoles reconnus Avantages Gain de temps, sécurité

SSO Prérequis Prérequis Organisation Gestion d identités Base centralisée des utilisateurs (BDD, annuaire LDAP) Un cadre : DNS, certificats

SSO Du poste de travail au Web Du poste de travail au web Protocoles Kerberos Central Authentication Server - CAS SAML - Shibboleth OpenID Lequel choisir? Chaque protocole adapté à un besoin Possibilité de tous les utiliser, de les chaîner

Kerberos Présentation Kerberos est un protocole d authentification réseau Il est spécialement concu pour apporter une solution sûre à l authentification client/serveur. Pour cela il utilise un mécanisme de crytographie à clef secrète. Il saura identifier une entité et l authentifier. Le mot de passe n est jamais transmis TCP ou UDP, port 88

Kerberos Présentation Historique 1983 Projet Athena : nécessité d authentifier les utilisateurs - Kerberos v1 -> v3 interne au MIT fin 80s Kerberos v4, publique 1993 Kerberos v5 - RFC1510, RFC4120 (2005) 1999 Windows 2000 utilise Kerberos v5 + nouvelles fonctionnalités (RFC3244, RFC4757)

Kerberos Présentation Implémentations MIT (Institution américaine) Microsoft Sun (Oracle) Heimdal (Institution suédoise)

Kerberos Fonctionnement Authentification (1 fois par session)

Kerberos Fonctionnement Authentification (1 fois par session) Le client demande authentification

Kerberos Fonctionnement Authentification (1 fois par session) Le client demande authentification Le SA fourni un ticket TGT Récupération d un ticket de service (1 fois pour chaque service)

Kerberos Fonctionnement Authentification (1 fois par session) Le client demande authentification Le SA fourni un ticket TGT Le client envoie demande d accès avec ticket TGS et preuve d identité

Kerberos Fonctionnement Authentification (1 fois par session) Le client demande authentification Le SA fourni un ticket TGT Le client envoie demande d accès avec ticket TGS et preuve d identité Le TGS fourni un ticket serveur utilisation unique

Kerberos Fonctionnement Authentification (1 fois par session) Le client demande authentification Le SA fourni un ticket TGT Le client envoie demande d accès avec ticket TGS et preuve d identité Le TGS fourni un ticket serveur utilisation unique Accès au service (1 fois pour chaque service) : Le client envoie le ticket serveur et une preuve d identité

Kerberos Fonctionnement Authentification (1 fois par session) Le client demande authentification Le SA fourni un ticket TGT Le client envoie demande d accès avec ticket TGS et preuve d identité Le TGS fourni un ticket serveur utilisation unique Accès au service (1 fois pour chaque service) : Le client envoie le ticket serveur et une preuve d identité Le serveur accorde l accès

Kerberos Usages Usages Ouverture de session (Windows, Linux, SSH, etc) Partage de fichier (CIFS, NFS) Web (IIS, Apache) Interfaces - API Mécanismes GSSAPI, SPNEGO

Kerberos Exemples à l Université Exemples à l Université

Kerberos Critiques & limites Critiques & limites SPOF disponibilité : l AS et KDC doivent être hautement disponibles SPOF sécurité : le KDC stocke toutes les clefs, risque d usurpation d identité si compromis Pas de standard dans son administration Ne peut être élargi à des services non-gérés et où la confiance n est pas assurée

SSO Web Objectifs Objectifs Un SSO adapté aux usages du Web : Fonctionne sur HTTP Elargir le périmètre d utilisation Allez plus loin que l authentification et transmettre des informations d identité

Central Authentication Server Historique Présentation CAS : centralisation de l authentification Permet à différents sites web ou services en ligne de déléguer l authentification à un service unique Assurer un SSO pour les services Web Historique Initié par Yale University Intègre le JASIG en 2004 avec CASv2 Aujourd hui en v3.5 Très largement utilisé dans les universités

Central Authentication Server Fonctionnement Fonctionnement

Central Authentication Server Fonctionnement Fonctionnement

Central Authentication Server Fonctionnement Captures POST / HTTP/1.1 Host: ocsp.tcs.terena.org Content-Type: application/ocsp-request HTTP/1.1 200 OK X-OCSP-Reponder-ID: h6edcaocsp6 Content-Type: application/ocsp-response POST / HTTP/1.1 Host: ocsp.usertrust.com Content-Type: application/ocsp-request HTTP/1.1 200 OK X-OCSP-Reponder-ID: h6edcaocsp3 Content-Type: application/ocsp-response GET /cas/login?service=http%3a%2f%2fetu.univ-lyon1.fr%2fservlet%2fcom.jsbsoft.jtf.core.sg%3fproc%3didentificat Host: cas.univ-lyon1.fr Referer: http://etu.univ-lyon1.fr/ HTTP/1.1 200 OK Content-Type: text/html;charset=iso-8859-1 https://cas.univ-lyon1.fr/cas/login?service=http%3a%2f%2fetu.univ-lyon1.fr%2fservlet%2fcom.jsbsoft.jtf.core.sg

Central Authentication Server Fonctionnement Captures POST /cas/login?service=http%3a%2f%2fetu.univ-lyon1.fr%2fservlet%2fcom.jsbsoft.jtf.core.sg%3fproc%3didentifica Host: cas.univ-lyon1.fr username=vincent.hurtevent&password=xxxxxxxxx&lt=lt-124026-9d0ohmzarvbw8puzjsvx HTTP/1.1 200 OK Set-Cookie: CASTGC=TGC-XXXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXX; Path=/cas; Secure Content-Length: 4036 GET /servlet/com.jsbsoft.jtf.core.sg?proc=identification_front&ticket=st-xxxxxxxxxxxxxxxxxx HTTP/1.1 Host: etu.univ-lyon1.fr HTTP/1.1 302 Moved Temporarily Location: http://etu.univ-lyon1.fr/ GET / HTTP/1.1 Host: etu.univ-lyon1.fr

Central Authentication Server Clients Clients Applications CMS Drupal, Joomla, Typo3, Wordpress Portail uportal, Liferay, Sharepoint Groupeware Confluences, Zimbra Bibliothèques ou modules PHP phpcas Java CAS client for Java.Net dotnet CAS Client Apache mod_auth_cas

Central Authentication Server Clients Exemple d implémentation en PHP phpcas Initialiser le client phpcas : :client Authentifier l utilisateur : phpcas : :forceauthentication phpcas : :checkauthentication Déconnexion phpcas : :logout() ;

Central Authentication Server Clients Exemple d implémentation en PHP Implémentation phpcas includeonce ( CAS. php ) ; phpcas : : c l i e n t (CAS_VERSION_2_0, cas. univ lyon1. f r,443, / cas / ) ; phpcas : : setnocasservervalidation ( ) ; i f ( isset ( $ \_GET[ logout ] ) ) { phpcas : : logout ( ) ; } i f ( isset ( $ \_GET[ l o g i n ] ) ) { phpcas : : f o r c e A u t e n t i c a t i o n ( ) ; } $auth=phpcas : : checkauthentication ( ) ; i f ( $auth ) { echo " L u t i l i s a t e u r est ". phpcas : : getuser ( ). " </ br > " ; echo " <a h r e f =? logout > se d&eacute ; connecter </ a> </ br > " ; } else { echo " L u t i l i s a t e u r n est pas a u t h e n t i f i &eacute ; < / br > " ; echo " <a h r e f =? l o g i n > se connecter </a> </ br > " ; }

Central Authentication Server CAS-conclusions Conclusions Avantages SSO Web fonctionnel Facile de mise en oeuvre Multiples librairies clientes Pas de cercle de confiance à maintenir Limites Ne permet que l authentification

Et des informations? Et des informations? Objectifs Des applications peuvent avoir besoin d obtenir des informations concernant l utilisateur pour déterminer les autorisations et personnaliser le service Nom Prénom Adresse mail Statut... Sans donner un accès direct au référentiel

Et des informations? Approches Confiance L approche fédérative Des institutions se coordonnent pour établir un cercle de confiance au sein duquel des informations utilisateurs pourront être transmises Ex : SAML, Liberty Alliance : réunit des fournisseurs d identité et des fournisseurs de services identifiés et maintient le cercle de confiance Centrée sur l utilisateur Ou "user-centric", il n y a pas de cercle de confiance définit, c est à l utilisateur de déterminer s il autorise un service donné à accéder à ses données personnelles auprès de son fournisseur d identité. Ex : OpenID

Et des informations? Vocabulaire Vocabulaire Vocabulaire Fournisseur d identité ou Identity Provider (IDP), entité spécialisée dans la fourniture d information relative à l utilisateur Fournisseur de Service ou Service Provider (SP), entité spécialisée dans la fourniture de service aux utilisateurs (Site web, Application en ligne, etc) Assertion ou Token, message structuré, signé, éventuellement chiffré, échangé entre IDP et SP

SAML - Shibboleth SAML - Shibboleth SAML est standard d échange d authentification et de données utilisateurs SAML 1.0 : norme par OASIS en 2002 SAML 1.1 : mise à jour en 2003 SAML 2.0 : standard 2005, construit sur SAML 1.1, ID-FF (Liberty Alliance), Shibboleth) SAML définit la manière dont les différentes parties, l IDP et le SP vont mener leurs échanges et comment les messages doivent être construits. Shibboleth est une des implémentation SAML Parmis d autres : simplesamlphp, ADFS, OpenAM,...

SAML - Shibboleth Métadonnées Metadonnées Métadonnées Toute partie possède ses propres métadonnées = Fiche d identité de la partie Les métadonnées définissent : Un nom : EntityID Des points d accès (URL de service) Un certificat de clé publique pour signer et/ou chiffrer les assertion SAML

SAML - Shibboleth Métadonnées Confiance : échange de métadonnées Confiance pair à pair

SAML - Shibboleth Métadonnées Confiance : échange de métadonnées Fédération

SAML - Shibboleth Fonctionnement Fonctionnement en mode Attribute Push Principe

SAML - Shibboleth Fonctionnement Fonctionnement UCBL

SAML - Shibboleth Fonctionnement Fonctionnement UCBL

OpenID OpenID User-centric Il n est plus question de fédération, il n y pas d échange de métadonnées. L utilisateur lors de l authentification décide d autoriser un SP à obtenir des informations personnelles auprès de l IDP. Quelques dates 2005 Brad Fitzpatrick (LiveJournal - SixApart) 2007 Symantec, Microsoft - Compatibilité CardSpace 2007 OpenID Foundation (Google, IBM, Microsoft, Verisign, etc) 2008 IDP publics (Yahoo!, Soureforge, Google, etc)

OpenID Fonctionnement

SSO de bout en bout SSO de bout en bout Permettre de SSO de l ouverture de session sur le poste de travail jusqu au service Web, qu il soit local, institutionnel, extérieur ou public.