Contrôle d accès basé sur les rôles et négociation dans un environnement multi cercles de confiance

Transcription

1 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

2 RESUME INTRODUCTION CONTEXTE DU TRAVAIL PROJET FC² ENQUETE JUDICIAIRE : EXEMPLE D APPLICATION GENERALITES SUR LA FEDERATION DES IDENTITES CONTROLE D ACCES ENTRE CERCLES DE CONFIANCE L EXISTANT ET SES LIMITES Problème 1 : Gestion des authentifications et du contrôle d accès centralisé Problème 2 : Le contrôle d accès basé sur les rôles Problème 3 : L échange des rôles des utilisateurs Problème 4 : La transmission de l authentification OBJECTIFS SPECIFICATIONS Exigences Fonctionnalités STANDARDS PERTINENTS POUR REPONDRE AUX SPECIFICATIONS UN ROLE DYNAMIQUE VIA LES ATTRIBUTS UNE SOLUTION DE CONTROLE D ACCES MULTI-CERCLES BASEE SUR SAML ET XACML FORMAT DES ATTRIBUTS ECHANGES Les attributs SAML Les attributs XACML XACML Attribute profile Cas 1 : rôle sans attributs sensibles Cas 2 : rôle avec attributs sensibles SOLUTION PROPOSEE POUR LE CONTROLE D ACCES Architecture globale Fédération pour la phase d authentification Phase d autorisation Architecture détaillée côté SP WSC Architecture détaillée côté IDP WSP XACML en détail dans le cas Enquête Judiciaire DEPLOIEMENTS POSSIBLES Cas 1 un module intégralement externe Cas 2 des agents PEP distribués sur les SP avec un PDP central partagé Cas 3 des agents PEP distribués sur les SP avec plusieurs PDP distribués Cas 4 des agents PEP+PDP localisés sur les SP UNE SOLUTION INNOVANTE BASEE SUR LA NEGOCIATION DE POLITIQUES LES INTERETS DE LA NEGOCIATION L ARCHITECTURE ET LES ECHANGES GENERAUX EXEMPLE THEORIQUE DE NEGOCIATION AVEC TRUSTBUILDER COMPARAISON DES DEUX SOLUTIONS AXES FUTURS DE TRAVAIL DEPLOIEMENT POUR PREUVE DE CONCEPT LIMITES L administration des politiques de sécurité Utilisation d un rôle entre différents cercles de confiance CONCLUSION /48

3 GLOSSAIRE BIBLIOGRAPHIE TABLE DES FIGURES ANNEXES FEDERATION DES IDENTITES : SAML 2.0 ET LIBERTY ALLIANCE L AUTORISATION : LE STANDARD XACML Description de XACML Un exemple simple Le profil RBAC pour XACML /48

4 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

5 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

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

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

8 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

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

10 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é 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 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

11 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 Spécifications 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

12 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

13 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

14 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

15 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 protected] 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

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

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

18 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

19 4. Une solution de contrôle d accès multi-cercles basée sur SAML et XACML 4.1. Format des attributs échangés 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> 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=" <xacml-context:attributevalue>[email protected]</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> 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

20 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=" ldapprof:encoding="ldap" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid: " FriendlyName="givenName"> <saml:attributevalue xsi:type="xs:string">jean</saml:attributevalue> </saml:attribute> 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 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

21 Rôle enquêteur : (qualification=agent de police judiciaire OU qualification=officier de police judiciaire) ET habilitation=oui Scénario : SP AP : Dis-moi si Jean Dupont a le rôle enquêteur Côté AP on vérifie si Jean Dupont a les attributs qui lui permettent d avoir le rôle enquêteur AP SP : Oui (Jean Dupont a le rôle enquêteur) On applique la permission liée à ce rôle SP User : Accès autorisé Dans ce cas-là, le contrôle d accès est réparti entre les deux domaines, le domaine gestionnaire de l identité et des rôles de ses utilisateurs, et le domaine fournisseur du service. Des accords préalables doivent avoir été passés. C est donc globalement le modèle RBAC qui est utilisé côté SP pour donner des droits d accès à l utilisateur. Côté IDP, on utilise les attributs pour donner dynamiquement un rôle à un utilisateur, en fonction de ses attributs Solution proposée pour le contrôle d accès Architecture globale Nous nous limitons à un cas où les échanges se font entre deux cercles de confiance. En effet, nous nous plaçons dans le cas où un premier cercle connaît toute l information utile sur l utilisateur, et où le second cercle héberge un service dont il gère le contrôle d accès. Les attributs de l utilisateur sur lesquels est construit son rôle sont évalués comme sensibles et ne seront donc pas échangés entre les deux cercles. Seul son rôle enquêteur peut être demandé par le cercle partenaire. IDP1 IDP2 CoT 2 CoT 1 Role Assignment Policies Enquêteur Policies & Role Permission Policies ACM1 WSP ACM2 WSC AP1 SP2 Figure 12 : vue globale sur les éléments principaux pour un contrôle d'accès réparti Fédération pour la phase d authentification La phase d authentification va consister en la création de comptes temporaires via un Transient Identifier sur l IDP et le SP du CoT 2. C est la solution pour que l utilisateur du CoT 1 puisse obtenir un jeton valide dans le CoT 2, sans la création préalable d un compte personnel sur l IDP du CoT 2. 21/48

22 Table de fédération Local ID SP LinkedID id1 IDP2 id2 Table de fédération Local ID SP LinkedID id2 IDP1 id1 IDP1 AP IDP2 CoT 2 3 CoT 1 UA module de contrôle d'accès (ACM) 5 Table de fédération Local ID IDP LinkedID id3 IDP2 id2 SP2 Figure 13 : fédération en inter-cot 1. L enquêteur du CoT Gouvernemental (CoT 1) fait une requête au SP 2 du CoT Telecom (CoT 2). 2. Cette requête est interceptée par l ACM qui redirige l utilisateur vers l IDP 2 avec un <Authnrequest> pour qu il fournisse un jeton d authentification. 3. L IDP 2 redirige l utilisateur vers son IDP, l IDP 1, en réclamant un jeton d authentification (<AuthnRequest> avec un Transient Identifier). Soit cette redirection est automatique (détection de l adresse de l IDP à l aide d un cookie de domaine commun), soit l utilisateur aura spécifié son IDP dans une liste. L IDP 1 fournit un jeton avec un Transient Identifier id1 (après avoir authentifié l utilisateur de son CoT s il ne l avait pas encore fait) 4. L IDP 2 crée un compte avec comme LocalId un aléa id2 et le fédère avec l id1 de l IDP1. Il redirige l utilisateur vers le SP2 avec un <Response> et le Transient Pseudonym id2. 5. Le module transmet la requête au SP 2 qui crée un compte avec comme LocalId un aléa id3 et le fédère avec l id2 de l IDP2. L utilisateur est alors authentifié sur le SP2 en tant que id3. Reste la phase d autorisation pour contrôler que l utilisateur a les droits nécessaires pour accéder à la ressource demandée Phase d autorisation Le scénario «pull credentials» La figure 14 spécifie l architecture globale pour le contrôle d accès basé sur les rôles entre cercles de confiance, dans un mode «pull credentials». 22/48

