Sécurisation d un espace collaboratif. Romain Laborde

Transcription

1 Sécurisation d un espace collaboratif Romain Laborde 26 septembre 2007

2 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

3 Organisation Virtuelle: Introduction Organisation 1 Projet Organisation 2 Organisation 3 Comment mettre en œuvre une infrastructure permettant une telle collaboration?

4 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

5 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!

6 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

7 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

8 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

9 Fonctionnement de Shibboleth

10 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

11 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

12 PERMIS est: PERMIS Infrastructure de gestion de privilèges X.509 basée sur ISO 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)

13 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

14 Shibboleth + PERMIS Policy 4 Users attributes + action name + resource name PERMIS PDP Users Attributes IdP SP PERMIS PEP 5 Apache Server Apache Server Users

15 Shibboleth + PERMIS Evolué

16 Attributs des utilisateurs

17 Définition des attributs des ressources Définition des attributs:

18 Politique: Définition des attributs <RoleHierarchyPolicy> <RoleSpec OID=" " 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>

19 Politique: Définition des attributs <RoleSpec OID=" " Type="voagreement"> <SupRole Value="contract1"/> <SupRole Value="contract2"/> </RoleSpec> <RoleSpec OID=" " 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>

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

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

22 Politique: Définition des ressources protégées <TargetPolicy> <TargetDomainSpec ID="TargetDomain1"> <Include URL=" <Include URL=" </TargetDomainSpec> <TargetDomainSpec ID="wfe-status-domain"> <Include URL=" <Include URL=" </TargetDomainSpec> </TargetPolicy>

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

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

25 Améliorations possibles Langage de politique propriétaire Protocole propriétaire PEP et PDP sur même équipement

26 Solution basée sur XACML/SAML Standards OASIS: SAML demande d autorisation XACML prise des décisions Authorization Server

27 Démonstration basée sur le scénario développé dans le cadre VIVACE/TSCP

28 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