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

Authentification et contrôle d'accès dans 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 attributs appli web profil(uid)? uid+crypt(pwd)? uid? référentiel utilisateurs (sql) Https : (uid,pwd) navigateur web 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 (uid,pwd) Service référentiel utilisateurs (ldap) (uid,pwd) (uid,pwd) appli 1 appli 2 appli 3 (uid,pwd) (uid,pwd) navigateur web

problèmes Authentification auprès de chaque application Mot de passe transmis à chaque application (uid,pwd) Service référentiel utilisateurs (ldap) (uid,pwd) appli 2 (uid,pwd) appli 1 appli 3 (uid,pwd) (uid,pwd) navigateur web

Single Sign-On Une seule authentification pour un groupe d'applications Service référentiel utilisateurs (ldap) appli 1 appli 2 appli 3 serveur authentification (uid,pwd) (uid,pwd) navigateur web

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 https Le serveur retourne 1 formulaire d'authentification navigateur web

1ère authentification directe auprès du serveur référentiel utilisateurs (ldap) serveur authentification (uid,pwd) https TGC TGC : Ticket Granting Cookie opaque navigateur web TGC rejouable permet d'éviter les réauthentifications

Accès à une application après authentification serveur authentification TGC ST 2. navigateur web 3. 4. 1. 5. appli 1 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 ST ST : Service Ticket opaque 1 seule utilisation seule information reçue par l'application

En pratique : accès à une appli AVANT authentification accès à l'appli (uid,pwd) serveur authentification appli 1 redirection vers le serveur CAS transmission du formulaire d'authentification https navigateur web le client envoie ses identifiants/passwd

référentiel utilisateurs (ldap) Le serveur retourne un ST et un TGC serveur authentification ST appli 1 le TGC est conservé par le client https ST TGC ST le ST est transmis à l'application navigateur web TGC 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 openid URL web App openid Consumer 2. Découverte Provider (YADIS) MAC 3.obtention d'1 clé secrète de cryptage (MAC) serveur authentification openid Provider 1. post OpenID URL ID mac 6. redirection Consumer avec ID signée 5. login 4.redirection provider navigateur web

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)

Sans SSO 7. contrôle des droits contrôle accès profil Fournisseur Identité referentiel utilisateurs web App Fournisseur Service 6. obtention profil nameid service Profil service Auth 5. redirection+ticket 4. authentification 1. accès nameid nameid 2. redirection userid passwd 3. login navigateur web

Avec SSO 7. contrôle des droits contrôle accès web App Fournisseur Service profil 6. obtention profil nameid Fournisseur Identité service Profil service Auth referentiel utilisateurs 5. redirection+ticket nameid nameid userid 1. accès 2. redirection ST navigateur web ST 3. login serveur SSO (CAS) 4. check

Fédération d'identité L'application ne connaît pas le fournisseur d'id. serveur SSO (CAS) web App Fournisseur Service 1. accès WAYF : aiguillage vers un fournisseur d'identité 2. redirection WAYF WAYF Fournisseur Identité (ex. UHP) 3. redirection FI ST Fournisseur Identité (ex. Nancy2) serveur SSO (CAS) navigateur web

Autres systèmes SSO centralisé LemonLDAP::NG LID SSO fédératif Liberty Alliance (IBM, Sun, Novell) WS-Federation (PassPort Microsoft)