23 IDP1 IDP2 SSO 3 CoT 1 AuthN 1 Enquêteur AP1 Role Assignment Policies ACM1 WSP 2 requête réponse 5 Role Enqueteur? 4 SSO 3 ACM2 WSC Role Permission Policies SP2 CoT 2 Figure 14 : contrôle d'accès réparti «pull credentials» entre deux CoTs 1. Un enquêteur s authentifie auprès de l IDP de son cercle de confiance, le CoT 1. Il n a pas de compte sur l IDP de l autre cercle. 2. L enquêteur fait une requête pour accéder au service Enquête Judiciaire situé sur le CoT La requête est interceptée par le module ACM2 qui demande à l utilisateur de s authentifier. Il le redirige donc vers l IDP2, et ce dernier récupère auprès de l IDP1 un jeton d authentification pour l enquêteur. 4. L ACM2 analyse les politiques protégeant l accès au SP2, et détermine qu il doit demander le rôle de l utilisateur auprès de l AP du CoT 1. Il envoie donc cette requête à l AP1. 5. La requête est interceptée par l ACM1 qui analyse, via ses politiques d affectation de rôle, si l utilisateur a le rôle enquêteur, et envoie sa réponse à l ACM2. Avec la connaissance de cette information supplémentaire, l ACM2 peut désormais prendre une décision d autorisation en fonction des permissions du rôle de l utilisateur. CoT Gouvernemental CoT Telecom Enquêteur REA IDP/AP PEP PDP PAP SP requête d'accès au SP avec jeton SAML AuthN requête HasPrivilegeOfRole enqueteur XACMLAuthZ DecisionQuery XACMLPolicy Query XACMLPolicy Statement Attribute Query Attribute Response Response Result Decision Permit XACMLAuthZ DecisionState ment accès à la ressource requête originale Figure 15 : diagramme de séquence «pull credentials» pour l'autorisation d'accès entre deux CoTs 23/48

24 Le scénario «push credentials» IDP1 IDP2 validation jeton 4 CoT 1 AuthN AP1 Role Assignment Policies ACM1 WSP validation jeton 4 Role Permission Policies CoT 2 1 Enquêteur 2 récupération du role et du jeton 3 requête + jeton AuthN + role 5 ACM2 WSC SP2 Figure 16 : contrôle d'accès réparti «push credentials» entre deux CoTs 1. Un enquêteur s authentifie auprès de l IDP de son cercle de confiance, le CoT 1. Il n a pas de compte sur l IDP de l autre cercle. 2. L enquêteur clique sur un lien vers le service Enquête Judiciaire proposé sur la page portail de son IDP. Ce lien le renvoie dans un premier temps auprès d un service qui va intégrer à sa requête un jeton d authentification et son rôle enquêteur (après vérification qu il a bien le droit de jouer ce rôle) 3. La nouvelle requête de l enquêteur est alors redirigé vers le service Enquête Judiciaire. 4. La requête est alors interceptée par l ACM2, qui vérifie la validité du jeton d authentification. 5. L ACM2 vérifie alors si le rôle de l utilisateur lui donne la permission d accéder au service. CoT Gouvernemental CoT Telecom Enquêteur REA PEP SSO service IDP/AP PEP PDP PAP SP requête d'accès au SP (lien sur IDP) après AuthN requête HasPrivilegeOf Role enqueteur AttributeQuery AttributeResponse Permit redirection + jeton AuthN requête + jeton + role accès à la ressource XACMLAuthZ DecisionQuery XACMLAuthZ DecisionState ment XACMLPolicy Query XACMLPolicy Statement requête originale Figure 17 : diagramme de séquence «push credentials» pour l'autorisation d'accès entre deux CoTs 24/48

25 Architecture détaillée côté SP WSC Composants internes du module de contrôle d accès Les composants principaux du module d accès sont un PEP, un PDP et un PAP. 1. Le PEP reçoit une requête d un utilisateur attributs qui veut accéder à un service rendu par un SP sous le contrôle du module. L utilisateur politiques 3 4 doit être authentifié, c est-à-dire avoir un jeton d authentification valide ; 2. Le PEP envoie une requête au PDP 6 PDP AP contenant des informations sur le sujet 1 PEP 9 (connues via l analyse du jeton 9 IDP d authentification et de la requête initiale) et sur la ressource demandée ; 8 3. Le PDP récupère les politiques de contrôle d accès concernant la ressource demandée par l utilisateur auprès du PAP ; SP SP SP 4. Le PDP récupère éventuellement les informations contextuelles nécessaires à la prise de décision auprès du PIP (attributs supplémentaires concernant le sujet, la ressource, l environnement) ; 5. Le PDP récupère le rôle de l utilisateur auprès de l AP ; le consentement de l utilisateur peut être demandé ; 6. Le PDP analyse l ensemble des informations et prend sa décision ; 7. Le PDP envoie au PEP sa décision ; 8. Le PEP garde un contexte associé à l utilisateur, l authentifie de manière transparente auprès du SP sur un compte avec les privilèges liés à son rôle, et envoie la requête initiale de l utilisateur au SP ; 9. Le SP donne des droits d accès grain fin à l utilisateur suivant son compte, et envoie la page demandée si l utilisateur a les privilèges suffisants. PAP PIP Les différentes politiques XACML Les politiques XACML disponibles côté SP Telecom sont référencés de la manière suivante : un Role <PolicySet> par rôle avec une référence vers un Role Permission <PolicySet>. L élément Target du Role <PolicySet> permet au PDP de trier les politiques et de n évaluer que celles qui sont applicables au sujet qui fait la requête. Le PolicySetIdReference d un Role Permission <PolicySet> permet de hiérarchiser les rôles, c est-à-dire de faire hériter à des rôles seniors les permissions de rôles juniors. Role <PolicySet> <Target> Tous les sujets ayant l'attribut role enqueteur <PolicySetIdReference> Enqueteur Permission <PolicySet> <Rule> Permit/Deny pour une action sur une ressource <PolicySetIdReference> héritage des permissions de roles juniors éventuels Figure 18 : politiques XACML pour les permissions RBAC Architecture détaillée côté IDP WSP Composant contrôlant la diffusion des attributs (Attribute Release Policy) Shibboleth propose de définir des Attribute Release Policies pour pouvoir contrôler la diffusion des attributs de l utilisateur. 25/48

