Authentification et contrôle d'accès dans les applications websnakeeyes57.free.fr/fac/Master/M1/Applications Web/cours-auth.pdf · SSO (CAS) 4. check ST ST userID referentiel utilisateurs

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

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 ...

● 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 ?

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

● 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)

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

● Role-Based Access Control– Permissions assignées à des rôles– Les usagers sont affectés à un ou plusieurs

rôles

Identification/Authentification

navigateur web

appli web

référentielutilisateurs

(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

● 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

référentielutilisateurs

(ldap)Service

(uid,pwd)

(uid,pwd)(uid,pwd)(uid,pwd)

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

référentielutilisateurs

(ldap)Service

(uid,pwd)

serveur authentification

Single Sign-On

● Une seule authentification pour un groupe d'applications

appli 2(uid,pwd)

navigateur web

appli 1 appli 3

référentielutilisateurs

(ldap)Service

(uid,pwd)

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

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

● 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

1ère authentification directe auprès du serveur

serveur authentification

navigateur web

httpsLe serveur retourne 1 formulaire d'authentification

1ère authentification directe auprès du serveur

serveur authentification

navigateur web

https

référentielutilisateurs

(ldap)

(uid,pwd)TGC

TGC

● TGC : Ticket Granting Cookie– opaque– rejouable– permet d'éviter les ré-

authentifications

Accès à une applicationaprè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.

TGCST

ST ● ST : Service Ticket

● opaque● 1 seule utilisation● seule information reçue

par l'application2.

3.

4.

5.

En pratique : accès à une appli AVANT authentification

serveur authentification

navigateur web

htt

ps

appli 1

(uid,pwd)

● accès à l'appli● redirection vers le

serveur CAS● transmission du

formulaire d'authentification

● le client envoie ses identifiants/passwd

serveur authentification

navigateur web

https

référentielutilisateurs

(ldap)

TGC

TGC

appli 1

ST

ST

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

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

● 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

● 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

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

Fédération d'identité : Shibboleth

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

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

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/” />

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

Fonctionnement

serveur authentificationopenID Provider

navigateur web

web AppopenID Consumer

1. post OpenID URL

openID URL

2. Découverte Provider(YADIS)

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

4.redirection provider

MAC

5. login6. redirection Consumeravec ID signée

ID mac

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

// 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

// 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

● 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

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)

FournisseurIdentité

navigateur web

profil

1. accès

nameID

web AppFournisseur

Service

user

ID

pass

wd

2. redirection

nameID3. login

4. authentification5. redirection+ticket

nameID

6. obtention profil

contrôleaccès

7. contrôle des droits

Sans SSOreferentielutilisateurs

service Auth

service Profil

Avec SSO

FournisseurIdentité

navigateur web

profil

1. accès

nameID

web AppFournisseur

Service

2. redirection

nameID

3. login

5. redirection+ticket

nameID

6. obtention profil

contrôleaccès

7. contrôle des droits

serveurSSO

(CAS)

4. check

ST

ST

userID

referentielutilisateurs

service Auth

service Profil

Fédération d'identité

FournisseurIdentité

(ex. UHP)

navigateur web

web AppFournisseur

Service

2. redirectionWAYF

FournisseurIdentité

(ex. Nancy2)WAYF

serveurSSO

(CAS)ST

serveurSSO

(CAS)

3. redirection FI

1. accès

WAYF : aiguillage vers un

fournisseur d'identité

● L'application ne connaît pas le fournisseur d'Id.

Autres systèmes

● SSO centralisé– LemonLDAP::NG– LID

● SSO fédératif– Liberty Alliance (IBM, Sun, Novell)– WS-Federation (PassPort Microsoft)