Contrôle d accès basé sur les rôles et négociation dans un environnement multi cercles de confiance Auteur : François Tachoires, v1.0, 06/06/2008 Encadrants EADS : Augustin De Miscault, Marie Nuadi Encadrants Telecom Bretagne : Frédéric et Nora Cuppens Rapport de stage du master recherche informatique de l université de Rennes I Mots-clés : contrôle d accès, rôle, XACML, SAML, inter-cot, fédération des identités, B2B, négociation de politiques de sécurité 1/48
RESUME... 4 1. INTRODUCTION... 5 2. CONTEXTE DU TRAVAIL... 6 2.1. PROJET FC²... 6 2.2. ENQUETE JUDICIAIRE : EXEMPLE D APPLICATION... 6 2.3. GENERALITES SUR LA FEDERATION DES IDENTITES... 7 3. CONTROLE D ACCES ENTRE CERCLES DE CONFIANCE... 8 3.1. L EXISTANT ET SES LIMITES... 8 3.1.1. Problème 1 : Gestion des authentifications et du contrôle d accès centralisé... 9 3.1.2. Problème 2 : Le contrôle d accès basé sur les rôles... 9 3.1.3. Problème 3 : L échange des rôles des utilisateurs... 10 3.1.4. Problème 4 : La transmission de l authentification... 10 3.2. OBJECTIFS... 11 3.3. SPECIFICATIONS... 11 3.3.1. Exigences... 11 3.3.2. Fonctionnalités... 16 3.4. STANDARDS PERTINENTS POUR REPONDRE AUX SPECIFICATIONS... 17 3.5. UN ROLE DYNAMIQUE VIA LES ATTRIBUTS... 17 4. UNE SOLUTION DE CONTROLE D ACCES MULTI-CERCLES BASEE SUR SAML ET XACML... 19 4.1. FORMAT DES ATTRIBUTS ECHANGES... 19 4.1.1. Les attributs SAML... 19 4.1.2. Les attributs XACML... 19 4.1.3. XACML Attribute profile... 19 4.1.4. Cas 1 : rôle sans attributs sensibles... 20 4.1.5. Cas 2 : rôle avec attributs sensibles... 20 4.2. SOLUTION PROPOSEE POUR LE CONTROLE D ACCES... 21 4.2.1. Architecture globale... 21 4.2.2. Fédération pour la phase d authentification... 21 4.2.3. Phase d autorisation... 22 4.2.4. Architecture détaillée côté SP WSC... 25 4.2.5. Architecture détaillée côté IDP WSP... 25 4.2.6. XACML en détail dans le cas Enquête Judiciaire... 29 4.3. DEPLOIEMENTS POSSIBLES... 30 4.3.1. Cas 1 un module intégralement externe... 31 4.3.2. Cas 2 des agents PEP distribués sur les SP avec un PDP central partagé... 31 4.3.3. Cas 3 des agents PEP distribués sur les SP avec plusieurs PDP distribués... 32 4.3.4. Cas 4 des agents PEP+PDP localisés sur les SP... 32 5. UNE SOLUTION INNOVANTE BASEE SUR LA NEGOCIATION DE POLITIQUES... 33 5.1. LES INTERETS DE LA NEGOCIATION... 33 5.2. L ARCHITECTURE ET LES ECHANGES GENERAUX... 33 5.3. EXEMPLE THEORIQUE DE NEGOCIATION AVEC TRUSTBUILDER... 35 6. COMPARAISON DES DEUX SOLUTIONS... 37 7. AXES FUTURS DE TRAVAIL... 38 7.1. DEPLOIEMENT POUR PREUVE DE CONCEPT... 38 7.2. LIMITES... 38 7.2.1. L administration des politiques de sécurité... 38 7.2.2. Utilisation d un rôle entre différents cercles de confiance... 38 8. CONCLUSION... 39 2/48
GLOSSAIRE... 40 BIBLIOGRAPHIE... 41 TABLE DES FIGURES... 42 9. ANNEXES... 43 9.1. FEDERATION DES IDENTITES : SAML 2.0 ET LIBERTY ALLIANCE... 43 9.2. L AUTORISATION : LE STANDARD XACML... 44 9.2.1. Description de XACML 2.0... 44 9.2.2. Un exemple simple... 46 9.2.3. Le profil RBAC pour XACML 2.0... 48 3/48
Résumé Les problématiques de SSO et de contrôle d accès aux applications d une entreprise sont bien connues et généralement résolues grâce à des annuaires internes. Cependant, donner des accès à des utilisateurs hors domaine, dans le cadre de partenariats inter-entreprises par exemple, est effectué le plus souvent manuellement par les administrateurs. Ce rapport présente deux solutions de contrôle d accès dans un environnement multi-cercles de confiance. La première est basée sur des standards ouverts pour échanger les informations d'authentification et de rôle des utilisateurs. Les standards étudiés sont SAML pour la fédération, et le transport d informations d authentification, de rôle et d autorisation, et XACML pour exprimer les politiques de contrôle d accès. La deuxième est une solution innovante qui repose sur des échanges de politiques entre deux modules de négociation. Un niveau de confiance bilatéral est atteint avec suite à un échange progressif d affirmations signées, et alors une autorisation d accès peut être donnée. 4/48
1. Introduction Aujourd hui, un internaute n a pas la possibilité de gérer simplement et efficacement son identité : il manque clairement une abstraction de l identité sur Internet. Tout internaute doit créer de multiples comptes sur chaque service qu il utilise, avec autant de mots de passe associés, et à la clé une ergonomie faible. Pour répondre à cette problématique, différents standards ont émergé, comme Liberty Alliance, Shibboleth, OpenID, Higgins, Cardspace et SAML 2.0. Ces standards définissent des architectures et des protocoles pour fédérer des identités entre les domaines, pour faire bénéficier à l internaute du SSO (Single-Sign On). Les problématiques de SSO au sein d une même entreprise sont souvent résolues à l aide d outils dits de E-SSO. Ces outils permettent de réaliser, de manière transparente pour l utilisateur, une authentification auprès des différentes applications auxquelles il a accès. Cependant les différentes solutions propriétaires ne sont pas interopérables et ne permettent donc pas de faire du SSO multi-domaines. Dans le cadre de partenariats entre deux entreprises, un utilisateur dont l identité est connue par son entreprise souhaite accéder à un service hébergé par l autre entreprise. Le contrôle d accès multi-domaines B2B est administré manuellement à l heure actuelle. Des accès particuliers sont ajoutés pour les personnes externes à l organisation. La transmission sécurisée des informations sur le rôle de l utilisateur permettrait de gérer ses droits d accès externes, suite à des accords entre les entreprises. L utilisation de standards compréhensibles par n importe quelle entreprise est un point clé pour résoudre cette problématique. Dans ce rapport nous allons discuter de cette utilisation des standards de fédération et de contrôle d accès pour donner des permissions spécifiques dans le cadre d échanges B2B, en basant la prise de décision sur un rôle joué par l utilisateur au sein de son entreprise. Dans un premier temps, nous décrivons le contexte dans lequel le travail a été réalisé, puis nous développons les limites de l existant et les objectifs du travail réalisé. Les standards pertinents et les formats des attributs échangés sont présentés, nous détaillons ensuite deux solutions possibles, l une basée sur l architecture XACML et l autre sur des principes de négociation de politiques de sécurité. Finalement nous évoquons les axes futurs de travail et concluons. 5/48
2. Contexte du travail 2.1. Projet FC² Le projet FC² se propose de concevoir une plate-forme complète permettant le développement sécurisé de nouveaux services électroniques basés sur la gestion transparente et fédérée d identités et s organisant autour de trois concepts principaux : 1) Définition et mise en œuvre de modèles d architectures de fédération d identité interopérables (Liberty Alliance, Microsoft/Cardspace, SAML, OpenID etc.) ; 2) Mise en place d une infrastructure dédiée pour les fournisseurs de service ; 3) Fourniture de services d authentification forte et de gestion de la vie privée. L enjeu du projet est multiple et vise les objectifs clés suivants : Garantir un haut niveau de prévention contre les attaques sur l identité numérique et lutter efficacement contre les divers types de fraude associés ; contribuer au développement efficace de nouveaux services basés sur l identité numérique, y compris dans une dimension multi sectorielle ; donner à l utilisateur final une plate-forme personnelle autorisant un meilleur confort et une plus grande facilité d utilisation vis à vis des systèmes transactionnels en ligne (ergonomie confiance - universalité d emploi). 2.2. Enquête Judiciaire : exemple d application Nous nous intéressons plus particulièrement à un cas d usage B2B particulier, le cas «Enquête Judiciaire». Tout au long de ce rapport, c est cet exemple qui sera le plus utilisé pour illustrer nos propos. Il ne s agit, bien sûr, que d un exemple qui est comparable à d autres situations classiques dans le milieu industriel, où l administrateur d un service a besoin de donner des accès à des utilisateurs externes. Un cercle de confiance (ou CoT pour Circle of Trust) contient un ensemble d entités fournissant des services et/ou des identités entre lesquels une relation de confiance existe et donc auxquels l utilisateur peut accéder librement après une authentification unique. Dans ce cas d usage, un enquêteur du CoT gouvernemental souhaite accéder à un service sur le CoT Telecom, pour les besoins de son enquête (exemple : connaître la liste des numéros appelés par un suspect). L objectif est le suivant : on souhaite que le CoT gouvernemental puisse partager avec le CoT Telecom les informations sur l authentification ainsi que les attributs prouvant que l utilisateur est un enquêteur, afin que ce dernier puisse accéder au service Telecom. Le CoT Telecom n aurait ainsi pas à gérer manuellement l identité de l enquêteur pour donner l accès à son service, il ferait confiance aux informations fournies par le CoT gouvernemental sur l enquêteur. La figure 1 illustre ce cas : 6/48
Figure 1 : Cas enquête judiciaire 2.3. Généralités sur la fédération des identités Une fédération d identités est constituée des acteurs principaux suivants : un fournisseur d identité (IDP), un ou plusieurs fournisseurs de services (SP), et des utilisateurs. Pour simplifier l expérience de l utilisateur, il est souhaitable qu il puisse se connecter à plusieurs services, au cours d une même session, après une seule authentification. Ainsi, si un utilisateur possède plusieurs comptes sur différents services, le système va lui permettre de les fédérer, c est-à-dire de les relier, afin de pouvoir bénéficier du SSO. Le standard pour s échanger des informations sur l authentification d un utilisateur est SAML [2] dont les spécifications du consortium OASIS en sont à la version 2.0 (voir en annexe pour plus d informations). Concrètement, à l heure actuelle, l identité de l utilisateur est disséminée sur Internet. Pour accéder au moindre service (forum, réseau social, e-commerce ) l utilisateur doit créer un compte de type identifiant/mot de passe. Il doit mettre lui-même à jour ses informations personnelles (nom, date de naissance, e-mail, adresse ) dans les formulaires à remplir. Fédérer ses comptes lui permet donc, au cours d une même session, de se connecter à plusieurs services sans s authentifier à nouveau plus éventuellement transférer des informations personnelles (attributs). 7/48
3. Contrôle d accès entre cercles de confiance 3.1. L existant et ses limites Vérifier que les utilisateurs ont des droits ou privilèges suffisants avant de leur donner l accès à une ressource est constamment réalisé. C est la base de la sécurité de tout système d information. La bonne gestion des droits d accès des utilisateurs est donc une problématique classique sur tous les SI. Or, étant donné l explosion du nombre de services proposés par les SI, la gestion de ces droits d accès est devenue lourde à gérer pour les administrateurs. Quant aux utilisateurs, ils se sentent perdus devant l hétérogénéité des systèmes d authentification et d autorisation. Par exemple, ils travaillent fréquemment avec plusieurs couples identifiant/mot de passe. Généralement l administrateur définit les règles d accès par application. Il définit dans un premier temps une politique de sécurité, puis l intègre à son application dans un deuxième temps. Définir une politique consiste à lister des règles qui précisent les actions autorisées en fonction d un ensemble de conditions (voir figure 2). Dans le cas général, l administrateur utilise des politiques dites fermées, où l accès est par défaut interdit, puis définit les exceptions via ces politiques. Par exemple, un serveur web Apache permet de protéger les accès à un site web à l aide du fichier.htaccess, dans lequel on trouve la liste des utilisateurs qui sont autorisés à accéder à un endroit précis d un site web. Tous les autres utilisateurs se voient refuser l accès. Figure 2 : Contrôle d accès classique Cette solution très répandue pose principalement quatre problèmes : o Problème 1 : L administrateur configure pour chaque application une politique de sécurité dans un langage particulier, souvent de bas niveau ; o Problème 2 : L administrateur configure les accès pour chaque utilisateur ou doit gérer manuellement des groupes d utilisateurs ; o Problème 3 : L administrateur de l application doit gérer les données sur l utilisateur. Par exemple, si un employé qui avait des accès à trois services particuliers quitte l entreprise, il faudra supprimer ses droits sur chacun des services ; o Problème 4 : L utilisateur possède autant de méthodes d authentification (identifiant/mot de passe) que d applications auxquelles il accède. Il est difficile, lorsqu une organisation fournit beaucoup de services, de garder une cohérence et d avoir une vue d ensemble sur les droits d accès aux différents services offerts. La gestion de l ensemble devient compliquée pour l administrateur et est source d erreur. 8/48
3.1.1. Problème 1 : Gestion des authentifications et du contrôle d accès centralisé Faire du contrôle d accès signifie prendre une décision d autorisation en fonction de deux types principaux de données : l authentification de l utilisateur, des attributs (sur la ressource, le contexte et l utilisateur), voir figure 4. Le contexte actuel est que chaque service a son langage pour définir des règles pour protéger l accès à ses ressources. Ces politiques ne sont donc pas réutilisables d un service à un autre. De même chaque service propose son système d authentification. C est ce que schématise le côté gauche de la figure 3. Figure 3 : contrôle d accès classique vs contrôle d accès centralisé De ces constatations on remarque qu il serait souhaitable de simplifier les méthodes de contrôle d accès aux services afin d en faciliter l administration et donc au final d améliorer la sécurité de l ensemble. L objectif est de pouvoir externaliser une partie du contrôle d accès d un certain nombre de services, afin de maintenir la cohérence de la politique de sécurité globale de l organisation. Lors de l ajout d un service par exemple, l administrateur pourrait ainsi réutiliser certaines politiques d un autre service déjà existant. Il serait notamment intéressant de pouvoir utiliser à nouveau différents rôles communs au système, au lieu de redéfinir des groupes spécifiques à chaque application. L emploi de standards est nécessaire pour apporter une réponse à ce problème, dans le cas où l on veut avoir l opportunité d échanger des informations de politiques de contrôle d accès avec d autres entreprises. Il faut un standard qui propose l échange de données sur l authentification des utilisateurs (le service fait alors confiance à un ou plusieurs fournisseurs d identité) et un autre qui définit un langage de politique de contrôle d accès indépendamment des spécificités de la ressource protégée. 3.1.2. Problème 2 : Le contrôle d accès basé sur les rôles Dans un contexte de contrôle d accès sur des ressources réparties sur un ou plusieurs réseaux, l abstraction au niveau des rôles semble intéressante. Les droits d accès sont définis pour un 9/48
ensemble d utilisateurs jouant le même rôle dans l organisation. En effet pour un certain nombre d application l information d identité (nom d utilisateur etc.) est moins importante pour le contrôle d accès que le rôle dans l organisation. Dans la majorité des cas, le contrôle d accès type RBAC (Role-Based Access Control), se révèle être une abstraction intéressante pour gérer les accès aux ressources. Pour l administrateur elle permet d éviter de configurer les accès pour chaque utilisateur. Dans le cas d usage «Enquête Judiciaire» par exemple, un agent de la police avec le rôle enquêteur a accès à l application Telecom d enquête judiciaire, alors qu un agent de police sans ce rôle n y aura pas accès. RBAC a vraiment un intérêt particulier dans ce cas si l affectation des rôles aux utilisateurs peut être automatisé. 3.1.3. Problème 3 : L échange des rôles des utilisateurs Un agent de police ne conserve pas forcément le rôle enquêteur tout au long de sa carrière. Cette information est connue par l organisation qui l emploie, elle doit donc être gérée par celle-ci. Pour assurer un contrôle d accès efficace sur le service Enquête Judiciaire du CoT Telecom, il est souhaitable que le cercle Telecom n ait pas à gérer ce type d informations. Créer un compte par enquêteur sur le service, et mettre à jour manuellement les droits en fonction des arrivées/départs d enquêteurs est une solution trop lourde pour l administrateur du service Telecom. De plus, cela ne relève pas de sa responsabilité. On souhaite donc que le service Telecom «Enquête Judiciaire» puisse prendre des décisions de contrôle d accès en fonction d une information de rôle d utilisateur transmise par le cercle gouvernemental, via un attribut role par exemple, qui assure le maintien et la validité de ces informations. profils informations d'authentification + informations de profil Serveur d'authentification Enquêteur accès autorisé Service Enquête Judiciaire Figure 4 : Accès via rôle entre deux CoTs 3.1.4. Problème 4 : La transmission de l authentification Les solutions de SSO et de fédération des identités visent à résoudre le problème de la multiplication des couples identifiant/mot de passe à saisir et à retenir par l utilisateur. Leur surnombre implique des oublis de mot de passe, l utilisation de mots de passe faibles ou identiques. Tout cela nuit à la sécurité. Du point de vue de l utilisateur, le SSO améliore l ergonomie puisqu il peut accéder à un ensemble de services après une seule authentification, qui peut être plus forte qu un login/password habituel. La sécurité globale du système s en trouve améliorée, puisqu une meilleure gestion des identités et de leurs droits associés est assurée. Il faut cependant noter qu un vol d identité peut alors avoir des conséquences plus graves, puisqu elle donne accès à plusieurs services. Grâce à la transmission des informations d authentification, l utilisateur n a pas à se ré authentifier sur le service d enquête judiciaire. 10/48
3.2. Objectifs La fédération des identités est d abord un concept destiné à améliorer l expérience de l internaute. Il semble intéressant tout de même d utiliser ces standards dans le cadre d échanges B2B. L objectif général est donc de réaliser du contrôle d accès B2B grâce aux informations sur l identité échangées via un standard de fédération d identités. Les contraintes en B2B sont différentes : dans ce cadre-là, l employé d une entreprise a confiance en elle pour stocker et gérer des données personnelles sur son identité. Nous allons parler de «module de contrôle d accès» pour nous référer à la fonctionnalité supplémentaire proposée. Voici les caractéristiques clés que doit apporter le module de contrôle d accès à un ou plusieurs services disponibles dans un cercle de confiance. Amélioration de l expérience utilisateur : Accéder à des services hors de son domaine après une authentification unique sur son domaine (éventuellement une ré authentification si souhaité) Bénéficier de privilèges sur un domaine B grâce à son rôle certifié par son domaine A. Amélioration de l expérience administrateur : Ouvrir l accès aux applications à des utilisateurs externes au domaine et au CoT sans en perdre le contrôle ; Ne pas avoir à créer un compte individuel pour un utilisateur externe ; Déléguer l administration de l identité, du rôle et des attributs des utilisateurs externes à l organisation à l administrateur des organisations partenaires ; Centraliser les politiques d un ensemble de services aux exigences de sécurité proches, et ainsi en faciliter la vision et l administration ; Exprimer une politique de sécurité fine quelle que soit la ressource à protéger à l aide d un langage standard ; Garder un contrôle fin sur la diffusion du rôle ou des attributs afin de respecter la vie privée des utilisateurs, et protéger ces informations potentiellement sensibles ; Garder des traces sur les connexions et les requêtes, lors de l utilisation de services sensibles. 3.3. Spécifications 3.3.1. Exigences Quelques définitions pour le contrôle d accès Un module de gestion de contrôle d accès a différentes tâches à exécuter, qui sont confiées à divers éléments. Avant d aller plus loin, voici donc quelques définitions de formalisation de ces différents éléments, indispensables à la compréhension de la suite du document : PEP, Policy Enforcement Point : élément chargé de mettre en œuvre le contrôle d accès. Il applique les décisions de politiques en réponse aux requêtes des utilisateurs qui veulent accéder à une ressource sur le réseau ; PDP, Policy Decision Point : élément chargé de prendre une décision (Permit ou Deny) à l aide d un ensemble d informations (politiques, identité de l utilisateur, ressource, contexte). Il est consulté par le PEP ; PAP, Policy Administration Point : élément permettant à l administrateur de gérer les politiques de sécurité. Il fournira les politiques au PDP quand celui-ci les lui demandera ; PIP, Policy Information Point : élément chargé de récupérer d autres informations utiles à la prise de décision (sur l utilisateur, la ressource, l environnement ). 11/48
Ces termes de PEP et PDP sont apparus dans la RFC 2748 qui définit le protocole COPS. A noter que nous parlerons également d IDP (fournisseur d identité), de SP (fournisseur de service) et d AP (fournisseur d attributs). Un attribut est un couple (nom, valeur) qui représente une information sur une caractéristique d un sujet, une ressource ou un environnement. Par exemple l attribut fonction= agent de la police judiciaire pourra être utilisé dans le cas Enquête Judiciaire. Un attribut peut être multi-valué. Dans ce cas-là c est un n-uplet (nom, valeur1, valeur2,, valeur(n-1)). Un rôle permet de représenter une fonction d un sujet au sein d une organisation. Une politique d accès rassemble une ou plusieurs règles définissant quelle action peut faire tel ou tel sujet sur une ressource, dans tel contexte. Une règle est composée de conditions, d actions et éventuellement d obligations. Par exemple, sous la condition que l utilisateur (qui demande l accès) possède le rôle enquêteur, l action est d autoriser l accès, avec obligation de garder une trace dans un fichier de log. Les exigences de l utilisateur L utilisateur a un compte sur l IDP gouvernemental dans le cas Enquête Judiciaire, mais n a pas de compte sur l IDP Telecom. L IDP Telecom est capable de valider l authentification de l utilisateur sur l IDP gouvernemental. L authentification fonctionne de la manière suivante : l utilisateur bénéficie du SSO lors d accès à de multiples services, sur de multiples CoTs : 1. Il s authentifie sur l IDP de son CoT (IDP1) ; 2. Il accède au SP1 qui l authentifie de manière transparente grâce à l IDP1 ; 3. Il accède à un deuxième SP2, sur un autre CoT, qui l authentifie encore de manière transparente. Le schéma ci-dessous présente cette cinématique : compte utilisateur A IDP1 1 IDP2 SP1 2 3 SP2 Utilisateur A Figure 5 : un cas d'usage de SSO multi-cots Sur cette figure, les flèches fines entre SP et IDP, et entre IDP et IDP, représentent le partage des informations d authentification et d attributs, qui est effectué de manière transparente pour l utilisateur. Différentes méthodes d authentification sont envisageables. Suivant les méthodes utilisées, le poste client peut devoir disposer d éléments supplémentaires (par exemple un lecteur de carte à puce). Un SP peut exiger un niveau d authentification particulier et à ce moment-là l utilisateur doit se ré authentifier sur l IDP avec la méthode d authentification adéquate. Les sessions sont 12/48
généralement gérées via l utilisation de cookie sur le navigateur client. Pour pouvoir bénéficier du SSO et du SLO l utilisateur doit donc accepter ces cookies. La politique d utilisation de ces éventuels cookies doit tenir compte du vol de cookie ou du «cookie hijacking». Comme un cookie permet à l utilisateur qui le possède de s authentifier sur n importe quel SP, le vol de cookie par un attaquant peut avoir des conséquences graves. Si le cookie n est pas chiffré et volé, l attaquant peut récupérer des informations confidentielles sur l identité de l utilisateur, et ses attributs. Cependant, même si ce cookie est chiffré, et s il est utilisé lors d une connexion via un canal non sécurisé (HTTP par exemple), il peut être sniffé et rejoué par un attaquant, qui pourra voler la session de l utilisateur et accéder à tous ses services avec ses privilèges. Figure 6 : cookie hijacking Le cookie doit être chiffré et le risque de rejeu doit être diminué (via des timestamps par exemple). L utilisateur ne possède pas de compte sur le SP. Dans le cas Enquête Judicaire, l enquêteur n a pas non plus de compte sur l IDP Telecom. Les exigences de l administrateur On distingue deux administrateurs : l administrateur d un SP l administrateur de l IDP L administrateur d un SP L administrateur d un SP peut avoir plusieurs SP à gérer. Le rôle de l administrateur d un SP est de gérer finement les accès au service qu il met en place. L administrateur d un SP est à la fois administrateur des SP dont il a la charge et administrateur du point du module de contrôle d accès où les politiques sont définies. L administrateur sur le module de contrôle d accès crée, modifie, supprime : des règles définissant les rôles des utilisateurs de son cercle de confiance, des politiques de contrôle d accès en définissant des règles qui s appliquent aux rôles. administrateur définit une politique de sécurité pour son système d'information active des agents de sécurité sur les SP crée les politiques d'accès a une vision d'ensemble sur les accès à son système a des logs sur l'ensemble des accès Figure 7 : cas d'utilisation du point de vue d un administrateur SP PEPs PAP L administrateur de SP doit pouvoir retrouver les actions utilisateurs et leurs auteurs. Il doit donc avoir à disposition des traces précises sur les accès au service. Ceux-ci doivent être journalisés, avec un lien permettant de remonter à l identité de l utilisateur. Ces traces contiendront par exemple des informations de date, heure, identité de l utilisateur, requête effectuée, ressource concernée Il ne gère pas les attributs des utilisateurs extérieurs au CoT. Il ne gère pas l ajout ou la suppression de comptes destinés à des personnes extérieures à l organisation. L administrateur d un IDP L administrateur d un système d informations, qui gère les différentes identités de son système, souhaite avoir une vue générale sur ses identités. Il souhaite ne pas avoir à gérer les identités de 13/48
personnes externes à l organisation, mais plutôt collaborer avec les fournisseurs d identité des autres organisations. Il souhaite avoir une vue d ensemble sur les politiques d accès aux services hébergés sur son système et pouvoir générer des rapports sur les statistiques de ces accès. Cette administration d ensemble peut être facilitée par l existence de rôles au sein de son système, qui représentent l abstraction d utilisateurs. Il souhaite partager des informations sur les attributs de ces utilisateurs, de manière contrôlée (respect de la vie privée des utilisateurs, confidentialité de certains attributs), avec des fournisseurs de service de confiance avec qui des accords auront été passés. Les exigences en termes de sécurité des ressources Quand on parle de contrôle d accès, il s agit tout d abord d identifier les ressources que l on souhaite protéger. Dans le cadre qui nous intéresse, elles sont de plusieurs types : Les données liées à un service proposé. On se limite a des ressources disponibles depuis un serveur web. Les informations personnelles des utilisateurs. Il s agit d assurer aux utilisateurs que leurs données personnelles (attributs) sont en sécurité. Même si Liberty Alliance assure que les informations concernant les utilisateurs sont toujours transmises avec l autorisation de l utilisateur, on peut craindre certains abus de la part de fournisseurs de service peu scrupuleux (par exemple un SP pourrait demander plus d attributs qu il n en a réellement besoin), et il apparaît donc nécessaire de protéger les accès à ces ressources. On souhaiterait que seuls les attributs nécessaires et suffisants pour l accès à un service soient transmis. Les politiques de sécurité liées à un service. On peut également imaginer que ces politiques doivent être protégées au même titre par exemple que l annuaire des utilisateurs. La connaissance de la politique de sécurité liée à un service peut aider un attaquant à la contourner, en l étudiant et en exploitant des vulnérabilités. Il faudra assurer donc que l élément qui réclame des politiques est de confiance. Les cookies et informations de sessions. Afin de garder en mémoire un contexte de sécurité après une authentification réussie à un service, fournisseur et utilisateur doivent stocker en local et se transmettre un certain nombre d informations liées à une session (heure, validité, contexte de sécurité, informations propre à l application.). Il faut empêcher l usurpation d identité. Les exigences pour les informations d authentification Le module de contrôle d accès devra être capable d analyser les informations contenues dans ce jeton d authentification, et d exprimer ses conditions suivant ces exigences en termes de contrôle des accès. C est-à-dire qu il pourra exiger que ce jeton d authentification soit délivré et certifié (signature) par un IDP particulier, il devra pouvoir en vérifier la validité (date et heure, émetteur et destinataire corrects ). SAML préconise l utilisation de standards pour cela (XML-Signature, TLS/SSL) Utilisateur demande d'accès + jeton d'authentification 1. Vérification du jeton 2. Analyse de la requête 3. Décision Figure 8 : gestion du jeton d'authentification 14/48
Suivant l analyse de la requête avec les informations du jeton d authentification, plus d autres informations que peut obtenir le module, une décision sera prise. Cette décision pourra être : Accès autorisé Accès refusé Redirection pour l obtention d un autre jeton d authentification (ayant un autre niveau d authentification ou provenant d une autre source Erreur (avec message descriptif éventuel) SAML ne préconise pas d authentification particulière mais permet simplement de transporter dans ces jetons le contexte d authentification. Le module, pourra formuler des exigences sur ce contexte afin de contrôler l accès aux ressources. Les exigences pour la diffusion des attributs Pour prendre une décision d accès, le module peut avoir besoin, en plus des informations autour de l authentification de l utilisateur, d informations le caractérisant. Il doit donc être capable de récupérer les attributs auprès des fournisseurs d attributs de l utilisateur via les protocoles SAML adéquats. Un attribut est une affirmation (clé=valeur). Par exemple, pour l utilisateur Jean Dupont aura les attributs suivants : Nom= Dupont Prenom= Jean Email= jean.dupont@entreprise.fr Il est important de noter que, dans un usage multi CoTs plus particulièrement, il est indispensable de connaître l émetteur de ces attributs. Ceux-ci doivent donc être signés par l autorité émettrice, car certains attributs pourront avoir la même clé sur différents CoTs, et donc une signification différente. Par exemple, Jean Dupont peut avoir un attribut role= ingénieur sur le fournisseur d attributs de son employeur, et un attribut role= trésorier sur le fournisseur d attributs d une association dont il fait partie. Prendre des décisions d accès via des attributs signifie donc que ces attributs sont certifiés par l émetteur. L intégrité doit pouvoir être également vérifiée. La confidentialité lors de la diffusion des attributs est un critère important, indispensable pour protéger non seulement la vie privée de l utilisateur mais souvent aussi son entreprise pour qui ces informations sont sensibles. Il faut noter aussi que la demande d attributs elle aussi doit respecter ces critères de signature, d intégrité et de confidentialité. En effet, le fournisseur d attributs doit être sûr de l origine de la source qui requiert des attributs sur un utilisateur ; il peut être également important dans certains cas que la requête soit confidentielle car elle est directement liée à une politique de contrôle d accès spécifique. Par exemple, dans le cas Enquête Judiciaire, il pourra être considéré comme sensible l information que l accès au service nécessite l attribut habilitation de l utilisateur. Les spécifications SAML et WS-Security permettent de répondre à ces critères. Fournisseur d'attributs confidentialité, intégrité, signature Demande d'attributs Envoi des attributs demandés valide Utilisateur Figure 9 : gestion de l'échange des attributs module de contrôle d'accès 15/48
La validation de l utilisateur n est pas obligatoire, elle peut être évitée si le fournisseur d attributs assure un contrôle fort sur les requêtes d attributs (autorisation de diffusion de certains attributs à un ensemble limité de SPs). Ce contrôle fort peut être assuré par un module de négociation ou via des politiques de contrôle d accès fines appliquées aux attributs. 3.3.2. Fonctionnalités Voici à droite le schéma fonctionnel général du module de contrôle d accès 1. requête d accès à une ressource 2. opérations pour prendre une décision d autorisation d accès 2.1 authentifier l utilisateur (via un service d authentification externe) 2.2 récupérer les politiques d accès à la ressource demandée 2.3 récupérer les attributs de l utilisateur nécessaires à la décision 2.4 prendre une décision avec les informations recueillies 2.5 garder une trace de la décision 3. transmission de la requête (cas où la requête est acceptée) 4. opérations pour prendre une décision sur le flux sortant (optionnel, dans le cadre de la protection avant la diffusion de documents sensibles par exemple) 4.1 vérification du contexte 4.2 contrôle d accès supplémentaire (prise de décision en fonction d éléments recueillis) 5. transmission de la ressource Ce module protège donc les accès d un SP. Ce SP peut être de différentes formes, et c est pourquoi le module de contrôle d accès devra en pratique s adapter aux SPs. Cela signifie aussi que ce SP peut être un AP, et donc qu à ce moment on contrôle la diffusion des attributs des utilisateurs, qui sont une ressource comme une autre. Le module de contrôle d accès doit être placé en coupure devant les fournisseurs de service, afin de pouvoir traiter les requêtes, c est-à-dire vérifier qu elles sont légitimes (utilisateur authentifié ayant des privilèges suffisants par rapport à une action sur une ressource demandée). La contrainte est donc, au sein d un cercle de confiance, d être compatible avec les protocoles de SSO utilisés. Le module de contrôle d accès devra être compatible avec les profils de SSO, c està-dire être capable d interpréter correctement les messages SAML échangés entre les différentes autorités de cercles de confiance. 1 AuthN 2 AuthZ 3 Gestion accréditations Gestion de l'authentification : profils SSO SP1 + comptes fonctionnels Gestion de l'autorisation : contrôle d'accès sur le rôle module de contrôle d'accès SP2 + comptes fonctionnels Gestion des sessions ouvertes Gestion du traçage SP3 + comptes fonctionnels Figure 11 : fonctionnalités principales du module Figure 10 : fonctionnement haut niveau du module 16/48
Le module de contrôle d accès devra être capable de gérer 3 phases : l authentification, l autorisation (contrôle d accès via des règles sur des rôles) et la session avec le SP, ceci pour le compte de un ou plusieurs SP. 3.4. Standards pertinents pour répondre aux spécifications Les contraintes posées pour la résolution du cas d étude B2B imposent principalement que deux cercles de confiance puissent échanger des informations sur l authentification et les attributs d un utilisateur. Le premier standard qui s impose naturellement est SAML 2.0. Il définit des protocoles pour échanger ces informations-là, et son format de jetons a été adopté par les principaux groupes de travail de Fédération des Identités. Plus d informations générales sur SAML sont disponibles en annexe ; dans la suite de ce rapport nous détaillerons les éléments clés de SAML permettant de résoudre notre problématique de B2B. Le deuxième standard indispensable est XACML. Après un examen de l état de l art, on remarque que c est un standard permettant de définir des politiques de contrôle d accès fines, ainsi qu une architecture d utilisation de ces politiques, avec un lien fort avec SAML. Ce dernier permet de transporter les informations utiles à la prise de décision, lors de l examen d une requête d accès. De même, le lecteur intéressé peut trouver plus de détails sur les principes de XACML en annexe. SAML 2.0 profile of XACML et Core and hierarchical role based access control (RBAC) profile of XACML v2.0 sont deux specifications de OASIS particulièrement reliées à notre problématique. La première étend SAML pour pouvoir transporter des requêtes XACML, la deuxième propose une solution pour implémenter des politiques RBAC avec XACML. 3.5. Un rôle dynamique via les attributs Dans RBAC, en général, les rôles sont définis manuellement. Cela pose évidemment un certain nombre de problèmes d administration. Un concept commun entre les différents systèmes de fédération d identités est celui d attributs. Dans ce cadre-là on souhaiterait pouvoir prendre des décisions de contrôle d accès en s échangeant les attributs entre différents cercles de confiance, via des protocoles standard. Dans [8] est défini un modèle de politique de contrôle d accès basé sur les attributs (ABAC). Voici le modèle basique : (1) S, R et E sont des sujets, ressources et environnements respectivement ; (2) SA k (1 k K), RA m (1 m M), et EA n (1 n N) sont les attributs pré-définis pour les sujets, ressources et environnements respectivement ; (3) ATTR(s), ATTR(r) et ATTR(e) sont des relations d affectation d attributs pour un sujet s, une ressource r et un environnement e, respectivement : ATTR(s) SA 1 x SA 2 x x SA K ATTR(r) RA 1 x RA 2 x x RA M ATTR(e) EA 1 x EA 2 x x EA N (4) Dans sa forme la plus générale, une règle de politique décide si un sujet peut accéder à une ressource r dans un environnement e. C est une fonction booléenne sur les différents attributs ; si le résultat est évalué à true, l accès est autorisé, sinon l accès est refusé. Rule: can_access(s,r,e) f(attr(s), ATTR(r), ATTR(e)) 17/48
L intérêt de ce modèle par rapport à RBAC est qu il permet d utiliser implicitement la notion de rôle et de les affecter dynamiquement. L effet immédiat est que la complexification d une politique de sécurité entraîne avec RBAC une explosion du nombre de rôles, alors qu avec un modèle de contrôle d accès grain fin comme ABAC cela reste tout à fait gérable. Voici un exemple pour illustrer cela : Une organisation doit contrôler l accès à des documents selon la politique suivante. Sensibilité du document Habilitation du sujet S (secret) Habilité S C (confidentiel) Habilité C ou plus P (public) Tout le monde Dans le modèle RBAC, trois rôles sont créés : HabilitéSecret, HabilitéConfidentiel, HabilitéPublic. Trois règles exprimant les permissions accordées à chaque rôle sont également créées. On spécifie donc que les utilisateurs ayant le rôle HabilitéSecret peuvent voir les documents secrets, confidentiels et publics. Ceux ayant le rôle HabilitéConfidentiel peuvent voir les documents confidentiels et publics, enfin ceux ayant le rôle HabilitéPublic peuvent uniquement voir les documents publics. Enfin les sujets sont manuellement affectés à l un des trois rôles. Avec ABAC, il n est pas nécessaire d expliciter la notion de rôle, mais simplement d exprimer dans une règle les droits d accès des sujets s sur un document d avec un environnement e (ici non pris en compte) : Rule1: can_access(s,d,e) (Habilitation(s)=S ET Sensibilité(d) Є {P,C,S}) OU (Habilitation(s)=C ET Sensibilité(d) Є {P,C}) OU (Habilitation(s)=P ET Sensibilité(d) Є {P}) Pour exprimer des règles fines de contrôle d accès, plusieurs attributs sont souvent mis en jeu. C est là qu ABAC se montre plus adaptable que RBAC. Par exemple, si on veut exprimer que le document, en plus de sa qualification, appartient à un domaine particulier, le domaine A ou le domaine B et que seuls les sujets du département A (respectivement B) peuvent accéder aux documents du domaine A (respectivement B), on remarque que le nombre de rôles est multiplié par deux. Roles RBAC HabilitéSecretA HabilitéSecretB HabilitéConfidentielA HabilitéConfidentielB HabilitéPublicA HabilitéPublicB Permissions RBAC Peut voir un document secret du domaine A Peut voir un document secret du domaine B Peut voir un document confidentiel du domaine A Peut voir un document confidentiel du domaine B Peut voir un document public du domaine A Peut voir un document public du domaine B Avec ABAC il suffit d ajouter une règle à la première, et de combiner les deux : Rule2: can_access(s,d,e) (Domaine(d)=A ET Departement(s)=A) OU (Domaine(d)=B ET Departement(s)=B) Rule3: can_access(s,d,e) Rule1 ET Rule2 18/48
4. Une solution de contrôle d accès multi-cercles basée sur SAML et XACML 4.1. Format des attributs échangés 4.1.1. Les attributs SAML Un attribut SAML est principalement constitué d un nom Name et d une valeur AttributeValue. Par exemple : <saml:attribute Name="role"> <saml:attributevalue> enqueteur </saml:attributevalue> </saml:attribute> Il est possible qu un attribut ait plusieurs valeurs. On peut spécifier également le format de l attribut (par défaut l attribut est de format unspecified. Si un attribut est multi-valué, toutes ces valeurs doivent avoir le même format. Voici les formats disponibles : urn:oasis:names:tc:saml:2.0:attrname-format:unspecified urn:oasis:names:tc:saml:2.0:attrname-format:uri urn:oasis:names:tc:saml:2.0:attrname-format:basic Différents profils pour l utilisation de ces attributs sont définis dans la documentation SAML Profiles. <saml:attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="FirstName"> <saml:attributevalue xsi:type="xs:string">jean</saml:attributevalue> </saml:attribute> 4.1.2. Les attributs XACML Les attributs XACML diffèrent des attributs SAML. Dans une requête XACML on va trouver l élément <xacml-context:attribute>. Cet élément contient les attributs AttributeId et DataType, et optionnellement Issuer. Cet élément contient également un ou plusieurs éléments <xacml-context:attributevalue>. Voici un exemple : <xacml-context:attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name" Issuer="http://idp.gouv.fr"> <xacml-context:attributevalue>jean.dupont@gouv.fr</xacml-context:attributevalue> </xacml-context:attribute> A noter que dans une politique XACML, l évaluation des attributs se fait à l aide des éléments <AttributeDesignator> et <AttributeSelector>. 4.1.3. XACML Attribute profile Les attributs SAML générés en accord avec le profil XACML adapté peuvent être transformés automatiquement en attributs XACML à utiliser comme entrées pour des décisions d autorisation XACML. Voici un exemple qui illustre ce profil. <saml:attribute 19/48
xmlns:xacmlprof="urn:oasis:names:tc:saml:2.0:profiles:attribute:xacml" xmlns:ldapprof="urn:oasis:names:tc:saml:2.0:profiles:attribute:ldap" xacmlprof:datatype="http://www.w3.org/2001/xmlschema#string" ldapprof:encoding="ldap" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:2.5.4.42" FriendlyName="givenName"> <saml:attributevalue xsi:type="xs:string">jean</saml:attributevalue> </saml:attribute> 4.1.4. Cas 1 : rôle sans attributs sensibles Un SP a besoin de savoir si un utilisateur a le rôle adéquat pour lui donner l accès au service. Pour le SP, ce rôle correspond à une liste d attributs qu il a définie et peu donc demander à un ou plusieurs fournisseurs d attributs. Dans les cas multi CoTs, cette politique pour définir un rôle est établie suite à des accords définissant les responsabilités de chaque partie. Par exemple, dans le cas Enquête Judiciaire : Au niveau SP Enquête Judiciaire Politique d accès : Les utilisateurs ayant le rôle enquêteur peuvent accéder à la ressource en lecture Rôle enquêteur : (qualification=agent de police judiciaire OU qualification=officier de police judiciaire) ET habilitation=oui Au niveau IDP/AP Police Nationale Les différents attributs sont stockés sur l IDP/AP. Scénario : Jean Dupont fait une demande d accès au SP Enquête Judiciaire SP AP : Donne-moi les attributs qualification et habilitation de Jean Dupont AP SP : qualification=agent de police judiciaire ET habilitation=oui SP User : Accès autorisé Dans ce cas-là, le rôle enquêteur n est pas explicitement défini, le modèle de contrôle d accès utilisé est ABAC. Simplement, la Police aura préalablement déclaré à l opérateur Télécom qu elle mettait à la disposition du service Enquête Judiciaire ces attributs, et qu une personne habilitée par la loi à accéder à ces informations était parfaitement identifiée via ces attributs. 4.1.5. Cas 2 : rôle avec attributs sensibles Un SP a besoin de savoir si un utilisateur a le rôle adéquat pour lui donner l accès au service, mais ne connaît pas quels attributs l AP utilise pour définir ce rôle. Le SP doit donc demander au fournisseur d attributs si l utilisateur a le rôle adéquat, l AP répondra simplement par un booléen, et ainsi ne divulguera pas les attributs sensibles qu il a regardé pour déterminer si l utilisateur avait le rôle ou non. Par exemple, dans le cas Enquête Judiciaire : Au niveau SP Politique d accès : Les utilisateurs ayant le rôle enquêteur (sur le domaine Police Nationale) peuvent accéder à la ressource en lecture Au niveau AP Les différents attributs sont stockés. 20/48