26 Dans l exemple suivant on autorise la diffusion de l attribut edupersonaffiliation à n importe qui. <?xml version="1.0" encoding="utf-8"?> <AttributeReleasePolicy xmlns="urn:mace:shibboleth:arp:1.0" xmlns:xsi=" xsi:schemalocation="urn:mace:shibboleth:arp:1.0 shibboleth-arp-1.0.xsd"> <Rule> <Description/> <Target> <AnyTarget/> </Target> <Attribute name="urn:example:attribute-def:edupersonaffiliation"> <AnyValue release="permit"/> </Attribute> </Rule> </AttributeReleasePolicy> On souhaiterait le faire en utilisant le standard XACML et en considérant chaque attribut comme une ressource particulière. On exploiterait principalement la signature de l émetteur de l assertion AttributeQuery. L objectif de ce contrôle d accès est de protéger la diffusion des attributs de l utilisateur, notamment ceux considérés comme sensibles par le fournisseur d attributs, et éviter une transmission suite à une validation involontaire de l utilisateur. Le fonctionnement est semblable à du contrôle d accès où la ressource demandée est un attribut. Ce contrôle d accès peut être intéressant dans un environnement multi CoTs : un AP accepte par exemple de transmettre des attributs aux SP de son cercle de confiance mais pas aux SP hors de son cercle. Il est intéressant de pouvoir gérer des exceptions afin d échanger des informations de rôles entre plusieurs cercles. Pour cela, la même architecture de module peut être exploitée ; voici ci-dessous les échanges entre les éléments assurant le contrôle d accès aux attributs de l AP. PAP PIP politiques 4 PDP 4 REA Role Assignment Policies attributs Requester 1 7 PEP 2 6 AP Figure 19 : éléments mettant en oeuvre un contrôle d'accès sur les ressources d'un AP 1. Une entité réclame des attributs concernant un utilisateur. Elle envoie une requête à l AP contenant l identifiant de l utilisateur, son contexte d authentification et le service qui a besoin de ces attributs ; 2. Le PEP intercepte la requête et la reformule pour le PDP ; 3. Le PEP envoie cette requête au PDP ; 4. Le PDP récupère les politiques protégeant l accès aux attributs des utilisateurs et les informations contextuelles nécessaires ; 5. Le PDP analyse l ensemble, prend sa décision et la communique au PEP ; 6. Si la décision est positive, le PEP réclame les attributs à l AP, qui lui envoie ; si l attribut demandé est un rôle, la requête est faite au REA (Role Enablement Authority) ; 7. Le PEP transmet les attributs à l entité qui les lui a demandés initialement. 26/48

27 Composant assurant la constitution d un rôle basé sur les attributs d un utilisateur Dans les spécifications Core and hierarchical role based access control (RBAC) profile of XACML v2.0 est fait mention d une autorité dédiée à l affectation de rôles aux utilisateurs, le REA (Role Enablement Authority). Dans le cas 2 qui nous intéresse, où les attributs de l utilisateur permettant de lui donner le rôle d enquêteur sont considérés sensibles, cette autorité est chargée de répondre si un utilisateur a le rôle R ou pas. Il existe deux possibilités pour affecter un rôle à un utilisateur : 1. l affectation manuelle via l identifiant des utilisateurs Très simplement, on peut spécifier dans une politique que Jean Dupont et Marcel Rouletabille peuvent jouer le rôle enquêteur. <?xml version="1.0" encoding="utf-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" PolicyId="Role:enqueteur:assignment:policy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:2.0:rule-combining-algorithm:permit-overrides"> <Rule RuleID="enqueteur:role:requirements" Effect="Permit"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType=" Jean Dupont </AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType=" Issuer=" </SubjectMatch> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType=" Marcel Rouletabille </AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType=" Issuer=" </SubjectMatch> </Subject> </Subjects> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType=" urn:ipdgouvfr:roles:enqueteur </AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType=" Issuer=" </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType=" urn:oasis:names:tc:xacml:2.0:actions:enablerole </AttributeValue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType=" Issuer=" 27/48

28 </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy> 2. l affectation automatique via les attributs La politique suivante exprime que les sujets ayant pour attributs (qualification=agent de police judiciaire OU qualification=officier de police judiciaire) ET habilitation=true sont autorisés à jouer le rôle enqueteur. <?xml version="1.0" encoding="utf-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" PolicyId="Role:enqueteur:assignment:policy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:2.0:rule-combining-algorithm:permit-overrides"> <Rule RuleID="enqueteur:role:requirements" Effect="Permit"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:and"> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:or"> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType=" Agent de police judiciaire </AttributeValue> <SubjectAttributeDesignator AttributeId="qualification" DataType=" Issuer=" </SubjectMatch> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType=" Officier de police judiciaire </AttributeValue> <SubjectAttributeDesignator AttributeId="qualification" DataType=" Issuer=" </SubjectMatch> </SubjectMatch> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType=" true </AttributeValue> <SubjectAttributeDesignator AttributeId="habilitation" DataType=" Issuer=" </SubjectMatch> </SubjectMatch> </Subject> </Subjects> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType=" urn:ipdgouvfr:roles:enqueteur </AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType=" Issuer=" </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType=" urn:oasis:names:tc:xacml:2.0:actions:enablerole </AttributeValue> 28/48

29 <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType=" Issuer=" </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy> XACML en détail dans le cas Enquête Judiciaire L utilisateur du cercle gouvernemental clique sur un lien présent sur le portail de son IDP, pour accéder au service Enquête Judiciaire. Le fait de cliquer sur ce lien enclenche une procédure particulière avec pour objectif d envoyer au service du partenaire une requête avec un jeton contenant le contexte de l authentification de l utilisateur et son rôle enquêteur. Une requête est ainsi générée au PDP : <?xml version="1.0" encoding="utf-8"?> <XACMLAuthzDecisionQuery> <Request> <Subject> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType=" Issuer=" <AttributeValue>Jean Dupont</AttributeValue> </Attribute> </Subject> <Resource> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType=" Issuer=" <AttributeValue>urn:ipdgouvfr:roles:enqueteur</AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType=" rivilegesofrole</attributevalue> </Attribute> </Action> </Request> </XACMLAuthzDecisionQuery> Le PEP gouvernemental vérifie dans sa politique d affectation des rôles si l utilisateur Jean Dupont peut jouer le rôle enquêteur (a-t-il les attributs spécifiés dans la Role Assignment Policy?). Si oui, il envoie la réponse suivante : <samlp:response> <Response xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi=" xsi:schemalocation="urn:oasis:names:tc:xacml:2.0:context:schema:os"> <Result> <Decision>Permit</Decision> </Result> </Response> </XACMLAuthzDecisionStatement> Une requête adaptée est alors formulée par le service SSO. Comme on ne souhaite pas transmettre le nom de l utilisateur et que ce dernier n a pas de compte sur le cercle Telecom, on va utiliser le «transient pseudonym» défini par SAML 2.0. C est un identifiant anonyme qui permet de faire de la fédération temporaire. Voici un exemple de requête : <samlp:response xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" 29/48

