gestion sémantique des droits d’accès au contenu : l’ontologie amo

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

3Plan 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

AMO : classes et propriétés 4

rdf:t

ype

AccessType

Public

Private

SemiPublic

rdf:t

ype

Role

Guest

Contributor

Administrator

rdf:t

ype

Action

ModifyContent

ReadContent

DeleteContent

ModifyUserRights

ModifyAccessType

ModifyAuthorizedAgents

foaf:Document

foaf:Agent

AccessType

crea

tor

hasA

utho

rized

Age

nt

hasAccessType

AuthorizedActionOnResource

Role ActionhasRole hasAction

hasAuthorizedActionOnResource

hasResource

hasActionOnResource

5AMO : exemple d’une stratégie de gestion des droits à modéliser

• Les droits d’accès dans DekiWiki

Guest Contributor AuthorizedAgent Administrator

Public

ReadContentReadContentModifyContentDeleteContent ReadContent

ModifyContentDeleteContentModifyAuthorizedAgentsModifyAccessType

ReadContentModifyContentDeleteContentModifyAuthorizedAgentsModifyAccessTypeModifyUserRights

Semi-Public ReadContent 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 :

<rdf:RDF xmlns="http://sweetwiki.i3s.unice.fr/AMO.rdfs#" ... >

<sioc:WikiArticle rdf:about="#TestPage"> ...

<creator rdf:resource="#AnnaKolomoiska"/>

<hasAuthorizedAgent rdf:resource="#MichelBuffa"/>

<hasAccessType rdf:resource="#Private"/>

</sioc:WikiArticle>

</rdf:RDF>

8



– Lors de la création d’un utilisateur :


<foaf:Agent rdf:about="#MichelBuffa"> ...

<hasRole rdf:resource="#Contributor"/>

</foaf:Agent>

</rdf:RDF>

9



– Lors de l’ajout de membres de groupes :


<foaf:Group rdf:about="#AdminGroup">

<foaf:member>

<foaf:Agent rdf:about="#AnnaKolomoiska"/>

</foaf:member>

<foaf:member>

<foaf:Agent rdf:about="#CatherineFaron"/>

</foaf:member>

<hasRole rdf:resource="#Admin"/>

</foaf:Group>

</rdf:RDF>

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 {

<http://sweetwiki.unice.fr#CatherineFaron>

amo:hasAuthorizedAccessOnResource ?x

?x amo:hasActionOnResource amo: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> }

11

12Positionnement

• 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

13Positionnement

• AMO repose sur FOAF

– Actuellement dans AMOamo: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)

14

Modèle utilisateur ISICIL

15Positionnement

• 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

16Positionnement

• 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

• 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(HttpServletRequest req, HttpServletResponse resp) 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>"); }}

17

• @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 ShoppingCart myCart; public void doGet(HttpServletRequest req, HttpServletResponse res) { //.... myCart.getTotal(); //.... }}

18

• 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 () {...}

...

}

19

gestion sémantique des droits d’accès au contenu : l’ontologie amo

Documents