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

carriagespinInternet and Web Development

Oct 22, 2013 (4 years and 2 months ago)

91 views

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

r
df:type

AccessType

Public

Private

SemiPublic

r
df:type

Role

Guest

Contributor

Administrator

r
df:type

Action

ModifyContent

ReadContent

DeleteContent

ModifyUserRights

ModifyAccessType

ModifyAuthorizedAgents

f
oaf:Document

foaf:Agent

AccessType

creator

hasAuthorizedAgent

hasAccessType

AuthorizedAction

OnResource

Role

Action

hasRole

hasAction

hasAuthorized

ActionOnResource

hasResource

hasActionOnResource

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


Les droits d’accès dans
DekiWiki

5

Guest

Contributor

AuthorizedAgent

Administrator

Public

ReadContent

ReadContent

ModifyContent

DeleteContent

ReadContent

ModifyContent

DeleteContent

ModifyAuthorized
Agents

ModifyAccessType

ReadContent

ModifyContent

DeleteContent

ModifyAuthorized

Agents

ModifyAccessType

ModifyUserRights

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

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 :

<
rdf:RDF

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


<
foaf:Agent

rdf:about
="#
MichelBuffa
">



...



<
hasRole

rdf:resource
="#
Contributor
"/>


</
foaf:Agent
>

</
rdf:RDF
>

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 :

<
rdf:RDF

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


<
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

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

»

@
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