30 ID="identifier_1" Version="2.0" IssueInstant=" T09:22:05Z" Destination=" <saml:issuer> <saml:assertion xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" ID="identifier_2" Version="2.0" IssueInstant=" T09:22:05Z"> <saml:issuer> <ds:signature xmlns:ds=" <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"> </saml:nameid> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata InResponseTo="identifier_1" Recipient=" NotOnOrAfter=" T09:27:05Z"/> </saml:subjectconfirmation> </saml:subject> <saml:authnstatement AuthnInstant=" T09:22:00Z" SessionIndex="identifier_2"> <saml:authncontext> <saml:authncontextclassref> urn:oasis:names:tc:saml:2.0:ac:classes:passwordprotectedtransport </saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement AuthnInstant=" T09:22:00Z" SessionIndex="identifier_2"> <Attribute Name="role" NameFormat=" <AttributeValue>enqueteur</AttributeValue> </Attribute> </saml:attributestatement> </saml:assertion> </samlp:response> Via un HTTP POST automatique, ce jeton est transmis au SP Enquête Judiciaire. Le PEP devant ce SP va alors transformer cette requête en requête XACML, destinée au PDP. Le contrôle d accès est alors réalisé classiquement Déploiements possibles A partir d une administration de politiques externalisée et centralisée, le but étant d avoir des politiques cohérentes sur un ensemble de services, on peut concevoir plusieurs déploiements possibles, la liste étant non exhaustive : 1. un module intégralement externe 2. des agents PEP distribués sur les SP avec un PDP central partagé 3. des agents PEP distribués sur les SP avec plusieurs PDP distribués 4. des agents PEP+PDP localisés sur les SP On note deux différences majeures parmi ces déploiements : un PEP central pour plusieurs SPs implique que TOUTE la gestion des droits d accès se fait à son niveau, et une fois les vérifications faites, le PEP transmet au SP les requêtes HTTP directement. 30/48

31 des agents PEP sur chaque SP : cette méthode est instrusive mais il n y a pas de rupture de la chaîne de liaison. Pour certaines applications à la gestion fine des droits d accès (base de données par exemple), vouloir externaliser complètement cette gestion des droits d accès serait absurde et complexe. Le point commun de tous ces déploiements est la présence d un point d administration de politiques central. Cela signifie que depuis ce point d administration central, l ensemble des politiques gouvernant l accès de tous les SPs sont visibles. Dans la réalité, les politiques ne sont pas nécessairement stockées au même endroit. Au final, le type de déploiement d un contrôle d accès décentralisé dépendra de l architecture réseau existante, l objectif étant d optimiser au maximum les temps de prise de décision et la facilité d administration Cas 1 un module intégralement externe Description du fonctionnement A une requête http d un utilisateur et en l absence d un PAP contexte de sécurité (pas de session ouverte), le PEP va demander une assertion d authentification auprès de l IDP, puis, en fonction de ses politiques concernant la ressource demandée, un certain nombre d attributs. En fonction de la décision prise pas le PDP, le PEP laissera ou non la requête passée. Avantages : PDP PEP PIP L ajout d un service demande simplement l ajout de politiques dans le PAP. Le PEP devra simplement journaliser les échanges d informations de session entre chaque SP et l utilisateur. Inconvénients : Les SPs doivent communiquer avec le PEP, notamment sur SP server SP server les sessions des utilisateurs authentifiés et donc le PEP doit avoir connaissance de ces sessions (début de la session, temps d expiration, fin de la session). Le PEP doit gérer l ensemble des requêtes vers tous les services (goulot d étranglement). Il y a une rupture de la chaîne de liaison entre chaque SP et le PEP Cas 2 des agents PEP distribués sur les SP avec un PDP central partagé Description du fonctionnement Dans cette architecture, on donne à chaque SP un agent de contrôle d accès PEP, qui protège l accès aux ressources de son SP. Pour traiter chaque requête il se réfère à un PDP externe, centre décisionnel commun à plusieurs SP. Ce PDP peut demander des politiques gérées par le un PAP, et de l information à un PIP. Pour accélérer le traitement des requêtes, le PEP peut garder en cache des décisions, tout comme le PDP peut également garder en cache des politiques et des informations. PEP SP server PAP PDP PEP PIP SP server 31/48

32 Cas 3 des agents PEP distribués sur les SP avec plusieurs PDP distribués Description du fonctionnement Dans cet exemple de déploiement, on a plusieurs PDP distribués. Pour accélérer le traitement des requêtes, le PEP peut garder en cache des décisions, tout comme le PDP peut également garder en cache des politiques et des informations. PIP PEP SP PDP PAP PEP SP PDP PIP PEP SP L intérêt d avoir des PDP distribués est que ces PDP peuvent être dédiés à un certain type de SPs, pour accélérer leur décision. server server server Cas 4 des agents PEP+PDP localisés sur les SP PAP Ici chaque SP à un agent PEP plus un module décisionnel personnel. Les politiques sont centralisées via un PAP. Les PDPs peuvent mettre en cache des politiques pour accélérer le traitement des requêtes. PEP PDP PEP PDP SP SP server server 32/48

33 5. Une solution innovante basée sur la négociation de politiques 5.1. Les intérêts de la négociation La négociation de politiques de sécurité permet à deux entités gouvernées par des politiques hétérogènes d arriver à une relation de confiance. Le principe, basé sur un modèle client/serveur classique, est simple. Un client souhaite accéder à une ressource protégée disponible sur un serveur. Pour que le serveur donne l accès au client à cette ressource, il est nécessaire qu une relation de confiance existe entre les deux partis. Cette relation de confiance va être établie avec un échange de politiques protégeant les credentials de chaque côté. Un credential est une affirmation qui peut être signée. C est par exemple un certificat X509 ou un attribut SAML. Le modèle est donc le suivant : Figure 20 : protocole général de négociation La phase d échange de politiques est intéressante car elle précise quels credentials doivent être échangés pour que la négociation aboutisse. Cette négociation a un intérêt particulier si les modules de négociation client et serveur sont capables d interpréter différents langages d expression de politique. De plus, dans le cadre d échanges B2B par exemple, une phase de négociation permettra de protéger finement les attributs de l utilisateur. Pour plus d informations sur l état de l art de la négociation de politiques de sécurité, le lecteur peut se référer à la bibliographie rédigée avant le stage L architecture et les échanges généraux Pour répondre aux spécifications (l utilisateur utilise un simple navigateur), ce n est pas l enquêteur qui va négocier directement mais il va déléguer la négociation à un module sur son CoT. Ce module est chargé de protéger la diffusion des ressources sensibles que sont les attributs des utilisateurs. Rappelons que nous nous plaçons dans un cercle de confiance (type Liberty Alliance) et que chaque utilisateur de ce cercle est caractérisé par ses attributs, disponible par l intermédiaire d un fournisseur d attributs. 33/48

