Authentification et contrôle d'accès dans les applications web

(1)

Authentification et contrôle d'accès

dans les applications web

(2)

Quelques Rappels

●

Objectifs : contrôler que seulement

– Certains utilisateurs

– Exécutent certaines opérations

– Sur certains objets

●

Trois entités :

– Sujet : l'entité demandant un accès à une ressource – utilisateur, process, thread

– Opération : l'action demandée – lire écrire,

modifier, créer un compte, créer un produit ...

– Objet : la ressource – fichier, ligne de table ...

(3)

●

Identification :

– Qui est le sujet ?

●

Identifiant, @mail, url

●

Authentification :

– Le sujet est-il réellement celui qu'il prétend être ?

●

Mot de passe secret, carte à puce, caractéristique bio-métrique

●

Contrôle d'accès

– Le sujet est-il autorisé à exécuter une action

sur un objet ?

(4)

Principe

●

Identification/Authentification :

– Transmission des crédits (credentials)

– Vérification auprès d'un référentiel d'utilisateurs

– Chargement d'un profil de l'utilisateur dans une variable de session

●

Contrôle d'accès :

– Comparaison entre un droit demandé et le contenu du profil en session

– Au minimum : dans tous les programmes accessibles via une url,

– Dans toutes les méthodes accédant aux

données

(5)

●

Contenu du profil :

– Identité (ID, nom, groupe, mail ...)

– Droits d'accès :

●

Niveau d'accès (hiérarchie de droits)

●

Liste de droits (à base de clés)

(6)

Les modèles

●

Mandatory Access Control (MAC)

– Sécurité assurée entièrement par le système, sans possibilité de modification par les usagers

– Politique définie par un administrateur

– Exemple : SGBD

●

Discretionary Access Control (DAC)

– Les sujets peuvent modifier ou transmettre les droits d'accès aux objets

– La politique est définie (en partie) par les usagers

– Exemple : unix, acl, capabilities

(7)

●

Role-Based Access Control

– Permissions assignées à des rôles

– Les usagers sont affectés à un ou plusieurs

rôles

(8)

Identification/Authentification

navigateur web appli web

référentiel utilisateurs

(sql)

Https : (uid,pwd)

uid ?

uid+crypt(pwd) ? profil(uid) ?

attributs

●

Un référentiel par application

●

Stockage et comparaison des pwd cryptés (md5, sha-1)

●

Échange sécurisé entre client et serveur

●

Situation actuelle sur le web

(9)

●

Problème : lorsque plusieurs applications partagent les mêmes utilisateurs

– Courant sur l'intranet d'1 organisation

– ajouter/modifier/supprimer un utilisateur : à faire pour chaque appli

– Utiliser 1 référentiel commun

appli 2

(uid,pwd)

navigateur web

appli 1 appli 3

(ldap) Service

(uid,pwd)

(uid,pwd) (uid,pwd)

(uid,pwd)

(10)

appli 2 ^(uid,pwd) ^(uid,pwd)

(uid,pwd) (uid,pwd)

problèmes

●

Authentification auprès de chaque application

●

Mot de passe transmis à chaque application

navigateur web

appli 1 appli 3

(ldap) Service

(uid,pwd)

(11)

serveur

authentification

Single Sign-On

●

Une seule authentification pour un groupe d'applications

appli 2 ^(uid,pwd)

navigateur web

appli 1 appli 3

(ldap) Service

(uid,pwd)

(12)

Les principes du SSO web

●

Authentification sur un (ou plusieurs) serveur(s)

– les applications ne voient pas les mots de passes

●

Redirections HTTP transparentes

– des applis vers les serveurs

– des serveurs vers les applis

●

Les redirections transportent de l'information

– cookies, paramètres url

(13)

CAS : Central Authentification Service

●

Mécanisme « SSO » avec 1 serveur centralisé

●

Un client accédant à 1 application est

redirigé vers le serveur d'authentification

●

Le serveur fait le contrôle d'identification et d'authentification et :

– délivre 1 cookie (TGC) conservé par le client, pour les authentifications futures

– délivre 1 « Ticket de Service » qui est

transmis par le client à l'application

(14)

●

l'application vérifie la validité de ce ticket auprès du serveur

●

