Gestion sémantique des droits d’accès au contenu : l’ontologie AMO

1. Gestion sémantique des droits d’accès au contenu : l’ontologie AMO M. Buffa, C. Faron Zucker

2. AMO in a nutshell • Contrôle d’accès basé sur les notions de rôle des utilisateurs et de types d’accès aux ressources • Représentation déclarative d’une stratégie sous la forme d’une base de règles – facilement modifiable • AMO est complémentaire des standards du web social • Cadre unifié de la gestion des ressources • AMO s’appuie sur FOAF et SIOC et est extensible Introduction

3. Gestion sémantique des droits d’accès au contenu • L’ontologie AMO • Classes et propriétés • Règles d’inférence • Modélisation et mise en œuvre de la stratégie de contrôle de DekiWiki • Annotation des ressources • Base de règles • Requêtes sémantiques • Positionnement Plan de l’exposé

4. Role AccessType Action rdf:type rdf:type ReadContent Guest ModifyContent rdf:type Contributor DeleteContent Administrator ModifyAccessType ModifyUserRights ModifyAuthorizedAgents hasRole hasAction foaf:Agent Role Action hasAuthorizedAgent hasAuthorizedActionOnResource hasActionOnResource creator Private AuthorizedActionOnResource Public SemiPublic hasResource hasAccessType foaf:Document AccessType AMO : classes et propriétés

5. Les droits d’accès dans DekiWiki AMO : exemple d’une stratégie de gestion des droits à modéliser

6. Droits attribués aux agents donnés à une ressource CONSTRUCT { ?agent amo:hasAuthorizedActionOnResource ?a ?a amo:hasResource ?resource ?a amo:hasActionOnResourceamo:ReadContent. ?a amo:hasActionOnResourceamo:ModifyContent. ?a amo:hasActionOnResourceamo:DeleteContent. ?a amo:hasActionOnResourceamo:ModifyAccessType. ?a amo:hasActionOnResourceamo:ModifyAuthorizedAgents } WHERE { ?resourcerdf:typefoaf:Document. ?resourceamo:hasAuthorizedAgent ?agent } • Etc. (6 autres règles) AMO : une base de règles (1)

7. Un agent hérite des droits attribués à ses groupes CONSTRUCT { ?agent amo:hasRole ?role } WHERE { ?group amo:hasRole ?role ?group foaf:member ?agent } • Le créateur d’une ressource est un agent de celle-ci CONSTRUCT ?resourceamo:hasAuthorizedAgent ?agent WHERE ?resourceamo:creator ?agent • Etc. AMO : une base de règles (2)

8. Annotation des ressources (1) • A l’aide des classes et propriétés d’AMO • Lors de la création d’une page wiki : <rdf:RDFxmlns="http://sweetwiki.i3s.unice.fr/AMO.rdfs#" ... > <sioc:WikiArticlerdf:about="#TestPage"> ... <creatorrdf:resource="#AnnaKolomoiska"/> <hasAuthorizedAgentrdf:resource="#MichelBuffa"/> <hasAccessTyperdf:resource="#Private"/> </sioc:WikiArticle> </rdf:RDF> Modélisation de la stratégie de contrôle d’accès dans DekiWiki (1)

9. Annotation des ressources (2) • Lors de la création d’un utilisateur : <rdf:RDFxmlns="http://sweetwiki.i3s.unice.fr/AMO.rdfs#" ... > <foaf:Agentrdf:about="#MichelBuffa"> ... <hasRolerdf:resource="#Contributor"/> </foaf:Agent> </rdf:RDF> Modélisation de la stratégie de contrôle d’accès dans DekiWiki (2)

10. Annotation des ressources (3) • Lors de l’ajout de membres de groupes : <rdf:RDFxmlns="http://sweetwiki.i3s.unice.fr/AMO.rdfs#" ... > <foaf:Grouprdf:about="#AdminGroup"> <foaf:member> <foaf:Agentrdf:about="#AnnaKolomoiska"/> </foaf:member> <foaf:member> <foaf:Agentrdf:about="#CatherineFaron"/> </foaf:member> <hasRolerdf:resource="#Admin"/> </foaf:Group> </rdf:RDF> Modélisation de la stratégie de contrôle d’accès dans DekiWiki (3)