34 IDP1 IDP2 CoT 2 Politiques Enquêteur Politiques Négociation Négociation CoT 1 PEP PEP AP1 SP2 Figure 21 : architecture générale dans le cas 2 CoTs Voici comment résoudre le cas Enquête Judiciaire en protégeant le SP par un module de négociation : 1. Un enquêteur fait une demande d accès au SP2 qui est interceptée par le PEP du CoT2. Si l utilisateur n est pas authentifié, le PEP redirige l utilisateur vers l IDP1 (découverte automatique via un Common Domain Cookie ou choix dans une liste). 2. L IDP1 redirige l utilisateur vers le SP2 avec un jeton d authentification Dans ce jeton doit se trouver l adresse du module de négociation Le PEP envoie demande une décision d accès au module de négociation 2 4. Le module de négociation 2 envoie sa politique d accès au module de négociation 1 «Pour accéder au service, je veux un attribut rôle avec la valeur enquêteur signé par le CoT1» 5. Le module de négociation 1 envoie sa politique pour diffuser les credentials demandés «Pour envoyer l attribut rôle avec la valeur enquêteur, j ai besoin de la preuve que le SP appartient bien au cercle Telecom» 6. Le module de négociation 2 envoie les credentials exigés, par exemple un certificat prouvant qu il appartient bien au cercle Telecom ou via une assertion SAML signée. 7. Le module de négociation récupère le rôle enquêteur auprès de l AP et l envoie via une assertion SAML signée. 8. La politique est satisfaite, le module de négociation 2 donne accès à la ressource. CoT Gouvernemental CoT Telecom Enquêteur Négo 1 IDP/AP PEP Négo 2 SP AuthN redirection requête d'accès au SP redirection requête d'accès au SP + jeton demande d'attributs politique d'accès politique de diffusion des attributs envoi de credentials transmission requête attributs envoi des attributs accès à la ressource décision requête originale Figure 22 : diagramme de séquence pour la négociation 34/48

35 Dans des cas où la ressource demandée est particulièrement sensible, il est possible que la négociation exige plusieurs tours d échanges de politiques et de credentials. C est là que le processus de négociation peut se révéler particulièrement utile. Voici un exemple avec le schéma ci-dessous : CoT Gouvernemental CoT Telecom Négo 1 Négo 2 Enquêteur politique_enqueteur : credential service judiciaire veut accéder au SP Enquête Judiciaire envoi politique_sp envoi politique_enqueteur politique_sp : credential role=enqueteur certifié par la police envoi politique_servicejud envoi credential employé police politique_servicejud : credential employé police envoi credential service judiciaire envoi credential role=enqueteur accès autorisé Figure 23 : un exemple de négociation pour le cas Enquête Judiciaire L avantage de la solution est de pouvoir échanger des attributs sensibles petit à petit, au fur et à mesure que le niveau de confiance entre les deux partis monte. Ici sur la figure ci-dessus, le credential prouvant que le sujet est un employé de la Police Nationale n est pas considéré comme sensible par le CoT Gouvernemental qui ne pose pas de condition particulière pour le diffuser. Cependant la diffusion de son rôle enquêteur est protégée par la politique «politique_enqueteur» qui spécifie qu un credential «service judiciaire» (qui est par exemple un attribut de la ressource demandée) est requis Exemple théorique de négociation avec TrustBuilder TrustBuilder [14] est un système de négociation de politiques de sécurité qui a été développé par ISRL (Internet Security Research Lab) à BYU (Brigham Young University). A l'heure actuelle, il s'agit de la proposition la plus avancée. Le système a été implémenté en Java et divisé en différents modules afin de maximiser les propriétés d'interopérabilité et de compatibilité (ajout possible de plugins pour supporter de nouveaux types de certificats ou de langages de politiques). Le client et le serveur, lors de la négociation, utilisent chacun un agent TrustBuilder qui va gérer le processus d'échange des politiques et certificats automatiquement. Par rapport à l exemple précédent il s agit donc du module de négociation 1 et du module de négociation 2. La négociation est symétrique, les deux modules ont un fonctionnement similaire. L élément clé de chaque module est le «compliance checker» : c est l élément chargé de déterminer si les Figure 24 : compliance checker 35/48

36 credentials disponibles localement peuvent répondre positivement à la politique reçue. Par exemple, si Bob reçoit la politique d Alice (figure ci-dessus), le compliance checker est chargé d évaluer cette politique et d estimer s il peut y répondre. Si l envoi de credentials est soumis à une exigence particulière, Bob envoie cette exigence à Alice sous la forme d une politique. Voici précisément comment fonctionnerait l exemple de la figure 28, si Jean Dupont demande l accès au service Enquête Judiciaire : Credentials et politiques côté police (client) Nom du credential Sujet associé valeur signataire Politique appliquée role Jean Dupont enqueteur Police Nationale Politique_enqueteur Organisation Jean Dupont Police nationale Police Nationale Aucune Credentials et politiques côté télécom (serveur) Nom du credential valeur signataire Politique appliquée Service Enquete judiciaire Telecom Politique_servicejud ressource Service Enquete Judiciaire Politique appliquée Politique_SP Scénario 1. A la réception de la demande d accès, le module de négociation 2 envoie la politique liée à la ressource. 2. Le compliance checker du module 1 analyse la politique : le credential role=enqueteur de Jean Dupont signé par la Police est demandé. Ce credential est disponible mais il est protégé par une politique. Le module 1 envoie la politique_enqueteur au module Le module 2 analyse politique_enqueteur. Le credential Service Enquete Judiciaire signé par Telecom est requis. Ce credential est disponible mais soumis à une politique, politique_servicejud. Cette politique est envoyée. 4. Le module 1 analyse politique_servicejud. Le credential de Jean Dupont Organisation Police Nationale, signé par la Police Nationale, est requis. Celui-ci est envoyé car non soumis à une politique particulière. 5. Les conditions de Politique_servicejud sont remplies : le credential Service Enquete Judiciaire est envoyé. 6. Les conditions de Politique_enqueteur sont remplies : le role enqueteur de Jean Dupont est envoyé au module Les conditions politique_sp sont alors remplies et l accès au service est autorisé. 36/48

