ISICIL, Grenoble, 24/02/2011 Gestion sémantique des droits d’accès au contenu : l’ontologie AMO M. Buffa, C. Faron Zucker

Introduction 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 2

Plan de l’exposé 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 3

AMO : classes et propriétés 4 rdf:type AccessType Public Private SemiPublic rdf:type Role Guest Contributor Administrator rdf:type Action ModifyContent ReadContent DeleteContent ModifyUserRights ModifyAccessType ModifyAuthorizedAgents foaf:Document foaf:Agent AccessType creator hasAuthorizedAgent hasAccessType AuthorizedAction OnResource RoleAction hasRolehasAction hasAuthorized ActionOnResource hasResource hasActionOnResource

AMO : exemple d’une stratégie de gestion des droits à modéliser Les droits d’accès dans DekiWiki 5 GuestContributorAuthorizedAgentAdministrator Public ReadContent ReadContent ModifyContent DeleteContent ModifyAuthorized Agents ModifyAccessType ReadContent ModifyContent DeleteContent ModifyAuthorized Agents ModifyAccessType ModifyUserRights Semi- Public ReadContent Private

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

AMO : une base de règles (2) 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 ?resource amo:hasAuthorizedAgent ?agent WHERE ?resource amo:creator ?agent Etc. 7

Modélisation de la stratégie de contrôle d’accès dans DekiWiki (1) Annotation des ressources (1) –A l’aide des classes et propriétés d’AMO –Lors de la création d’une page wiki :... 8

Modélisation de la stratégie de contrôle d’accès dans DekiWiki (2) Annotation des ressources (2) –Lors de la création d’un utilisateur :... 9

Modélisation de la stratégie de contrôle d’accès dans DekiWiki (3) Annotation des ressources (3) –Lors de l’ajout de membres de groupes : 10

Mise en œuvre de la stratégie de contrôle d’accès dans DekiWiki (4) Requêtes SPARQL –CatherineFaron peut-elle modifier TestPage? ASK { amo:hasAuthorizedAccessOnResource ?x ?x amo:hasActionOnResource amo:ModifyContent ?x amo:hasResource } –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 } 11

Positionnement 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 12

Positionnement AMO repose sur FOAF –Actuellement dans AMO amo:Document subClassOf foaf:Document amo:Agent subClassOf foaf:Agent amo:hasRole rdfs:hasRange foaf: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) 13

14 Modèle utilisateur ISICIL

Positionnement 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 15

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

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 "guest"}) public class Servlet extends HttpServlet { public void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { resp.setContentType("text/html"); PrintWriter out = resp.getWriter(); out.println(" Servlet Output "); if (req.isUserInRole("j2ee") && !req.isUserInRole("guest")) { out.println("Hello World"); } else { out.println("Invalid roles"); } out.println(" "); } 17

@DeclareRoles sert à définir les rôles qui pourront être testés dans permet de « revêtir » un public class CalculatorServlet private ShoppingCart myCart; public void doGet(HttpServletRequest req, HttpServletResponse res) { //.... myCart.getTotal(); //.... } 18

Spécification des droits d’exécution @RolesAllowed("admin") public class SomeClass { public void aMethod () {...} public void bMethod () public class MyBean public void aMethod () {...}... } 19