Lors d'une demande ultérieure, le client transmet le TGC au serveur

d'authentification afin d'éviter une nouvelle authentification

●

TGC : utilisable plusieurs fois, durée de vie limitée, opaque (pas d'infos)

●

ST : non rejouable, opaque

(15)

1ère authentification directe auprès du serveur

serveur

authentification

navigateur web https

Le serveur retourne 1 formulaire d'authentification

(16)

1ère authentification directe auprès du serveur

serveur

authentification

(ldap)

(uid,pwd) TGC

TGC

●

TGC : Ticket Granting Cookie

– opaque

– rejouable

– permet d'éviter les ré-

authentifications

(17)

Accès à une application

après

authentification

1. accès application

2.redirection vers serveur CAS, transmission du TGC 3.le serveur CAS renvoie 1 ST 4.l'appli transmet le ST au

serveur,

5.le serveur retourne un accord

serveur

authentification

navigateur web

appli 1

1.

TGC ST

ST _●

ST : Service Ticket

●

opaque

●

1 seule utilisation

●

seule information reçue par l'application

2.

3.

4.

5.

(18)

En pratique : accès à une appli AVANT authentification

serveur

authentification

navigateur web

https

appli 1

(uid,pwd)

●

accès à l'appli

●

redirection vers le serveur CAS

●

transmission du formulaire

d'authentification

●

le client envoie ses

identifiants/passwd

(19)

serveur

authentification

(ldap)

TGC

appli 1

ST

●

Le serveur

retourne un ST et un TGC

●

le TGC est

conservé par le client

●

le ST est transmis à l'application

●

Toutes les

redirections sont

transparentes

(20)

CAS-sification d'une application

●

CAS permet de déporter l'authentification

– gestion et contrôle des mots de passe

●

L'application doit gérer ses utilisateurs et ses groupes d'utilisateurs

– base privée

– annuaire partagé

– niveaux de droits

●

les contrôles d'accès sont réalisés par

l'application

(21)

●

L'application doit réaliser 3 opérations :

– redirection vers le serveur CAS

– récupération d'un Service Ticket (dans l'URL)

– validation du Service Ticket

●

Librairies de CAS-sification :

– phpCAS, RORCAS ....

– implantent les opérations nécessaires à la cas-sification d 'une appli

–

http://www.ja-sig.org

(22)

●

Cas-sification d'une appli java :

–

http://www.jasig.org/cas/client-integration/java-client

– CASFilter : filtre d'urls placé dans web.xml

●

Les urls filtrés sont redirigées vers le serveur CAS

– CAS Tag Library : pour les pages JSP

(23)

Authentification « Single Sign-On » le mécanisme OpenID

Fédération d'identité : Shibboleth

(24)

OpenID : SSO pour sites web

●

Objectif :

– permettre l'authentification sur plusieurs sites avec le même identifiant/mdP

– serveurs d'authentification multiples : authentification non centralisée

●

Principe : l'identifiant est une URL permettant d'accéder au serveur d'authentification

– gcanals.myopenid.com

– www.loria.fr/~canals

– https://www.google.com/accounts/o8/id

(25)

Fournisseurs/consomateurs OpenID

●

Provider spécialisés :

– claimID, myOpenID, myid.net

●

Provider applicatif

– yahoo, Blogger, Flickr, Orange

●

sites acceptant l'authentification OpenID

– dailymotion, sourceforge, wikitravel

(26)

Redirection d'URLs

●

Identifiant OpenID sur un serveur Provider :

– gcanals.myopenid.com

●

On peut utiliser n'importe quelle URL pointant vers une page contenant une redirection vers ce provider :

– www.loria.fr/~canals

<link rel=”openid.server” href=”http://www.myopenid.com” /> –

<link rel=”openid.delegate” href=”http://gcanals.myopenid.com/” />

(27)

Termes

●

OpenID Consumer : l'application web demandant une authentification

●

OpenID Provider : le fournisseur

d'authentification, gérant les utilisateurs/

mots de passe

●

OpenID URL : URL utilisée comme

identifiant – dirige vers le Provider ou une page redirigeant vers le provider

●

YADIS : protocole de découverte du

Provider

(28)

Fonctionnement

serveur

authentification openID Provider