37 6. Comparaison des deux solutions Les deux solutions présentent une architecture assez similaire. Chacune permet de prendre une décision de contrôle d accès après un échange de credentials ; ce sont deux solutions de gestion d autorisation. Cette architecture est la suivante : un cercle «client» qui détient des «preuves» sur l identité de l utilisateur qui fait la demande d accès, et un cercle «serveur» qui propose un service et le protège à l aide d une politique de sécurité. Le cercle «serveur» dispose lui aussi de «preuves» sur son service. La principale différence est que dans le cas négociation, l entité émettrice des attributs de l utilisateur les protège via un processus de négociation, c est-à-dire que la diffusion sera autorisée si un compromis est atteint. Dans l autre cas, il n y a pas d échange de politiques, les credentials nécessaires à la prise de décision sont directement envoyés. Une négociation préalable peut apporter plus de souplesse à ces échanges. L approche de négociation apparaît un peu trop élaborée pour résoudre le «simple» exemple de l enquête judiciaire, où l environnement de fédération d identités facilite le transfert des attributs. Dans les spécifications Liberty Alliance par exemple, chaque cercle dispose d entités responsables de ces échanges. L AP (Attribute Provider) gère les caractéristiques de chaque identité du cercle de confiance, et un DS (Discovery Service) est chargé de faciliter la mise en relation de l utilisateur avec les services, éventuellement hors du cercle de confiance. Ainsi il est possible, comme évoqué dans la première solution, de résoudre la problématique en s appuyant sur SAML pour transporter les informations utiles entre les cercles (jeton d authentification et attributs). Pour résoudre un certain nombre de problématiques plus complexes, la négociation de politiques de sécurité apparaît néanmoins très pertinente. Un échange progressif de politiques et de credentials pour arriver à un compromis est un concept intéressant pour les organisations, car cela permet d échanger des informations sensibles après la réception de garanties nécessaires et de manière automatique. L exemple donné dans la deuxième solution est un aperçu de ce concept. La solution de négociation peut être déployée comme un module supplémentaire, interrogeable dans des cas précis par un module de contrôle d accès. Ainsi les deux solutions présentées dans ce rapport sont en fait complémentaires : si le module de contrôle d accès du serveur détecte par exemple que le client a la possibilité de suivre une négociation, il peut engager cette négociation avec le client. Ce genre d informations peut être transmis à l aide de metadata contenues dans une assertion SAML. La figure suivante illustre cet exemple. IDP1 CoT 1 CoT 2 AuthN 1 2 requête + assertion SAML ACM Utilisateur décision 3 Politiques 6 4 délégation au module de négociation SP2 AP1 module négociation NEGOCIATION 5 credentials module négociation Figure 25 : solution mixte, contrôle d'accès et négociation 37/48

38 7. Axes futurs de travail 7.1. Déploiement pour preuve de concept Mon stage continuant en juillet et août, l objectif est de déployer un module de contrôle d accès dans l architecture du cas Enquête Judiciaire présentée dans ce rapport, sur une plateforme de test constituée de deux cercles de confiance, basés sur des solutions différentes de SSO. Il devra s intégrer aux cercles de confiance sans en perturber les fonctionnalités en place. Ce module, comme développé dans les chapitres objectifs et spécifications, devra principalement être capable de prendre une décision de contrôle d accès grâce à la transmission du rôle enquêteur de l utilisateur, avec une seule authentification sur son cercle de confiance Limites L administration des politiques de sécurité L administration de la politique de sécurité, pour être gérable, doit se faire via l expression, la visualisation, la modification de politiques haut-niveau. Les outils d administration des modèles RBAC [1] et OrBAC [12] sont par exemple des candidats potentiels pour cela. Le problème est donc de pouvoir déterminer comment traduire automatiquement une politique haut-niveau adaptée pour l administrateur en une politique plus bas-niveau comme XACML, sur lesquelles se basent les prises de décision du PDP. L objectif est de combiner les avantages apportées par les deux langages, à savoir la vision haut niveau grâce à l abstraction (RBAC ou OrBAC) et la granularité fine (XACML) Utilisation d un rôle entre différents cercles de confiance Nous avons vu comment un cercle de confiance pouvait utiliser les informations sur le rôle joué par un utilisateur dans un cercle de confiance partenaire, pour contrôler l accès à ses services. Une autre question se pose : comment donner un rôle dans son domaine de sécurité à un utilisateur externe, en fonction du rôle qu il joue dans son domaine? Une possibilité serait de faire du «mapping» de rôle, c est-à-dire donner un rôle interne à un utilisateur externe en fonction d un certain nombre de critères définis dans une politique. Plusieurs autres approches pour les modèles d échanges inter organisations existent dans la littérature, notamment l extension O2O (Organization To Organization) du modèle OrBAC [16]. 38/48

39 8. Conclusion Dans ce rapport nous avons présenté comment utiliser les standards SAML et XACML pour répondre à des problématiques classiques de B2B et comment ajouter une éventuelle négociation pour la prise de décision. Aujourd hui, lorsqu une entreprise souhaite donner des accès à des personnes externes, l administration est lourde et les risques de présence de comptes dormants élevés. L utilisation de standards qui permettent à un utilisateur de transporter facilement des informations sur son identité avec une sécurité élevée et dans le respect de sa vie privée répond aux problèmes d interopérabilité entre les solutions de SSO de chaque cercle de confiance. Baser la prise de décision sur la connaissance d un rôle permet au cercle partenaire qui fournit un service de faire un contrôle d accès fin avec un minimum d information sur la personne, mais avec une information suffisante et certifiée. La gestion de politiques XACML pour le contrôle d accès a cependant ses limites, et il semble indispensable qu une interface intuitive soit proposée à l administrateur pour la création, la modification et la suppression de politiques. De même, les outils existants actuels pour la négociation comme TrustBuilder ne proposent ni l utilisation de langage haut niveau pour exprimer les politiques, ni du standard SAML pour le transport des politiques et des credentials. Des tests de déploiement d un module de contrôle d accès sur une plateforme simulant deux cercles de confiance seront réalisés cet été. 39/48

40 Glossaire AA: Attribute Authority ABAC: Attribute Based Access Control AP: Attributes Provider ARP: Attribute Release Policy B2B: Business To Business Cardspace: implémentation Microsoft d'un sélecteur de cartes Infocard COPS: Common Open Policy Service CoT: Circle of Trust (cercle de confiance) DS: Discovery Service E-SSO: Enterprise Single-Sign On FC² : Fédération de Cercles de Confiance Higgins: projet open source dun système de sélecteur de cartes Infocard IDP: Identity Provider Liberty Alliance: projet de définition d'un standard de fédération d'identités et de profils pour des services innovants OpenID: standard de fédération d'identités OrBAC: Organization-Based Access Control PAP: Policy Administration Point PDP: Policy Decision Point PEP: Policy Enforcement Point PIB: Policy Information Base PIP: Policy Information Point RBAC: Role-Based Access Control SAML: Security Assertion Markup Language SP: Service Provider SSO: Single-Sign On TrustBuilder: implémentation d'un module de négociation en java WSC: Web Service Consumer WSP: Web Service Provider XACML: extensible Access Control Markup Language 40/48

