Sécurisation d un espace collaboratif Romain Laborde 26 septembre 2007
Plan Le concept d organisation virtuelle Introduction Contraintes Etude de cas définie dans le cadre d une coopération en le projet VIVACE et le programme TSCP Fédération d identité (Shibboleth) Infrastructure de gestion de privilèges (PERMIS) Politiques de contrôle d accès basées sur les attributs (PERMIS) Présentation de la version future de notre solution SAML/XACML Démonstration
Organisation Virtuelle: Introduction Organisation 1 Projet Organisation 2 Organisation 3 Comment mettre en œuvre une infrastructure permettant une telle collaboration?
Organisation Virtuelle: Contraintes (1) Chaque organisation veut garder le contrôle de ses ressources Humaines : Décider qui travaille dans le cadre d une OV, changer le personnel selon les besoins de l organisation, etc Informatique: Ne pas avoir à déléguer l administration d une partie de ses ressources informatique à une autre organisation
Organisation Virtuelle: Contraintes (2) Hétérogénéité des technologies utilisées pour l authentification et les accréditations des utilisateurs Enormément de technologies disponibles sur le marché Il est difficile de demander à une organisation de changer ses technologies pour chaque nouvelle collaboration!
Organisation Virtuelle: Contraintes (3) Facilité d utilisation «Sécurité» ne doit pas être équivalent à «difficultés d utilisation» Exemple de solution non adaptée Un identifiant/mot de passe différent pour chaque utilisateur et pour chaque organisation partenaire Problèmes: Utilisateurs: Trop de couples identifiant/mot de passe à retenir Administrateurs: Difficulté d avoir une vue globale des droits des utilisateurs au niveau de l OV
Etude de cas VIVACE/TSCP Alice Role = Analyzer identity: Company B Virtual Organization identity: Shared Design identity: identity: Company C Bob Role = Designer identity: identity: identity: Conductor Bassem Role =Integrator Company A John Role =Validator
Fédération d identité Identity Provider (IdP) Site d origine des utilisateurs Fournit les mécanismes : Authentification Accréditation des utilisateurs (Roles, id OV) Service Provider (SP) Ressources, Serveurs SAML (standard OASIS): Protocole entre les IdPs et SPs Envoie des déclarations (authentification et attributs) IdP Autentication Users Attributes SAML SP Organization 1 Organization 1 Organisation1 Organisation 2
Fonctionnement de Shibboleth
Etude de cas VIVACE/TSCP Alice Role = Analyzer identity: Company B Virtual Organization identity: Shared Design identity: identity: Company C Bob Role = Designer identity: identity: identity: Conductor Bassem Role =Integrator Company A John Role =Validator
Expression de politique: ABAC ABAC = Attribute Based Access Control Exemple de politique: 1) role(s) = integrator voagreement(s) = contract1 (name(a) = read name(a) = write) name(r) = specification-document status (R) = start 2) role(s) = designer voagreement(s) = contract1 (name(a) = read name(a) = write) name(r) = specification-document status (R) = awaitdesign 3)... +) role(s) = wfe-status voagreement(s) = contract1 (name(a) = read name(a) = write) name(r) = status- specification-document
PERMIS est: PERMIS Infrastructure de gestion de privilèges X.509 basée sur ISO 10181-3 Groupe ISSRG, University of Kent (UK) Role Based Access Control (RBAC) PERMIS fournit: Langage XML pour définir des politiques RBAC Outils pour gérer les privilèges (Certificats d attributs)
PERMIS Externalisation de la fonctionnalité d autorisation des applications PEP = Policy Enforcement Point PDP = Policy Decision Point Que faut il faire de cette requête? PDP Décision Politique Requête PEP Application de la décision du PDP
Shibboleth + PERMIS Policy 4 Users attributes + action name + resource name PERMIS PDP Users Attributes IdP SP PERMIS PEP 5 Apache Server Apache Server 3 2 1 Users
Shibboleth + PERMIS Evolué
Attributs des utilisateurs
Définition des attributs des ressources Définition des attributs:
Politique: Définition des attributs <RoleHierarchyPolicy> <RoleSpec OID="1.2.826.0.1.3344810.1.1.14" Type="permisRole"> <SupRole Value="Integrator"> <SubRole Value="any"/> </SupRole> <SupRole Value="Designer"> <SubRole Value="any"/> Wfe-status </SupRole> <SupRole Value="Analyzer"> <SubRole Value="any"/> Integrator </SupRole> <SupRole Value="Validator"> <SubRole Value="any"/> </SupRole> <SupRole Value="any"/> Designer Analyzer Validator <SupRole Value="wfe-status"/> any </RoleSpec>
Politique: Définition des attributs <RoleSpec OID="1.3.6.1.4.2.1.1" Type="voagreement"> <SupRole Value="contract1"/> <SupRole Value="contract2"/> </RoleSpec> <RoleSpec OID="1.3.6.1.4.2.1.2" Type="status"> <SupRole Value="start"/> <SupRole Value="await-design"/> <SupRole Value="await-analysis"/> <SupRole Value="await-validation"/> <SupRole Value="validated"/> <SupRole Value="stop"/> </RoleSpec> </RoleHierarchyPolicy>
Politique: Définition des autorités d attributs <SOAPolicy> <SOASpec ID="idp1" LDAPDN="cn=idp.example.org,o=test,c=FR"/> <SOASpec ID="idp2" LDAPDN="cn=idp2.example.org,o=Internet Widgits Pty Ltd,st=Some-State,c=FR"/> <SOASpec ID="home" LDAPDN="cn=home,o=test,c=FR"/> </SOAPolicy>
Politique: Définition des droits des AA <RoleAssignmentPolicy> <RoleAssignment> <SubjectDomain ID="SubjectDomain"/> <RoleList> <Role Type="permisRole" Value="Designer"/> <Role Type="permisRole" Value="wfe-status"/> <Role Type="permisRole" Value="Integrator"/> <Role Type="voagreement" Value="contract1"/> </RoleList> <Delegate Depth="0"/> <SOA ID="idp1"/> <Validity/> </RoleAssignment>
Politique: Définition des ressources protégées <TargetPolicy> <TargetDomainSpec ID="TargetDomain1"> <Include URL="http://*:0-65535/secure"/> <Include URL="https://*:0-65535/secure"/> </TargetDomainSpec> <TargetDomainSpec ID="wfe-status-domain"> <Include URL="http://sp.example.org/wfeadmin/wfe-tools/status-admin.php"/> <Include URL="https://sp.example.org/wfeadmin/wfe-tools/status-admin.php"/> </TargetDomainSpec> </TargetPolicy>
Politique: Définition des droits role(s) = wfe-status voagreement(s) = contract1 (name(a) = read name(a) = write) name(r) = status- specification-document <TargetAccessPolicy> <TargetAccess> <RoleList> <Role Type="permisRole" Value="wfe-status"/> <Role Type="voagreement" Value="contract1"/> </RoleList> <TargetList> <Target Actions="GET,POST"> <TargetDomain ID="wfe-status-domain"/> </Target> </TargetList> </TargetAccess>
Politique: Définition des droits role(s) = integrator voagreement(s) = contract1 (name(a) = read name(a) = write) name(r) = specification-document status (R) = start <TargetAccess> <RoleList> <Role Type="permisRole" Value="Integrator"/> <Role Type="voagreement" Value="contract1"/> <Role Type="status" Value="start"/> </RoleList> <TargetList> <Target Actions="GET,POST"> <TargetDomain ID="TargetDomain1"/> </Target> </TargetList> </TargetAccess>
Améliorations possibles Langage de politique propriétaire Protocole propriétaire PEP et PDP sur même équipement
Solution basée sur XACML/SAML Standards OASIS: SAML demande d autorisation XACML prise des décisions Authorization Server
Démonstration basée sur le scénario développé dans le cadre VIVACE/TSCP
Démonstration Bassem Role =Integrator Shared Design sp.example.org Bob Role = Designer wfe idp.example.org Alice Role = Analyzer John Role= Validator idp2.example.org