11. Requêtes SPARQL • CatherineFaron peut-elle modifier TestPage? ASK { <http://sweetwiki.unice.fr#CatherineFaron> amo:hasAuthorizedAccessOnResource ?x ?x amo:hasActionOnResourceamo:ModifyContent ?x amo:hasResource <http://sweetwiki.unice.fr#TestPage> } • Quels sont les agents ayant des droits sur TestPage et quels sont leurs actions autorisées? SELECT ?agent ?action WHERE { ?agent amo:hasAuthorizedAccessOnResource ?x ?x amo:hasActionOnResource ?action ?x amo:hasResource <http://sweetwiki.unice.fr#TestPage> } Mise en œuvre de la stratégie de contrôle d’accès dans DekiWiki (4)

12. AMO et les standards du Web 2.0 • Les ressources dans ISICIL sont annotées avec les ontologies FOAF et SIOC • AMO complète FOAF et SIOC • Pour repr. les connaissances relatives aux droits d’accès • AMO complémentaire de FOAFRealm • FOAFRealm pour filtrer l’accès aux ressources en fonction des profils des utilisateurs et de leurs relations sociales • AMO complémentaire de FOAF-SSL • FOAF-SSL pour l’authentification des agents du système Positionnement

13. AMO repose sur FOAF • Actuellement dans AMO amo:DocumentsubClassOffoaf:Document amo:AgentsubClassOffoaf:Agent amo:hasRolerdfs:hasRangefoaf:Agent A la fois les personnes et les groupes peuvent avoir un rôle Les rôles d’un groupe sont propagés à ses membres (formalisé par une règle) Positionnement

14. Modèle utilisateur ISICIL

15. AMO et le nouveau user model de ISICIL • Le user model est basé sur sioc:UserAccount • Mise à jour de AMO doit • distinguer les agents et les accounts • garder la possibilité d’avoir des rôles attribués à des groupes • Dans SIOC, on a: • sioc:has_function amo:hasRole sioc:has_function n’a pas de domain • amo:Role sioc:Role, amo:Group sioc:UserGroup • On se base sur SIOC, on met à jour la base de règles AMO • Extension de SIOC (postérieure à AMO) à voir de plus près • amo:Action sioc:Permission • amo:AccessType sioc:Status Positionnement

16. AMO les droits d’accès basés sur les relations sociales et la confiance • On ajoute de nouvelles règles à la base • Dont les prémisse portent sur les relations qu’ont des foaf:Agent • Dont les conclusions portent sur les droits qu’ont les sioc:UserAccount des foaf:Agent Positionnement

17. A réfléchir : la sécurité dans le code • Java EE et Spring par ex, proposent des ensembles d’annotations de code pour gérer les « autorisations » @DeclareRoles({"j2ee", "guest"}) public class Servlet extends HttpServlet { public void service(HttpServletRequestreq, HttpServletResponseresp) throws ServletException, IOException { resp.setContentType("text/html"); PrintWriter out = resp.getWriter(); out.println("<HTML><HEAD><TITLE>Servlet Output</TITLE> </HEAD><BODY>"); if (req.isUserInRole("j2ee") && !req.isUserInRole("guest")) { out.println("Hello World"); } else { out.println("Invalid roles"); } out.println("</BODY></HTML>"); } }

18. @DeclareRoles sert à définir les rôles qui pourront être testés dans l’application • @RunAs permet de « revêtir » un rôle @RunAs("Admin") public class CalculatorServlet { @EJB private ShoppingCartmyCart; public void doGet(HttpServletRequestreq, HttpServletResponse res) { //.... myCart.getTotal(); //.... } }

19. Spécification des droits d’exécution par : • @RolesAllowed("list-of-roles"), @PermitAll, @DenyAll @RolesAllowed("admin") public class SomeClass { public void aMethod () {...} public void bMethod () {...} ...}  @Stateless public class MyBean {  @RolesAllowed(“students") public void aMethod () {...}  ... }