41 Bibliographie [1] Role-Based Access Control, [2] SAML, [3] XACML, [4] Liberty Alliance, [5] XACML and Role-Based Access Control, Jason Crampton, Royal Holloway, University of London, DIMACS Workshop on Secure Web Services and e-commerce [6] XACML-Role Based Access Control, March 2006, Panos Perionellis Jake Wu [7] Romain Laborde, Thierry Desprats, Gestion de conditions stables dans XACML : intérêt d une approche par notification, Université Paul Sabatier Toulouse [8] E. Yuan, J. Tong, Attributed Based Access Control (ABAC) for Web Services [9] SAML 2.0 profile of XACML v2.0, OASIS Standard, 1 February 2005 [10] Core and hierarchical role based access control (RBAC) profile of XACML v2.0, OASIS Standard, 1 February 2005 [11] A Model for Attribute-Based User-Role Assignment, M A. Al-Kahtani, R. Sandhu, IEEE ACSAC 02 [12] A. Abou El Kalam, R. El Baida, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, A. Miège, C. Saurel et G. Trouessin. Organization Based Access Control. IEEE 4th International Workshop on Policies for Distributed Systems and Networks (Policy 2003), Lake Come, Italy, June 4-6, [13] D. Abi Haidar, N. Cuppens-Boulahia, F. Cuppens, H. Debar, Access Negotiation within XACML Architecture. Second Joint Conference on Security in Networks Architectures and Security of Information Systems (SARSSI). Annecy, France, June [14] L Olson M Winslett G Tonti N Seeley A Uszok and J Bradshaw. Trustbuilder as an authorization service for web services. International Workshop on Security and Trust in Decentralized/Distributed Data Structures (STD3S), [15] E. Bertino E. Ferrari Anna Squicciarini. Trust negotiations: concepts, systems, and languages. Computing in Science et Engineering, [16] F. Cuppens, N. Cuppens-Boulahia et C. Coma. O2O: Managing Security Policy Interoperability with Virtual Private Organization. HPOVUA 2006, Presqu'ile de Gien, France. Juin /48

42 Table des figures FIGURE 1 : CAS ENQUETE JUDICIAIRE... 7 FIGURE 2 : CONTROLE D ACCES CLASSIQUE... 8 FIGURE 3 : CONTROLE D ACCES CLASSIQUE VS CONTROLE D ACCES CENTRALISE... 9 FIGURE 4 : ACCES VIA ROLE ENTRE DEUX COTS FIGURE 5 : UN CAS D'USAGE DE SSO MULTI-COTS FIGURE 8 : GESTION DU JETON D'AUTHENTIFICATION FIGURE 11 : FONCTIONNALITES PRINCIPALES DU MODULE FIGURE 12 : VUE GLOBALE SUR LES ELEMENTS PRINCIPAUX POUR UN CONTROLE D'ACCES REPARTI FIGURE 13 : FEDERATION EN INTER-COT FIGURE 14 : CONTROLE D'ACCES REPARTI «PULL CREDENTIALS» ENTRE DEUX COTS FIGURE 15 : DIAGRAMME DE SEQUENCE «PULL CREDENTIALS» POUR L'AUTORISATION D'ACCES ENTRE DEUX COTS FIGURE 16 : CONTROLE D'ACCES REPARTI «PUSH CREDENTIALS» ENTRE DEUX COTS FIGURE 17 : DIAGRAMME DE SEQUENCE «PUSH CREDENTIALS» POUR L'AUTORISATION D'ACCES ENTRE DEUX COTS FIGURE 19 : ELEMENTS METTANT EN OEUVRE UN CONTROLE D'ACCES SUR LES RESSOURCES D'UN AP FIGURE 20 : PROTOCOLE GENERAL DE NEGOCIATION FIGURE 21 : ARCHITECTURE GENERALE DANS LE CAS 2 COTS FIGURE 22 : DIAGRAMME DE SEQUENCE POUR LA NEGOCIATION FIGURE 23 : UN EXEMPLE DE NEGOCIATION POUR LE CAS ENQUETE JUDICIAIRE FIGURE 25 : SOLUTION MIXTE, CONTROLE D'ACCES ET NEGOCIATION FIGURE 26 : CONVERGENCE VERS SAML FIGURE 27 : DIAGRAMME DE FLUX DANS UNE ARCHITECTURE XACML FIGURE 28 : TRANSPORT DE XACML AVEC SAML (SAML PROFILE OF XACML) FIGURE 29 : FONCTIONNEMENT D'UN PDP XACML /48

43 9. Annexes 9.1. Fédération des identités : SAML 2.0 et Liberty Alliance Plusieurs consortiums ont défini des spécification pour la fédération des identités. Les principaux sont SAML, Liberty Alliance ID-FF et Shibboleth. Tous les trois ont interagi et convergé vers les spécifications de SAML 2.0 (voir figure 26). C est pourquoi c est ce standard qui nous a intéressé pour transmettre les informations d authentification, de rôle et d autorisation. Figure 26 : convergence vers SAML 2.0 Security Assertion Markup Language (SAML) est le protocole standard utilise pour l échange d informations sur l authentification et les autorisations d utilisateurs. Trois types d assertions peuvent être échangées : 1. Authentication statements 2. Attribute statements 3. Authorization decision statements (peu développé, XACML est à utiliser à leur place) Différents protocoles sont également définis. Ceux qui sont particulièrement intéressant par rapport à la problématique de contrôle d accès sont : Assertion Query and Request Protocol : ce protocole nous permet d échanger des informations simples sur l authentification de l utilisateur, sur le sujet, sur ses attributs, et sur les décisions d autorisation. <AuthnQuery> permet de faire la requête «Quels sont les assertions contenant des affirmations sur l authentification sont disponibles pour ce sujet?». A ne pas confondre avec <AuthnRequest> <AttributeQuery> permet de demander une liste d attributs correspondant à un sujet. <AuthzDecisionQuery> permet de formuler la requête «Ces actions sur cette ressource doivent être autorisées pour cet utilisateur, étant donné ces évidences?» Cette fonctionnalité a été gelée dans les spécifications de SAML 2.0, pour avoir plus de fonctionnalités (et pouvoir bénéficier de toute l expressivité de XACML) il faut utiliser <XACMLAuthzDecisionQuery>, qui est une extension pour SAML. 43/48

44 Authentication Request Protocol : ce protocole permet de demander la création d une assertion d authentification pour établir un contexte de sécurité sur un fournisseur de service. On utilise des éléments <AuthnRequest> et <AuthnResponse> 9.2. L autorisation : le standard XACML Description de XACML 2.0 XACML (extensible Access Control Markup Language) est un langage qui fournit un mécanisme pour créer des politiques et des règles permettant de contrôler l accès à une ou plusieurs ressources. XACML et SAML (Security Assertion Markup Language), deux standards définis par le consortium OASIS, ont de nombreux points communs. Les principaux composants définis dans l architecture XACML sont le Policy Enforcement Point (PEP), le Policy Decision Point (PDP), le Policy Administration Point (PAP) et le Policy Information Point (PIP). Le PEP est l entité à qui est confié le contrôle d accès à une ou plusieurs ressources. Pour mener à bien cette tâche, le PEP demande au PDP de prendre une décision en fonction des informations (attributs, contexte ) et des politiques que lui transmettront le PAP et le PIP. Dans un scénario où un utilisateur demande l accès à une ressource, cette demande serait transmise au PEP, et analysée par le PDP qui rendrait son verdict. Le protocole SAML serait utilisé pour la formulation de la requête au PEP par le client et pour la réponse du PEP au client, alors que XACML permettrait de définir les échanges de décisions politiques entre le PEP et le PDP. OASIS propose une architecture pour utiliser son langage de politique de contrôle d accès XACML. Dans cette architecture différentes tâches sont spécifiées et distribuées à différents modules. Figure 27 : diagramme de flux dans une architecture XACML Les politiques sont dans un premier temps implémentées via le PAP. Il serait souhaitable de disposer d un outil graphique ergonomique pour réaliser cela. Le PAP est chargé de rendre disponible ces politiques au PDP, lorsque ce dernier lui enverra des requêtes. 44/48

