comité réseau des universités [email protected] - authentification web, sso et fédération...

[email protected] - Authentification web, SSO et fédération d'identités 1

Co

mité R

éseau d

es Un

iversités

Authentification web,Single Sign-On

et fédération d’identités


Co

mité R

éseau d

es Un

iversités

Plan

• Contrôle d’accès et authentification web– Rappels– Fonctionnement– Mise eu oeuvre avec Apache– Limites de ces solutions

• Le Single Sign-On web– Principes– Architecture– Apports– L’exemple CAS

• La fédération d’identités– Principe– Solutions techniques– L’exemple Shibboleth


Co

mité R

éseau d

es Un

iversités

L'importance de la plateforme web

• Le web propose des outils standards• Le navigateur web est disponible sur tous

les postes utilisateurs

• Les applications classiques client/serveur deviennent des applications web

• Il faut pouvoir sécuriser l’accès à ces applications


Co

mité R

éseau d

es Un

iversités Contrôle d’accès et

authentification web


Co

mité R

éseau d

es Un

iversités

Qu’est-ce que le web ?

• Un protocole : HTTP• Un format de document : HTML• Un format d’adressage : les URL (http://xxx)

• Le client : navigateur web (Firefox, IE,…)• Le serveur : Apache, IIS, Tomcat,…

• Programmes côté client : Javascript• Interface côté serveur : CGI (Common Gateway

Interface )


Co

mité R

éseau d

es Un

iversités

Fonctionnement du serveur web

• Le serveur transmet des documents au navigateur web

• Le document peut être le résultat de l'exécution d'une application (CGI)

Documents(HTML ou

autre)

Serv

eu

r w

eb

requête HTTP

navigateur

Application

(CGI)


Co

mité R

éseau d

es Un

iversités

Comment gérer le contrôle d’accès

• Objectif – restreindre l’accès à une partie du serveur

pour une population identifiée

• Identification de l’utilisateur :1. Adresse IP du poste client (pas suffisant)

2. Authentification de l’utilisateur


Co

mité R

éseau d

es Un

iversités

Les méthodes d’authentification

• Authentification par mot de passe :– L’utilisateur saisie un identifiant et un mot de passe– Le serveur vérifie le mot de passe

• Authentification avec certificat :– L’utilisateur possède un certificat X509– Le serveur doit vérifier la validité du certificat

(autorité de certification +période de validité + liste de révocation + usage)


Co

mité R

éseau d

es Un

iversités

L’authentification HTTP

• L’authentification de l’utilisateur est prévue dans le protocole HTTP

• Solution peu utilisée :– Problème d’intégration des formulaires

de login dans les interfaces– Les navigateurs ne proposent pas de

fonction de logout

• Techniques de remplacement :– Formulaires HTML


Co

mité R

éseau d

es Un

iversités

Gestion des sessions

• Authentification native HTTP :– Le navigateur renvoie au serveur les éléments

d’authentification à chaque requête

• Utilisation de formulaires HTML :– Une session attachée à une adresse IP, côté serveur– Plus courant : le navigateur positionne des cookies

HTTP• Possibilité de gérer une table des sessions


Co

mité R

éseau d

es Un

iversités

Les cookies HTTP

• Permet au serveur de gérer les états entre 2 requêtes

• Un cookie est une variable, positionné par le serveur, stockée dans la client, puis renvoyée par le client lors des requêtes suivantes

• Contraintes sur les cookies :– Portée restreinte– Durée de vie limitée


Co

mité R

éseau d

es Un

iversités

Les cookies HTTP

• Réponse HTTP

Set-Cookie: variable=valeur; path=/

Content-type: text/html

….

• Requête suivante

Cookie: var1=val1; var2=val2

GET /prog.php HTTP/1.1


Co

mité R

éseau d

es Un

iversités

Apache et les modules d’authentification

• On peut étendre les fonctionnalités du serveur web Apache en ajoutant des modules

• Authentification gérée par des modules :– mod_auth : utilisation des fichiers htpasswd et

htgroup– mod_ssl : gestion SSL et authentification avec

certificats– mod_authldap : authentification LDAP– mod_authZldap : authentification avec certificats puis

autorisation basée sur LDAP– …beaucoup d’autres (http://modules.apache.org)


Co

mité R

éseau d

es Un

iversités

Configuration du serveur Apache

• Fichier htpasswd– Mots de passe cryptés– Syntaxe /etc/passwd

• Fichier htgroup– Composition groupes– Syntaxe /etc/group

salaun:2GxaEBB0vU/.Qdupont:pJnCOcjPuWsdblejean:zuL9.Cs1BvjU6….

admin: salaun dupontdev: salaun blejean durand…


Co

mité R

éseau d

es Un

iversités

Exemple 1Contrôle d’accès IP

Ressource

protégéeApach

e

Contr

ôle

d’a

ccès

<File /mon_document.html>Order deny,allowDeny from allAllow from .cru.fr</File>


Co

mité R

éseau d

es Un

iversités

Exemple 2htpasswd+htgroup

Ressource

protégéeApach

e

au

thenti

fica

tion

Contr

ôle

d’a

ccès

htpasswd htpgroup

ID + mot de passe

<File /mon_document.html>AuthType BasicAuthUserFile /etc/httpd/conf/htpasswdAuthGroupFile /etc/httpd/conf/htgroup Require user dupontRequire group gestion</File>


Co

mité R

éseau d

es Un

iversités

Exemple 3certificats + base LDAP

Ressource

protégéeApach

e

au

thenti

fica

tion

Contr

ôle

d’a

ccès

Autoritésde

certificationsLDAP

Certificat X509

<File /mon_document.html>SSLEngine onSSLRequireSSL…SSLCACertificatePath /etc/httpd/ssl.crt

AuthzLDAPEngine onAuthzLDAPServer “ldap.cru.fr”…Require filter (gestionMember=Yes)</File>


Co

mité R

éseau d

es Un

iversités

Authentification VS autorisation

• Deux processus disjoints

• Authentification– « prouver son identité »

• Autorisation (ou contrôle d’accès)– « déterminer les droits d’accès »


Co

mité R

éseau d

es Un

iversités

Les mauvais usages…

• Les pages cachées => 1 lien suffit pour que la page soit indexée

par google !

• Le compte partagé par un groupe d’utilisateurs : (on fait l’économie de la gestion de compte)=> à chaque modification du groupe on devrait

changer le mot de passe…


Co

mité R

éseau d

es Un

iversités

Les limites / multiplication des référentiels

• Autant de fichiers htaccess et htgroup que de serveurs

• Pas de relation avec les comptes système– risques d’inconsistance (anciens comptes non

désactivés)

• Utilisation de LDAP ou d’un autre référenciel (NIS) résout ce problème


Co

mité R

éseau d

es Un

iversités

Les limites / sécurisation des échanges

• Le mot de passe utilisateur circule :1. Entre le navigateur et le serveur web

2. Entre le module d’authentification et la base d’authentification (si la base est distante)

(1) et (2) sécurisable par SSL


Co

mité R

éseau d

es Un

iversités

Les limites / ergonomie utilisateur

• Multiplication des comptes donc des mots de passe– pb de mémorisation des mots de passe– contournement des consignes de sécurité

(penses bêtes)– utilisation systématique du même mot de

passe (sur voila.fr et pour les applications sensibles)

• L’utilisateur peut être amené à s’authentifier très souvent


Co

mité R

éseau d

es Un

iversités

Single Sign-On

Authentification unique


Co

mité R

éseau d

es Un

iversités

Single Sign-On…définition

• Authentifier 1 seule fois un utilisateur pour accéder à un ensemble d’applications

• Session d’authentification partagée par plusieurs applications web (sur plusieurs serveurs)


Co

mité R

éseau d

es Un

iversités

Architecture simplifiée

Application

Utilisateur

Usagers / Groupes

Application

Usagers / Groupes

Serv

eu

rS

SO

Sessiond’Authentification

PKI

NIS

LDAP


Co

mité R

éseau d

es Un

iversités

Architecture d’un SSOles briques

• Le serveur d’authentification– Élément central

• Les agents d’authentification– Devant chaque ressource à protéger


Co

mité R

éseau d

es Un

iversités

Le serveur d’authentification

• Élément central du SSO :– Authentification utilisateur– Persistance connexion– Propagation identité vers applications

• Repose sur un ou des référentiels d’authentification (NIS,LDAP,…)


Co

mité R

éseau d

es Un

iversités

L’agent d’authentification

• Interface entre serveur authentification et application :– Redirection de l’utilisateur vers le serveur

d’authentification– Transmission de l’identité de l’utilisateur à

l’application

• Implémenté sous plusieurs formes– Librairies clientes– Module intégré au serveur web


Co

mité R

éseau d

es Un

iversités

Scénario d’authentification

Serveur Authentification

AgentAuthentification

Application

Utilisateur

Accès initial


Co

mité R

éseau d

es Un

iversités

Scénario d’authentification

Serveur Authentification

Utilisateur

Accès suivants

AgentAuthentification

Application


Co

mité R

éseau d

es Un

iversités

Les flux

NavigateurAgent Auth

Serveur Auth Base Auth

Requête application

Demande authentification

Formulaire login

Vérif. Mot de passe

Appli.

Jeton authentification

Réponse appli.

1

2

3

4

5

6


Co

mité R

éseau d

es Un

iversités

Single Sign-On Les techniques utilisées

• Communication via l’utilisateur utilisant :– Requêtes HTTP (GET) ou formulaires (POST)– Redirections HTTP– Javascript

• Persistence des sessions : – Cookies HTTP

• Protection des échanges :– SSL– Portée et durée de validité des cookies– Jetons non rejouables


Co

mité R

éseau d

es Un

iversités

Gestion des sessions à deux niveaux

• Avec le serveur d’authentification– évite de se ré-authentifier à chaque

application

• Avec l’agent d’authentification– évite de renvoyer l’utilisateur vers le serveur

d’authentification à chaque requête


Co

mité R

éseau d

es Un

iversités

Apports du SSOErgonomie

• 1 seul mot de passe

• saisi 1 seule fois

• à 1 seul endroit

=> l’utilisateur est sensibilisé et ne doit fournir son mot de passe que sur la page de Login.


Co

mité R

éseau d

es Un

iversités

Exemple de page de Login


Co

mité R

éseau d

es Un

iversités

Apports du SSOSécurité

• Limite l’accès et la circulation des mots de passe (uniquement entre le navigateur et serveur d’authentification)

• Politique de gestion des mots de passe possible (Changement, complexité minimum, accounting)

• Extension des méthodes d’authentification envisageable


Co

mité R

éseau d

es Un

iversités

Apports du SSOpour les applications

• Utilisation des même librairies d’authentification dans toutes les applications :– Meilleur intégration des applications dans

l'environnement informatique– Rapidité de développement– Même niveau de sécurité partout


Co

mité R

éseau d

es Un

iversités

Solutions de Single Sign-Onl’embarras du choix…

• Pas de standardisation des techniques de SSO pour le web

• Besoins pressants dès lors que les applications web se multiplient

• Multiplication des solutions :– Libres ou propriétaires– Utilisant une terminologie propre– Solutions techniques très variables (plus ou

moins sûres)


Co

mité R

éseau d

es Un

iversités

CAS, un exemple de SSO

• CAS (Central Authentication Service)– SSO web développé par l’université de Yale(USA)

• Très utilisé par les universités françaises

• Une architecure simple et robuste– Code léger– L’identité de l’utilisateur est transmise via un ticket (à

la Kerberos)– Permet un fonctionnement en mode proxy

• Cas d’exemple : webmail, portail web.


Co

mité R

éseau d

es Un

iversités

L’architecture CAS


Co

mité R

éseau d

es Un

iversités

CAS / fonctionnement multi-tiers


Co

mité R

éseau d

es Un

iversités

Demo CAS

• ENT

• Serveur de listes


Co

mité R

éseau d

es Un

iversités

Single Sign-OnLes limites

• Technique des redirections HTTP pose problème si le service est indisponible=> utilisateur bloqué

• Les applications "multi-tiers" (web services)• Les applications propriétaires (« legacy »)• Gestion d’attributs pour le contrôle d’accès• Les utilisateurs doivent toujours avoir d’autres

comptes pour les applications extérieures


Co

mité R

éseau d

es Un

iversités

Le Single Logout…

• Si l’utilisateur s’est « logué » globalement, il doit pouvoir se « délogué » globalement

• Plus difficile que le SSO car chaque application gère sa propre session avec l’utilisateur.

• Il faut donc gérer une base centrale des applications qui ont une session d’authentification avec l’utilisateur et mémoriser une URL de déconnexion.

• Le single logout est complexe donc peu implémenté…


Co

mité R

éseau d

es Un

iversités

La fédérationd’identités


Co

mité R

éseau d

es Un

iversités

Constat…

Les limites d’un service d’authentification / autorisation apparaissent lorsqu’on veut ouvrir les accès à des personnes extérieures…

Comment reconnaître localement l’identité et/ou les privilèges d’un utilisateur enregistré ailleurs ?


Co

mité R

éseau d

es Un

iversités

Des cas d’utilisation

• Contrôle d’accès en fonction du profil de l’utilisateur– Exemple : étudiant en pharmacie

• Intranet pour un groupe de travail– Chercheur, étudiants, association,

informaticiens

• Accès aux périodiques électroniques depuis un ENT– Science Direct, JSTOR, …


Co

mité R

éseau d

es Un

iversités

Les solutions techniquesde fédération d’identités


Co

mité R

éseau d

es Un

iversités

SAML

SAML

• SAML=Security Assertion Markup Language

• Standard OASIS en 2002

• Répond à un besoin d’interopérabilité

• Echanges d’assertions de sécurité entre services

• Indépendant des mécanismes d’authentification


Co

mité R

éseau d

es Un

iversités

Types d’assertions SAML

• Authentification

• Échange d’attributs

• Décisions d’autorisation

SAML


Co

mité R

éseau d

es Un

iversités

Exemple d’assertion SAML

SAML

<saml:Assertion MajorVersion=”1” MinorVersion=”0”AssertionID=”128.9.167.32.12345678”Issuer=”Comite Reseau des Universites”IssueInstant=”2002-03-21T10:02:00Z”>

<saml:Conditions NotBefore=”2002-03-21T10:02:00Z” NotAfter=”2002-03-21T10:07:00Z” />

<saml:AuthenticationStatement AuthenticationMethod=”password”AuthenticationInstant=”2002-03-21T10:02:00Z”>

<saml:Subject> <saml:NameIdentifier SecurityDomain=”www.cru.fr”

Name=”osalaun” /> </saml:Subject></saml:AuthenticationStatement>


Co

mité R

éseau d

es Un

iversités

Liberty Alliance

SAMLLiberty Alliance

• Liberty Alliance n’est pas un produit

• Consortium d’industriels produisant des spécifications sur la gestion d’identités

• S’appuie sur SAML• Implémenté dans de nombreux produits

SourceID Sun LASSO


Co

mité R

éseau d

es Un

iversités

Shibboleth

SAMLShibboleth Liberty Alliance

Shibboleth SourceID Sun LASSO

• Norme et produit développé par Internet2• Open source• Première version en 2002• Basé sur SAML (bibliothèque OpenSAML)• Utilisé surtout par des universités

– en Allemagne, Danemark, Finlande, France, Grande-Bretagne, Suède, Suisse, USA, Australie, Chine


Co

mité R

éseau d

es Un

iversités

Shibboleth



• Conçu pour interconnecter les SSO des universités• Fonctionnalités

– Délégation d’authentification– WAYF pour orienter l’utilisateur– Propagation des attributs utilisateur– Partage de méta données– Définition de règles de confiance


Co

mité R

éseau d

es Un

iversités

WS-Federation



Oblix

WS-*

WS-Federation

ADFS

• Draft porté par Microsoft et IBM, 2003• Basée sur les spécifications WS-*

– WS-Security, WS-Trust, WS-Policy, WS-MetadataExchange

• Définit l’échange d’identités et d’attributs entre domaines de sécurité


Co

mité R

éseau d

es Un

iversités

Autres initiatives

• CardSpace (Microsoft)

• OpenID

• OAuth

• Bandit (IBM et Novell)


Co

mité R

éseau d

es Un

iversités

Card Space (Microsoft)

• Principe : sélecteur d’identités

• Projet anciennement nommé « infoCard »

• Intégré dans IE 7– Point fort car aucune autre technologie n’est

intégrée dans les client web

[email protected] - Authentification web, SSO et fédération d'identités

Co

mité R

éseau d

es Un

iversités

OpenIDhttp://openid.net/

• Protocole de délégation d'authentification• Origine : authentification sur les blogs• Principe :

1. Saisie de l’URI de son OpenID provider2. Redirection vers l’OpenID provider3. Authentification

– Développement rapide de la technologie– Nombreux services compatibles– Nombreuses implémentations


Co

mité R

éseau d

es Un

iversités

Oauthhttp://oauth.net

• Standard récent (version 1.0, décembre 2007)

• Définit un standard permettant la délégation d'un utilisateur pour l'accès à un service

• Exemple d'utilisation – Un utilisateur autorise un service d'impression

à accéder à ses photos sur un site de gestion de photos

• Oauth est complémentaire de OpenID


Co

mité R

éseau d

es Un

iversités

Bandithttp://www.bandit-project.org

• Initiative IBM + Novell

• Palette d’outils « open source »

• Bandit = Higgins + CASA + ARF + Role engine

• Higgins : aggrégateur d’identités – Liberty Alliance, Cardspace, LDAP

• CASA : porte-clefs


Co

mité R

éseau d

es Un

iversités

Shibboleth


Co

mité R

éseau d

es Un

iversités • Logiciel « open source »• Issu du monde universitaire

– USA, Internet 2

• Basé sur la norme SAML• Utilisé surtout dans le monde universitaire

– France, Suisse, USA, Angleterre, Finlande, Australie, Suède, Belgique, Allemagne, Danemark, Slovénie, République Tchèque

http://shibboleth.internet2.edu


Co

mité R

éseau d

es Un

iversités

Fonctionnement de Shibboleth

Cours en ligne dans une autre université

Université de rattachement

de l’étudiant

1

3

2

4

• Tentative d’accès à la ressource

• Redirection vers le SSO de l’université de rattachement

• Authentification sur le SSO

• Redirection vers la ressource avec une preuve d’authentification

SSO


Co

mité R

éseau d

es Un

iversités

Fonctionnement de Shibboleth

Cours en ligne dans un autre université


de l’étudiant

1

3

2

4

5. Demande d’attribut sur l’utilisateur

6. Extraction des attributs

7. Propagation vers la ressource

5 7

6

Référentiels


Co

mité R

éseau d

es Un

iversités

Briques techniques de Shibboleth

Cours en ligne dans un autre université


de l’étudiant1. Le fournisseur d’identités

2. Le fournisseur de services

3. Le service de découverte

4. Échanges au format SAML

Référentiels

SSO

IdP1

WAYF3SP2


Co

mité R

éseau d

es Un

iversités

ShibbolethDemo

• Sourcesup


Co

mité R

éseau d

es Un

iversités

Le Service de découverteou Where Are You From (WAYF)

• La partie visible de l’iceberg– La seul brique de Shibboleth avec laquelle

l’usager interagit directement

• Objectif – Orienter l’utilisateur vers son fournisseur

d’identités

• Localisation– Au plus près du fournisseur de services


Co

mité R

éseau d

es Un

iversités

Fonctionement du WAYF

WAYF

IdP 1

IdP 2

IdP 3

SP


Co

mité R

éseau d

es Un

iversités

L’établissement choisit les attributs qu’il propage, selon la ressource

Intranet d’un groupe de travail

Établissement de rattachement

Cours en ligne dans un autre établissement

Périodiques électroniques(prestataire privé)

NomPrénomEmail

EtapeDiscipline

Statut(étudiant,Personnel)


Co

mité R

éseau d

es Un

iversités

• Cercle de confiance– Regroupe un ensemble de SP et d’IdP

• La confiance repose sur :– Méta données + certificats X.509– Nommage d’attributs utilisateurs + nomenclature– Qualité de la gestion des utilisateurs– Bonne utilisation des données transmises

Les relations de confiance

IdP

SP


Co

mité R

éseau d

es Un

iversités

Apports de la fédération d’identités

• Pour l’utilisateur– Il n’utilise que le mot de passe de son SSO– Adapté aux utilisateurs nomades

• Pour l’établissement de rattachement– Niveau de sécurité constant (SSO)– Meilleure maîtrise des données personnelles

• Pour les gestionnaires de ressources– Plus besoin de gérer des comptes utilisateurs– Accès à des données utilisateurs fiables


Co

mité R

éseau d

es Un

iversités

Quelques liens

Site du CRU : http://www.cru.fr/CAS : http://www.yale.edu/tp/auth/

SAML : http://www.oasis-open.org/committees/workgroup.php?wg_abbrev=security

Liberty Alliance : http://www.projectliberty.org/Shibboleth : http://shibboleth.internet2.edu/

Fédération du CRU : http://federation.cru.fr