navigateur web web App

openID Consumer

1. post

OpenID URL

openID URL

2. Découverte Provider (YADIS)

3.obtention d'1 clé secrète de cryptage (MAC)

4.redirection provider

MAC

5. login 6. redirection Consumer

avec ID signée ID _mac

(29)

Programmation du Consumer

●

Fournit 2 urls :

– Begin : utilisée par l'utilisateur accédant au service

●

traitement des données du formulaire initial,

déclenchement du protocole YADIS, redirection vers le provider

– complete : utilisée par le Provider (redirection)

●

validation de l'authentification, accès au service

●

Librairie PHP, Python, Ruby, Java

– http://openidenabled.com/php-openid/

– Java : openid4java

(30)

// Instancier un ConsumerManager

public ConsumerManager _manager;

public MyConsumer() throws ConsumerException { _manager = new ConsumerManager();

}

// Définir une URL de retour (complete)

String _returnURL = ''http://my.example.net/openid/complete'';

// Créer la requête d'authentification //

protocole Yadis

List discoveries = manager.discover( userSuppliedString );

DiscoveryInformation discovered = manager.associate(discoveries);

// si nécessaire

session.setAttribute("discovered", discovered);

// obtain a AuthRequest message to be sent to the OpenID provider

AuthRequest authReq = manager.authenticate(discovered, _returnURL)

// Redirection

httpResp.sendRedirect(authReq.getDestinationUrl(true));

Partie 1 : traitement de l'url openid fournie par l'utilisateur

(31)

// Récupération des paramètres de la réponse du provider openid

ParameterList openidResp = new ParameterList(request.getParameterMap());

// Récupération de l'information en session

DiscoveryInformation discovered = (DiscoveryInformation)

session.getAttribute("discovered");

// URL de validation utilisée par le provider StringBuffer vURL = request.getRequestURL();

String qS = request.getQueryString();

if (qS != null && qS.length() > 0) vURL.append("?").append(qS);

// Vérification de la réponse

VerificationResult v = _consumerManager.verify(vURL.toString(), openidResp, discovered);

// extraction de l'identifiant utilisateur

Identifier idUser = verification.getVerifiedId();

if (idUser != null)

// SUCCES : utiliser idUser pour retrouver le profil de l'utilisateur dans // le référentiel local – mettre ce profil dans une variable de session else

// ECHEC de l'authentification

Partie 2 : traitement de la réponse du provider

(32)

●

OpenId : SSO pour le web

– Pas de serveur centralisé : passage à l'échelle

– Protocole de découverte du serveur d'authentification

●

Offre uniquement l'authentification

– Chaque application doit gérer ses utilisateurs,

ses groupes, ses droits

(33)

Shibboleth – fédération d'identités, profils

●

Fédérer des identités détenues par plusieurs sources

– par exemple : Nancy Université

●

Gérer les profils

– groupes d'utilisateurs communs à plusieurs applications

●

Peut s'appuyer sur un SSO (CAS ou autre)

(34)

Fournisseur Identité

navigateur web

profil

1. accès

nameID

web App Fournisseur

Service

userID passwd 2. redirection

nameID

3. login

4. authentification 5. redirection+ticket

nameID

6. obtention profil contrôle

accès 7. contrôle des droits

Sans SSO

referentiel utilisateurs

service Auth service Profil

(35)

Avec SSO

Fournisseur Identité

navigateur web

profil

1. accès

nameID

web App Fournisseur

Service

2. redirection

nameID

3. login 5. redirection+ticket

nameID

6. obtention profil contrôle

accès 7. contrôle des droits

serveur SSO (CAS)

4. check

ST

userID

referentiel utilisateurs

service Auth service Profil

(36)

Fédération d'identité

Fournisseur Identité (ex. UHP)

navigateur web web App

Fournisseur Service

2. redirection WAYF

Fournisseur Identité (ex. Nancy2) WAYF

serveur SSO (CAS)

ST

serveur SSO (CAS)

3. redirection FI 1. accès

WAYF : aiguillage

vers un fournisseur

d'identité

●

L'application ne connaît

pas le fournisseur d'Id.

(37)

Autres systèmes

●

SSO centralisé

– LemonLDAP::NG

– LID

●