45 La requête d accès d un utilisateur est interceptée par le PEP. Pour pouvoir répondre à cet utilisateur (access or deny), le PEP va reformuler la requête pour le PDP (XACMLAuthzDecisionQuery, une requête SAML définie dans [11]). Ce qu il y a de nouveau dans le profil SAML d XACML : Entre le PEP et le PDP : XACMLAuthzDecisionQuery et XACMLAuthzDecisionStatement Entre le PDP et le PAP : XACMLPolicyQuery et XACMLPolicyStatement Ce qui est déjà défini dans SAML 2.0 : dialogue avec le fournisseur d attributs (AP) via AttributeQuery et AttributeStatement. Figure 28 : transport de XACML avec SAML (SAML profile of XACML) Une «Policy» ou une «PolicySet» est à la racine de toutes les politiques XACML. Une PolicySet est un conteneur qui peut regrouper des «Policy», des «PolicySet» ou encore des références vers des «Policy» situées dans un endroit distant. Une «Policy» représente une simple politique de contrôle d accès, exprimée au travers d un ensemble de règles. Comme une même évaluer une politique peut amener à évaluer un ensemble de règle, on précise dans la politique XACML l algorithme qui permettra de faire une conciliation et de donner une seule réponse. Par exemple, l algorithme first-applicable : la première règle qui est évaluée à un «Permit» ou à un «Deny» est rendue en réponse. Un PDP XACML a pour rôle de trouver les politiques qui s appliquent à une requête donnée. XACML offre une fonctionnalité pour aider le PDP à réaliser cela, il s agit de l élément Target. Une politique se décompose en effet de la manière suivante : PolicySet [Policy Combining Algorithm] 1. Policy [Rule Combining Algorithm] a. Target i. Subject Attributes ii. Resource Attributes iii. Action Attributes iv. Environment Attributes b. Rule [Effect] 45/48

46 i. Subject Attributes ii. Resource Attributes iii. Action Attributes iv. Environment Attributes v. Conditions c. Obligations Target est grossièrement un ensemble de conditions simplifiées sur le sujet, la ressource, l action, et l environnement pour que la politique s applique à une requête donnée. Des fonctions booléennes sont utilisées pour comparer les valeurs trouvées dans une requête avec une Target. Si une requête est trouvée applicable avec la Target, alors les règles (rules) sont évaluées. Figure 29 : fonctionnement d'un PDP XACML XACML prend ses décisions à l aide des attributs qu il collecte sur le sujet, la ressource, l action et l environnement. Deux mécanismes permettent d aller récupérer des attributs : AttributeDesignator et AttributeSelector. AttributeDesignator laisse la politque spécifier un Name et un Type, et optionnellement un Issuer. Le PDP cherche la valeur dans la requête et sinon peut aller chercher la valeur dans d autres endroits (un annuaire LDAP par exemple). AttributeSelector permet d aller chercher des valeurs d attributs au moyen d une requête XPath Un exemple simple Jean Dupont souhaite lire un document CD. Via son navigateur web il entre l url souhaité. La requête HTTP est interceptée par un PEP. Voici alors la requête XACML envoyée par le PEP au PDP. <Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi=" <Subject> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name"> <AttributeValue>[email protected]</AttributeValue> </Attribute> <Attribute AttributeId="habilitation" DataType=" Issuer="[email protected]"> <AttributeValue>CD</AttributeValue> 46/48

47 </Attribute> </Subject> <Resource> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType=" <AttributeValue> </Attribute> <Attribute AttributeId="classification" DataType=" <AttributeValue>CD</AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType=" <AttributeValue>read</AttributeValue> </Attribute> </Action> <Environment/> </Request> On peut formuler cette requête en français de la manière suivante : Jean Dupont, dont l attribut habilitation émis par [email protected] a pour valeur CD, souhaite faire l action read sur la ressource dont l attribut classification émis par [email protected] a pour valeur CD. Le PDP récupère auprès du PAP la politique suivante, qui gère les accès à la GED. Cette politique indique que tous les utilisateurs habilités CD ont accès aux ressources web CD situés sous l adresse <?xml version="1.0" encoding="utf-8"?> <PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi=" PolicySetId="AccesWebServicesSimple" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> <Target/> <Policy PolicyId="AccesGEDSimple" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <Target/> <Rule RuleId="ReadRuleCD" Effect="Permit"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType=" <SubjectAttributeDesignator AttributeId="habilitation" DataType=" MustBePresent="true" Issuer="[email protected]" /> </SubjectMatch> </Subject> </Subjects> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:regexp-string-match"> <AttributeValue DataType=" <ResourceAttributeDesignator DataType=" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/> </ResourceMatch> </Resource> </Resources> <Actions> 47/48

48 <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType=" <ActionAttributeDesignator DataType=" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" /> </ActionMatch> </Action> </Actions> </Target> <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> <ResourceAttributeDesignator DataType=" AttributeId="classification" /> </Apply> <AttributeValue DataType=" </Condition> </Rule> <Rule RuleId="DenyOtherwise" Effect="Deny"> </Rule> </Policy> </PolicySet> Le PDP après évaluation de la requête et de la politique renvoie alors la réponse suivante : <Response> <Result ResourceID=" <Decision>Permit</Decision> <Status> <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/> </Status> </Result> </Response> Le profil RBAC pour XACML 2.0 Pour la gestion des rôles avec XACML, on définit 4 types de politiques : 1. Role <PolicySet> ou RPS : Permet de spécifier la Permission <PolicySet> associée à un rôle. L élément <Target> permet de limiter l applicabilité des permissions ; 2. Permission <PolicySet> ou PPS : Contient concrètement les permissions associées à un rôle donné à l intérieur d éléments <Policy> et <Rules>. Peut référencer d autres PPS et ainsi hériter d autres permissions ; 3. Role Assignment <Policy> ou <PolicySet> : un élément <Policy> ou <PolicySet> qui définit quel rôle peut être activé à quels sujets. Peut aussi définir des restrictions sur les combinaison de rôles possibles pour un même sujet ; 4. HasPrivilegeOfRole <Policy> : une <Policy> dans une PPS qui supporte les requêtes demandant si un sujet a les privilèges associés à un rôle donné. 48/48