Upload
hahuong
View
220
Download
1
Embed Size (px)
Citation preview
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
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.