=Paper= {{Paper |id=None |storemode=property |title=Linked Data Access Goes Mobile: Context-Aware Authorization for Graph Stores |pdfUrl=https://ceur-ws.org/Vol-937/ldow2012-paper-05.pdf |volume=Vol-937 |dblpUrl=https://dblp.org/rec/conf/www/CostabelloVDG12a }} ==Linked Data Access Goes Mobile: Context-Aware Authorization for Graph Stores== https://ceur-ws.org/Vol-937/ldow2012-paper-05.pdf
            Linked Data Access Goes Mobile: Context-Aware
                    Authorization for Graph Stores

                       Luca Costabello, Serena Villata, Nicolas Delaforge, Fabien Gandon
                                                 INRIA Sophia Antipolis, France
                                               firstname.lastname@inria.fr


ABSTRACT                                                          In this paper we address the problem of defining an access
To encourage data providers to publish a maximum of data          control framework for querying Web of Data servers from
on the Web, we propose a mechanism to define lightweight          mobile environments. Let us consider a content sharing ser-
access control policies for graph stores. Influenced by the       vice compliant with the Web of Data: Alice uploads some
steep growth of the mobile web, our Linked Data access            pictures together with the reviews of a rock concert to the
control framework features context-aware control policies.        platform. She prefers to share these media to everyone but
The proposed framework is exclusively grounded on standard        her boss. Since her colleagues might view the content at
Semantic Web languages. The framework architecture is             work with their smartphones, moving from office to office, she
designed as a pluggable filter for generic SPARQL endpoints,      decides that nobody is allowed to access the shared media
and it has been evaluated on a test dataset.                      from a mobile device if the boss is in the same room.
                                                                  Such application scenario raises three major challenges:
Categories and Subject Descriptors                                (i) how to define a fine-grained access control model for
I.2.4 [Artificial Intelligence]: Knowledge Representation         the Web of Data, (ii) how to model context-aware, mo-
Formalisms and Methods; K.6.5 [Management of Com-                 bile consumption of such information, and (iii) how to inte-
puting and Information Systems]: Security and Protec-             grate mobile context in the access control model, providing
tion                                                              an evaluation of the overall framework. We answer these
                                                                  questions adopting exclusively Web of Data languages and
                                                                  reusing, when possible, already existing proposals, to avoid
General Terms                                                     re-inventing the wheel.
Design, Algorithms                                                First, we describe the S4AC1 vocabulary, a lightweight on-
                                                                  tology which defines fine-grained access control policies for
Keywords                                                          RDF data [23]. We adopt the PRISSMA2 vocabulary to model
Linked Data, Ubiquitous Web, Access Control                       the mobile context in which linked data consumption takes
                                                                  place. Third, we combine the access control model and the
1.    INTRODUCTION                                                contextual vocabulary into context-aware access conditions
Denying or allowing access to a set of resources or services is   defined by data providers. Prototype evaluation shows that
a common problem in a large number of mobile computing            contextual access control comes with a cost, but performance
fields, from location-based services to personal area networks.   still remains acceptable for most Web of Data applications.
As ubiquitous connectivity spreads, access control has been       The main advantage of our proposal is to provide a pluggable
enhanced with location awareness and, to some extent, other       and easy-to-integrate filter for generic SPARQL endpoints,
contextual dimensions such as the proximity of nearby peo-        without modifying the endpoint itself. We rely on W3C rec-
ple or objects. The open nature of current Web of Data            ommendations only, as we do not introduce any new language
information and the consumption of web resources on the go        or technology. For the time being, our framework assumes
may give providers the impression that their content is not       the trustworthiness of the information sent by the mobile
safe, thus preventing further publication of datasets, at the     consumer, including data describing context (e.g. location,
expense of the growth of the Web of Data itself [14]. Access      device features, etc). Our approach focuses only on SPARQL
control is therefore necessary, and context must be part of       data servers. Other Web of Data access strategies, such as
the access control evaluation, given that such Ubiquitous         dereferencing resources, are out of the scope of this work.
Web of Data enables new linked data fruition scenarios.           The reminder of the paper is organized as follows. Sec-
                                                                  tion 2 compares the related work to the proposed framework.
                                                                  Section 3 introduces the mobile context aspects. Section 4
                                                                  describes the access control model, while the access enforce-
                                                                  ment algorithm is detailed in Section 5. Section 6 shows the
                                                                  experimental results of the prototype implementation of the
                                                                  framework.

Copyright is held by the author/owner(s).                         1
LDOW2012 April 16, 2012, Lyon, France.                                http://ns.inria.fr/s4ac/
                                                                  2
                                                                      http://ns.inria.fr/prissma/
2.   RELATED WORK                                                 Data. Moreover, the semantic technology adopted differs, i.e.,
The Web Access Control vocabulary (WAC3 ) allows data             rule-based approach with description logic in their case and
providers to specify access control lists defined at RDF doc-     SPARQL 1.1 in our proposal. Their contextual information
ument granularity (we grant access to specific RDF data,          does not include the device dimension. Finally, their solu-
e.g. a few named graphs). Sacco and Passant [20] present a        tion is not meant to be a pluggable framework for SPARQL
Privacy Preference Ontology (PPO4 ) to express fine-grained       endpoints. Flouris et al. [11] present a fine-grained access
access control policies to an RDF file. The consumer asks for     control framework on top of RDF repositories. Both their
a particular RDF file, e.g., a FOAF profile and the system        framework and our proposal are repository-independent. On
selects and returns the accessible part of the file. They do      the other hand, their solution does not consider the contex-
not propose a filter for generic SPARQL endpoints, nor they       tual dimension and they propose a high level specification
consider contextual information. Muhleisen et al. [19] present    language to be translated into a SPARQL/SerQL/SQL query
a policy-enabled server for Linked Data called PeLDS, based       to enforce the policy. They focus only on Read operations.
on SWRL5 . They deal only with Read and Update actions
and they do not consider contextual information. Giunchiglia
et al. [13] propose a Relation Based Access Control model
                                                                  3.     HANDLING CONTEXT WITH PRISSMA
(RelBAC ). They require to specify who can access the data,       Whenever a mobile application needs to access some re-
while we and [20] specify the attributes the consumer must        sources, the surrounding context (e.g. the physical environ-
satisfy. Finin et al. [10] study the relationship between OWL     ment) must take part into the access evaluation procedure.
and Role Based Access Control (RBAC). To go beyond                SPARQL queries must be associated with contextual data
RBAC, they consider Attribute Based Access Control where,         for access evaluation, according to a proper model.
similarly to our proposal, access constraints are based on        The choice and the design of a context model necessarily need
general attributes of an action. Hollenbach et al. [15] present   a context definition first: we agree on the widely-accepted
a system where providers control the access to RDF docu-          proposal by Dey [9]. More specifically, we rely on the work
ments using WAC, but they do not rely on the consumer’s           by Fonseca et al. 6 , that we adopt as a foundation for our
context. Abel et al. [1] present a model of context-dependent     proposal. The mobile context is seen as an encompassing
access control at triple level. Policies are not expressed        term, an information space defined as the sum of three differ-
using Semantic Web languages, instead they introduce an           ent dimensions: the mobile User model, the Device features
high-level syntax mapped to existing policy languages, en-        and the Environment in which the action is performed.
forcing access control as a layer on top of RDF stores. They      Our Web of Data scenario favours the adoption of an ontology-
pre-evaluate the contextual conditions before expanding the       based model. As pointed out by Korpipää and Mäntyjärvi [17],
queries sent to the database. Shen and Cheng [21] propose         an ontological approach leads to simple and extensible mod-
a context-based access control model using Semantic Web           els. This is a common point with the Web of Data rationale:
technologies, where policies are expressed using SWRL. They       linked data on the Web heavily relies on lightweight vocabu-
consider four types of contexts: subject (our User and De-        laries under the open world assumption (i.e. new ontologies
vice dimensions), object, transaction (our Access Privilege)      can be added at anytime about anything) and model ex-
and environment (our Environment dimension). They do              change and re-use are welcomed and promoted at Web scale.
not apply their model to the Web of Data. Covington et            A large number of ontology-based context models relying
al. [7] use the notion of role proposed by RBAC to capture        on Dey’s definition have been proposed in the latter years,
the context of the environment in which the access requests       as summarized by Baldauf et al. [2] (e.g. CoOL, SOUPA,
are made. Environmental roles are defined using a prolog-         COBRA-ONT). These works are grounded on RDF and
like logical language for expressing policies. Hulsebosch et      provide in-depth context expressivity, but for chronological
al. [16] propose context-sensitive verification methods aimed     reasons they are far from the Web of Data best practices
at checking the authenticity of the user’s information. Cup-      (e.g. no lightweight approach, limited interlinking with other
pens and Cuppens-Boulahia [8] propose an Organization             vocabularies), thus discouraging the adoption and re-use in
Based Access Control (OrBAC) model where contextual con-          the Web community.
ditions have to be satisfied to activate a security rule. They    Our work targets access control in the mobile Web of Data:
introduce a context algebra whereas we rely on Semantic           we need therefore a context model compliant with the Web of
Web languages. Moreover, we deal with a wider range of            Data paradigm. Our context-aware access control framework
contextual dimensions. Corradi et al. [5] present UbiCOSM,        adopts PRISSMA, a lightweight vocabulary originally designed
a security middleware adopting context for policy specifica-      for context-aware adaptation of RDF data [6]. PRISSMA pro-
tion and enforcement. They distinguish between physical           vides classes and properties to model core mobile context
and logical contexts while we consider additional contextual      concepts, but is not meant to deliver yet another mobile con-
dimensions, e.g., the device. Policies are expressed at a         textual model: instead, well-known Web of Data vocabular-
high level of abstraction in terms of RDF metadata. Their         ies and recent W3C recommendations are reused (Figure 1).
approach does not apply to the Web of Data. Toninelli et          Moreover, it does not provide a comprehensive, exhaustive
al. [22] follow two design guidelines: context-awareness to       context representation: the approach is to delegate refine-
control resource access and semantic technologies for context     ments and extensions to domain specialists. The overall
and policy specification. They adopt spontaneous coalitions       context is modelled by the class prissma:Context and is
as an application scenario, while we deal with the Web of         determined by the following dimensions:

                                                                  prissma:User represents the target mobile user associated
3
  http://www.w3.org/wiki/WebAccessControl                         with a prissma:Context and consists in a foaf:Person sub-
4
  http://vocab.deri.ie/ppo
5                                                                 6
  http://www.w3.org/Submission/SWRL/                                  http://bit.ly/XGR-mbui
                    s4ac:
                                                                                       hasAccessConditionSet
                      DisjunctiveACS                                                                                               appliesTo
                                              subClassOf
                                                                   AccessConditionSet                    AccessPolicy        hasAccessPrivilege       AccessPrivilege
                                              subClassOf
                     ConjunctiveACS                                                                                             dcterms:subject
                                                                    hasAccessCondition           hasAccessEvaluationContext


                            rdfs:Literal        hasQueryAsk         AccessCondition             AccessEvaluationContext

                                                                                              owl:equivalentClass
                    prissma:

                                                                                           Context

                                    rdfs:subClassOf                         device                             user
                                                                                          environment                                     rdfs:subClassOf
                      dcn:Device                         Device                                                             User                            foaf:Person
                                                                                         Environment
                                                                                                                                         rdfs:subClassOf
                                                                        nearbyEntity                           ao:time
                                               owl:Thing                                        ao:activity
                                                                              motion                                          Time                     time:TemporalEntity

                                                                                                    Activity             descriptivePeriod
                                                      rdfs:subClassOf
                             geo:SpatialThing                                 POI

                                                        poiLabel                       foaf:based_near         geo:Point
                                                                              radius
                                                           poiCategory


                                  Figure 1: The model at a glance (grey boxes represent core classes).


class. To provide more flexibility, the class can be used to                                             Example 1. Figure 2 visualizes a sample mobile context
model both user stereotypes and specific users.                                                          featuring all the dimensions described above. The user, Bob,
                                                                                                         knows Alice and is currently at work, near his and Alice’s
prissma:Device represents the mobile device on which Web                                                 boss. Bob is using an Android tablet with touch display and
of Data resource consumption takes place, enabling device-                                               is not moving.
specific access control. The class inherits from W3C Delivery
Context Ontology 7 dcn:Device that provides an extensible
and fine-grained model for mobile device features.                                                       Other context-related issues need to be considered beyond
                                                                                                         context-model definition, such as context fetch, context trust-
prissma:Environment models the physical context in which                                                 worthiness and privacy. PRISSMA supports both raw context
the Web of Data resource consumption takes place. Different                                              data fetched directly from mobile sensors (e.g. GPS location,
dimensions are involved in modelling the surrounding envi-                                               mobile features) and refined information processed on board
ronment, delegating refinements and extensions to domain                                                 or by third-party, server-side services (e.g. POI resolution
specialists. Location is modelled with the notion of Point of                                            or user activity detection). The present paper assumes that
Interest (POI). The prissma:POI class consists in a simplified,                                          context data is fetched and pre-processed beforehand.
RDFized version of the W3C Point of Interest Core specifica-                                             The trustworthiness of contextual information sent by mo-
tions8 . Each prissma:POI consists of a geo:SpatialThing9                                                bile consumers should not be taken for granted. The
and can be associated with a given geo:Point cou-                                                        prissma:User’s identity needs to be certified: this is an open
pled with a physical radius via the prissma:radius                                                       research area in the Web, and initiatives such as WebID11
property.      The properties prissma:poiCategory and                                                    specifically deal with this issue. Hulsebosch et al. [16] pro-
prissma:poiLabel are used to assign a category and a la-                                                 vide a survey of context verification techniques (e.g. heuris-
bel. Time is modelled extending the time:TemporalEntity                                                  tics relying on context history, collaborative authenticity
class10 . The prissma:descriptivePeriod property as-                                                     checks). A promising approach is mentioned in Kulkarni
sociates a description to each temporal entity (e.g.                                                     and Tripathi [18], where context sensors are authenticated
http://dbpedia.org/resource/Evening). Other dimen-                                                       beforehand by a trusted party. We plan to tackle the issue
sions are considered: the motion property associates                                                     of context-verification in future work.
any given high-level representation of motion to a                                                       Context is sent to the data server along with the client query
prissma:Environment. The environmental proximity of a                                                    for access evaluation (see Section 5 for details). Privacy
generic object can trigger different resource representations:                                           concerns arise while dealing with mobile user context. We
nearby objects are associated with the Environment with the                                              are aware that sensible data such as current location must be
prissma:nearbyEntity property. The prissma:Activity                                                      handled with a privacy-preserving mechanism. In a previous
class is a placemark aimed at connecting third-party solu-                                               work, the myCampus experience [12], we deal with access
tions focused on inferring high-level representations of user                                            control and obfuscation rules for tracking mobile users. In
actions (e.g.‘running’, ‘driving’, ‘shopping’, etc).                                                     the present proposition, we do not address this issue, nor the
                                                                                                         problem of context integrity.
7
   http://bit.ly/dc-ontology
8
   http://www.w3.org/TR/poi-core/
 9
   http://www.w3.org/2003/01/geo/wgs84_pos
10                                                                                                      11
   http://www.w3.org/TR/owl-time                                                                             http://www.w3.org/2005/Incubator/webid/spec/
 @prefix :                            An Access Condition, as defined in Definition 2, expresses
 [other prefixes omitted]
 :bobCtx{
                                                                     a constraint which needs to be verified in order to have the
 :ctx1 a prissma:Context;                                            Access Policy satisfied.
          prissma:user :usr1;        THE CONSUMER'S
          prissma:device :dev1;         CONTEXT                      Definition 2. (Access Condition) An Access Condition
          prissma:environment :env1.
                                                                     (AC) is a condition which tests whether or not a query
 :usr1 a prissma:User;                                               pattern has a solution.
         foaf:name "Bob";           THE USER DIMENSION
         foaf:knows ex:alice#me.

 :dev1 a prissma:Device;                                             In the S4AC model, we express Access Conditions as SPARQL
         hard:deviceHardware :dev1hw;
         soft:deviceSoftware :dev1sw.
                                                                     1.1 ASK queries. Note that no information is returned about
 :dev1hw a hard:DeviceHardware;                                      the possible query solutions, just whether or not a solution
           dcn:display hard:TactileDisplay. THE DEVICE DIMENSION
 :dev1sw a soft:DeviceSoftware;
                                                                     exists.
           soft:operatingSystem :dev1os.
 :dev1os a soft:OperatingSystem;                                     Definition 3. (Access Condition verification) If the query
           common:name "Android".                                    pattern has a solution (i.e., the ASK query returns true), then
 :env1 a prissma:Environment;                                        the Access Condition is said to be verified. If the query
         prissma:motion "no";                                        pattern has no solution (i.e., the ASK query returns false),
         prissma:nearbyEntity :ACME_boss#me;
         prissma:currentPOI :ACMEoffice.           THE ENVIRONMENT   then the Access Condition is said not to be verified.
 :ACMEoffice a prissma:POI;                           DIMENSION
               prissma:poiCategory example:Office;
               prissma:poiLabel example:ACMECorp.
 }
                                                                     Each Access Policy P is composed by a set of Access Condi-
                                                                     tions, as defined in Definition 4.
     Figure 2: Bob’s sample mobile context in TriG notation.
                                                                     Definition 4. (Access Condition Set) An Access Condition
                                                                     Set (ACS) is a set of access conditions of the form ACS =
4.      WEB OF DATA ACCESS CONTROL                                   {AC1 , AC2 , . . . , ACn }.
In this section, we present our access control model and we
show how it is linked to the PRISSMA context vocabulary
presented in Section 3. Our access control model adopts the          Roughly, the verification of an Access Condition Set returns a
granularity of named graphs [3], thus supporting fine-grained        true/false answer. We consider two standard ways to provide
access control policies, including the triple level. We choose       such an evaluation: conjunctively and disjunctively.
to rely on named graphs to not depend on documents (one              Definition 5. (Conjunctive Access Condition Set) A
document can serialize several named graphs, one named               Conjunctive Access Condition Set (CACS) is a log-
graph can be split over several documents, and not all graphs        ical conjunction of Access Conditions of the form
come from documents). The named graph specification per-             CACS = AC1 ∧ AC2 ∧ . . . ∧ ACn .
mits to organize the RDF content of a dataset in multiple
graphs identified by given URIs12 .                                  Definition 6. (Conjunctive ACS evaluation) A CACS is
The model is grounded on the S4AC ontology (Figure 1). Our           verified if and only if every contained Access Condition is
access control model is integrated with lightweight ontologies       verified.
adopted in the Social Web and the Web of Data. In par-
                                                                     Definition 7. (Disjunctive Access Condition Set) A
ticular, S4AC reuses concepts from SIOC13 , SKOS14 , WAC,
                                                                     Disjunctive Access Condition Set (DACS) is a log-
SPIN15 and Dublin Core16 .
                                                                     ical disjunction of Access Conditions of the form
The main component of the S4AC model is the Access Policy,
                                                                     DACS = AC1 ∨ AC2 ∨ . . . ∨ ACn .
as presented in Definition 1. Roughly, an Access Policy de-
fines the constraints that must be satisfied to access a given       Definition 8. (Disjunctive ACS evaluation) A DACS is
named graph or a set of named graphs. If the Access Policy           verified if and only if at least one of the contained Access
is satisfied the data consumer is allowed to access the data.        Conditions is verified.
Otherwise, the access is denied. The constraints specified
by the Access Policies may concern the data consumer, the
device, the environment, or any given combination of these           We introduce the ACS, instead of using for instance the
dimensions (see Section 3).                                          SPARQL UNION clause inside the ASK, because the idea is
                                                                     to define basic ACs with a simple and focused goal to allow
Definition 1. (Access Policy) An Access Policy (P ) is a             their reuse by users without a SPARQL background.
tuple of the form P = hACS, AP, S, R, AECi where (i) ACS             The second component of the Access Policy is the Access
is a set of Access Conditions to satisfy, (ii) AP is an Access       Privilege. The privilege specifies the kind of operation the
Privilege, (iii) S is the subject of the set of resources to         data consumer is allowed to perform on the resource(s) pro-
be protected by P , (iv) R is the (set of) resource(s) to            tected by the Access Policy.
be protected by P , and (v) AEC is the Access Evaluation
Context of P .                                                       Definition 9. (Access Privilege) An Access Privilege (AP )
12
                                                                     is a set of allowed operations on the protected resources of
   The discussion about the use of named graphs in RDF 1.1           the form AP = {Create, Read, U pdate, Delete}.
 can be found at http://www.w3.org/TR/rdf11-concepts
13
   http://rdfs.org/sioc/spec
14
   http://www.w3.org/TR/skos-reference                               We model the Access Privileges as four classes of operations
15
   http://spinrdf.org                                                to keep a close relationship with CRUD-oriented access con-
16
   http://dublincore.org/documents/dcmi-terms                        trol systems, allowing a finer-grained access control beyond
simple read/write privileges. Moreover, we relate the four         :alice_reviews {
privilege classes to SPARQL 1.1 query and update language          ex:29900 a bibo:Article;
                                                                          dcterms:title "A great festival";
primitives through the SPIN ontology, which models the                    dcterms:date "2011";
SPARQL primitives as SPIN classes. We show how this                       dcterms:creator example:alice#me;
matching is actually used in Section 5.                                   bibo:abstract "Really enjoyed Coldplay".
As previously explained, policies protect data at named
                                                                   ex:29655 a bibo:Article;
graph level. We offer two different ways of specifying the                dcterms:title "Disappointed";
protected object: the provider may target one or more spe-                dcterms:date "2010";
cific named graphs, or a set of named graphs associated                   dcterms:creator example:alice#me;
                                                                          bibo:abstract "Not up to the standards".
with a common subject. The former is achieved by pro-              }
viding the URI(s) of the named graph(s) to protect using
the s4ac:appliesTo property. The latter is implemented             Figure 3: The named graph :alice_reviews, in TriG syntax.
by listing the subjects of the named graphs to protect us-         The graph contains the concert reviews authored by Alice.
ing the property dcterms:subject. The assumption here
is that named graphs have been previously annotated with
                                                                   :policy1 a s4ac:AccessPolicy; ACCESS POLICY
such metadata. Summarizing, both S and R represent the                        s4ac:appliesTo :alice_reviews; RESOURCE TO PROTECT
data to protect, but R specifies the URI(s) of the named                      s4ac:hasAccessPrivilege [a s4ac:Read]; ACCESS PRIVILEGE
                                                                              s4ac:hasAccessConditionSet :acs1.
graphs, while S specifies the subject of the graphs (e.g., the
policy protects the named graphs whose subject is Concert,         :acs1 a s4ac:AccessConditionSet;
                                                                           s4ac:ConjunctiveAccessConditionSet;
http://dbpedia.org/resource/Concert).                                      s4ac:hasAccessCondition :ac1,:ac2. ACCESS CONDITIONS
Finally, the Access Policy is associated with an Access Eval-                                                        TO VERIFY

uation Context. The latter provides an explicit link between       :ac1 a s4ac:AccessCondition;
                                                                          s4ac:hasQueryAsk
the policy and the actual context data (in the case of the                """ASK {?context a prissma:Context.
mobile context it is modelled with PRISSMA) that will be used                     ?context prissma:user ?u.
                                                                                  ?u foaf:knows ex:alice#me.}""".
to evaluate the Access Policy.
                                                                   :ac2 a s4ac:AccessCondition;
Definition 10. (Access Evaluation Context) An Ac-                         s4ac:hasQueryAsk
                                                                          """ASK {?context a prissma:Context.
cess Evaluation Context (AEC) is a list of predeter-                              ?context prissma:environment ?env.
mined bound variables of the form AEC = (hvar1 , val1 i,                          ?env prissma:based_near ?p.
hvar2 , val2 i, . . . , hvarn , valn i).                                          FILTER (!(?p=ex:ACME_boss#me))}""".


                                                                    Figure 4: The Access Policy protecting :alice_reviews
In this paper, we focus on the mobile context, thus the Ac-
cess Evaluation Context list is composed only by a couple
AEC = (hctx, U RIctx i). We map therefore the variable ctx,        ice_reviews whose content is shown in Figure 3. We now
used in the policy’s Access Conditions, to the URI identifying     present an example of Access Policy with a conjunctive Ac-
the actual mobile context in which the SPARQL query has            cess Condition Set associated with a Read privilege (Figure 4).
been performed. More specifically, we choose to implement          The policy protects the named graph :alice_reviews and
the Access Evaluation Context as a SPARQL 1.1 BINDINGS             allows the access to the named graph only if the consumer
clause to constrain the ASK evaluation, i.e. BINDINGS ?ctx         (i) knows Alice, and (ii) is not located near Alice’s boss.
{(U RIctx )}. However, the same result can be obtained by
binding directly the variable ?ctx to the URI of the contex-
tual graph.                                                        Policy validation can be addressed in two different ways.
The semantics of our Access Control Policies is mirrored in        First, the SPIN vocabulary can be used to express the literal
the semantics of the SPARQL language, in particular con-           representing the ASK query as RDF statements. On the other
cerning the ASK query and the BINDINGS clause. The result          hand, we can perform a two-step validation, combining RDF
of the verification of each access condition is composed, in       validation for the policy and SPARQL validation for the
case of multiple conditions, conjunctively or disjunctively        literals of s4ac:hasQueryAsk, i.e. the ASK queries.
and this combination provides the overall result of the policy
evaluation. The Access Privilege and the resource to protect
are components of the policy which do not concur to its            5.     CONTROL ENFORCEMENT
verification.                                                      Our Access Control Manager is designed as a pluggable
                                                                   component for SPARQL endpoints (Figure 5). The access
Conflicts among policies might occur if the data provider          control flow is described below:
uses Access Conditions with contrasting FILTER clauses. For
instance, it is possible to define positive and negative state-
                                                                        1. the mobile consumer queries the SPARQL endpoint to
ments such as ASK{FILTER(?u=)} and
                                                                           access the content. At the same time, contextual infor-
ASK{FILTER(!(?u=))}. If these two Ac-
                                                                           mation is sent with the query and saved as a named
cess Conditions are applied to the same data, a logical conflict
                                                                           graph using SPARQL 1.1 update language statements.
arises. This issue is handled in the framework by evaluating
                                                                           Each time a context element is added we use an IN-
policies applied to a resource in a disjunctive way. We expect
                                                                           SERT DATA, while we rely on a DELETE/INSERT when
to add a mechanism to prevent the insertion of conflicting
                                                                           the contextual information is already stored and has to
policies as a future work.
                                                                           be updated. Summarizing, the mobile client sends two
Example 2. Let us consider the named graph :al-                            SPARQL queries: the first is the client query aimed at
                         1                   2         Access Control            4
                                                         Manager
                                 Query                     Access       "secured"                    Datastore
                                                         Enforcement      Query
                                                              +
                                                                                     SPARQL
                                                           Policies
                               Contextual                                            endpoint
                                                   3      Selection
                               Information
                                                                                                 Access     Contextual
                                                                                                          +
                                                                                                 Policies    Graphs
                                                                             5



                                         Figure 5: The access control framework architecture.


      the datastore, the second provides contextual informa-                  PREFIX ctxgraphs: 
      tion (like the one visualized in Figure 2).                             ASK{?context a prissma:Context.
                                                                                  ?context prissma:user ?u.    THE CONSUMER'S
   2. the client query is filtered by the Access Control Man-                     ?u foaf:knows ex:alice#me.}     CONTEXT
      ager instead of being directly executed on the SPARQL                       BINDINGS ?context {(ctxgraphs:bobCtx)}

      endpoint.                                                               ASK {?context a prissma:Context.
                                                                                   ?context prissma:environment ?env.
   3. the Access Control Manager selects the set of policies                       ?env prissma:based_near ?p.
                                                                                   FILTER (!(?p=ex:ACME_boss#me))}
      affecting the client query and after their evaluation                        BINDINGS ?context {(ctxgraphs:bobCtx)}
      returns the set of named graphs the consumer is granted
      access to.                                                        Figure 6: The Access Conditions bound to the actual
                                                                        prissma:Context shown in Figure 2
   4. the client query is executed only on the accessible
      named graphs.
                                                                                 PREFIX bibo: 
                                                                                 SELECT *
   5. the result of the query is returned to the consumer.
                                                                                 WHERE {?review a bibo:Article}

                                                                                                      (a)
The aim of the Access Control Manager is twofold: it first
selects the Access Policies to assess and it verifies the set of
Access Conditions included in the selected policies to grant                     PREFIX bibo: 
                                                                                 SELECT *                        NAMED GRAPH
or not the access. We describe the two algorithms to protect                     FROM :peter_reviews             ACCESSIBLE BY
the access to the data (Figure 8).                                               WHERE {?review a bibo:Article} THE CONSUMER

Algorithm 1 is the main procedure for the execution of a                                            (b)
query with access enforcement. The input of the algorithm               Figure 7: The SPARQL query issued by Bob’s mobile client
is the client query Q and the RDF graph Gctx modeling                   (a) and the constrained version (b).
the client mobile context. It assumes the existence of a
repository of access policies AP S. The algorithm starts by
saving the contextual graph in a local cache (line 1). At the           execute. In particular, the algorithm maps the client query
beginning, the set of accessible named graph N GS is empty              to one of the four access privileges S4AC defines using the
(line 3). The selection of the Access Policies is addressed             SPIN vocabulary (line 1). Then, the algorithm selects all
by the sub-routine Access Policies Selection (line 4), which            the Access Policies which have the identified Access Privilege
returns the set of Access Policies the query is concerned by.           (lines 3-7). The selected policies are returned to the main
Then, the algorithm runs all the Access Conditions composing            Access Enforcement algorithm (Algorithm 1).
the selected policies (lines 7-10). According to the type of            Example 3. An example of client query is shown in Fig-
Access Condition Set (i.e., conjunctive or disjunctive), for            ure 7.a, where Bob wants to access all rock festival’s reviews
each verified policy, the associated named graph is added               from the context described in Figure 2. When the query is
to the set of accessible named graphs (lines 11-12). Finally,           received by the Access Control Manager, the latter selects the
after the execution of all Access Conditions, the client query          Access Policies concerning this query (for instance the policy
is sent to the SPARQL endpoint with the addition of the                 shown in Figure 4). The Access Conditions included in the
FROM clause (line 16). Query execution is therefore performed           policies are then coupled with a BINDINGS clause, as shown
only on the accessible named graphs, given the consumer                 in Figure 6, where the ?context variable is bound to Bob’s
contextual information. Line 18 outputs the triples resulting           actual context. The identification of the named graph(s)
from Q.                                                                 accessible by Bob returns only the graph :peter_reviews.
                                                                        The named graph :alice_reviews of Figure 3 is forbidden
Algorithm 2 is the Access Policies Selection routine. It                because Access Conditions evaluation leads to a false an-
selects the Access Policies concerned by the client query.              swer with Bob’s context (Bob is near Alice’s boss). The
The input of the algorithm is the query Q and the repository            Access Control Manager adds the FROM clause to constrain
of the policies AP S. We do not want to verify all the Access           the execution of the client query only on the allowed named
Policies every time a query is run. Thus, we adopt a selection          graph. The “secured” client query is shown in Figure 7.b.
mechanism to obtain only a subset of Access Policies to
     Algorithm 1: Query Execution with Access Enforcement            on performance for various levels of cardinality reduction,
   Input: a SPARQL query Q, an RDF graph Gctx , Access Policy Set    using modified versions of the BSBM dataset featuring a
           APS                                                       larger amount of named graphs (we define a higher number
   Output: the SPARQL query result R                                 of bsbm:RatingSites, thus obtaining more named graphs).
 1 save Gctx in local contextual cache;
 2 if Gctx has changed then                                          When access is granted to a small fraction of named graphs,
 3     N GS = ∅;                                                     the query is executed faster than the case without access con-
 4     AP S ← APSelection(Q, AP S);                                  trol (e.g. if access is granted to only 1% of named graphs, the
 5     forall APi ∈ AP S do
 6         ACcountf alse = 0;
                                                                     query is executed 19% faster on the 1M triple test dataset).
 7         forall ACj ∈ ACSi do                                      As more named graphs and triples are accessible, perfor-
 8             append Gctx to ACj as BINDINGS clause;                mance decreases. In particular, response time is affected
 9             if ASKACj execution returns false then
                                                                     by the construction of the active graph, determined by the
10                 ACcountf alse + +;
                                                                     merge of graphs in FROM clauses. As shown in Figure 9.b,
11             if (ACSAPi is DACS and                                the cost of this operation grows with the number of named
               ACcountf alse < ACSAPi )||(ACSAPi is CACS and         graphs returned by the evaluation of the Access Policies.
               ACcountf alse = 0 then                                In Figure 9.c we analyse the overhead introduced on response
12                 N GS ← N GS ∪ N GAPi ;
                                                                     time by queries executed in dynamic mobile environments.
13 else                                                              We execute independent runs of 100 identical SELECT queries,
14     N GS ← N GScached ;                                           dealing with a range of context change probabilities. In case
15 forall N Gi ∈ N GS do                                             of a context update, the query is coupled with a SPARQL 1.1
16     append FROM  to Q;                                     update (Section 5). Not surprisingly, with higher chances of
17 R ← run Q;                                                        updating the context, the response time of the query grows,
18 return R;
                                                                     since more SPARQL queries need to be executed. The delay
                                                                     of INSERT DATA or DELETE/INSERT operations depends on
     Algorithm 2: Access Policies Selection                          the size of the triple store and on the number of named
   Input: SPARQL client query Q, APS                                 graphs (e.g. after a DELETE query, the adopted triple store
   Output: a reduced set of Access Policies AP Sr
 1 AccP rvQ ← map Q type to CRUD operation;                          refreshes internal structures to satisfy RDFS entailment).
 2 AP Sr = ∅;                                                        Performance is therefore affected by the number of active
 3 forall APi ∈ AP S do                                              mobile users, since each of them is associated with a mobile
 4     if AccP rvAPi ≡ AccP rvQ then
 5         AP Sr ← AP Sr ∪ APi ;                                     context graph.
 6     end
 7 end
 8 return AP Sr ;                                                    7.   CONCLUSIONS
                                                                     Accessing the Web of Data needs an access control mecha-
               Figure 8: SPARQL Query Execution Procedure
                                                                     nism. Moreover, consumption and production of linked data
                                                                     might origin from mobile devices immersed into pervasive
                                                                     environments. This paper presents an approach towards
     6.      EVALUATION                                              context-aware access control for the ubiquitous Web of Data.
     To assess the impact on response time, we implemented the       The proposed solution is conceived as an easy-to-integrate
     Access Control Manager as a Java EE component and we            pluggable filter for data servers that support the SPARQL
     plugged it to the Corese-KGRAM RDF store and SPARQL             query language. Our framework relies only on Web of Data
     1.1 query engine17 [4]. We evaluate the prototype on an         languages and existing vocabularies; no other formalism has
     Intel Xeon E5540, Quad Core 2.53 GHz machine with 48GB          been added. The prototype evaluation shows that, despite
     of memory, using the Berlin SPARQL Benchmark (BSBM)             the overall performance needs to be ameliorated, the delay
     dataset 3.118 .                                                 introduced by our fine-grained, context-based access control
     In Figure 9 we execute 10 independent runs of a test query      is acceptable given that data protection comes with a cost.
     batch consisting in 50 identical queries of a simple SELECT     Future testing campaign will be carried out to provide a
     over bsbm:Review instances (tests are preceded by a warmup      thorough evaluation with other SPARQL query engines, such
     run). We measure the response time with and without access      as Virtuoso, Sesame, Jena and AllegroGraph. An effective
     control. When executed against the Access Control Manager,      backend user interface to define Access Policies has to be
     the test SPARQL query is associated with the mobile context     designed, as user interaction issues should not be underesti-
     described in Figure 2. Each Access Policy contains exactly      mated. The trustworthiness of the information sent by the
     one Access Condition. In Figure 9.a, to simulate a worst-case   mobile consumer, including data describing context (e.g. lo-
     scenario, access is granted to all named graphs defined in      cation, device features, etc.) should not be taken for granted:
     the base (i.e. all Access Conditions return true), so that      future work needs to investigate this issue. Privacy concerns
     query execution does not benefit from cardinality reduction.    arise while dealing with mobile user context. We are aware
     Larger datasets are less affected by the delay introduced by    that sensible data such as current location must be handled
     our prototype, as datastore size plays a predominant role in    with a privacy-preserving mechanism, and we will therefore
     query execution time (e.g. for 4M triples and 100 always-true   focus on this issue in the future.
     Access Policies we obtain a 32.6% response time delay).
     In a typical scenario, the Access Control Manager restricts
     the results of a query. In Figure 9.b we assess the impact      8.   REFERENCES
                                                                      [1] F. Abel, J. L. De Coi, N. Henze, A. W. Koesling,
     17
          http://tinyurl.com/corese-engine                                D. Krause, and D. Olmedilla. Enabling Advanced and
     18
          http://bit.ly/berlin-sparql                                     Context-Dependent Access Control in RDF Stores. In
                                                              [9] A. K. Dey. Understanding and using context. Personal
                                                                  Ubiquitous Computing, 5:4–7, 2001.
                                                             [10] T. W. Finin, A. Joshi, L. Kagal, J. Niu, R. S. Sandhu,
                                                                  W. H. Winsborough, and B. M. Thuraisingham.
                                                                  ROWLBAC: representing role based access control in
                                                                  OWL. In Procs of 13th ACM Symposium on Access
                                                                  Control Models and Technologies (SACMAT-2008),
                                                                  pages 73–82, 2008.
                                                             [11] G. Flouris, I. Fundulaki, M. Michou, and G. Antoniou.
                          (a)                                     Controlling Access to RDF Graphs. In Procs of the 3rd
                                                                  Future Internet Symposium (FIS-2010), LNCS 6369,
                                                                  pages 107–117, 2010.
                                                             [12] F. Gandon and N. M. Sadeh. A semantic e-wallet to
                                                                  reconcile privacy and context awareness. In Procs of the
                                                                  2nd Int. Semantic Web Conf. (ISWC-2003), LNCS
                                                                  2870, pages 385–401, 2003.
                                                             [13] F. Giunchiglia, R. Zhang, and B. Crispo. Ontology
                                                                  driven community access control. In Procs of the 1st
                                                                  Workshop on Trust and Privacy on the Social and
                                                                  Semantic Web (SPOT-2009), 2009.
                          (b)
                                                             [14] T. Heath and C. Bizer. Linked Data: Evolving the Web
                                                                  into a Global Data Space. Morgan & Claypool, 2011.
                                                             [15] J. Hollenbach, J. Presbrey, and T. Berners-Lee. Using
                                                                  RDF Metadata To Enable Access Control on the Social
                                                                  Semantic Web. In Procs of the Workshop on
                                                                  Collaborative Construction, Management and Linking
                                                                  of Structured Knowledge (CK-2009), 2009.
                                                             [16] R. J. Hulsebosch, A. H. Salden, M. S. Bargh, P. W. G.
                                                                  Ebben, and J. Reitsma. Context sensitive access
                                                                  control. In Procs of the 10th ACM Symposium on
                         (c)                                      Access Control Models and Technologies
           Figure 9: Response time overhead                       (SACMAT-2005), pages 111–119, 2005.
                                                             [17] P. Korpipää and J. Mäntyjärvi. An ontology for mobile
                                                                  device sensor-based context awareness. In Procs of the
                                                                  4th Int. and Interdisciplinary Conf. Modeling and Using
    Procs of the 6th Int. Semantic Web Conf.                      Context (CONTEXT-2003), LNCS 2680, pages
    (ISWC-2007), LNCS 4825, pages 1–14, 2007.                     451–458, 2003.
[2] M. Baldauf, S. Dustdar, and F. Rosenberg. A survey on    [18] D. Kulkarni and A. Tripathi. Context-aware role-based
    context-aware systems. Int. J. of Ad Hoc and                  access control in pervasive computing systems. In Procs
    Ubiquitous Computing, 2(4):263–277, 2007.                     of 13th ACM Symposium on Access Control Models and
[3] J. J. Carroll, C. Bizer, P. J. Hayes, and P. Stickler.        Technologies (SACMAT-2008), pages 113–122, 2008.
    Named graphs. J. Web Sem., 3(4):247–267, 2005.           [19] H. Muhleisen, M. Kost, and J.-C. Freytag.
[4] O. Corby and C. Faron-Zucker. The KGRAM Abstract              SWRL-based Access Policies for Linked Data. In Procs
    Machine for Knowledge Graph Querying. In Web                  of the 2nd Workshop on Trust and Privacy on the
    Intelligence, pages 338–341. IEEE, 2010.                      Social and Semantic Web (SPOT-2010), 2010.
[5] A. Corradi, R. Montanari, and D. Tibaldi.                [20] O. Sacco and A. Passant. A Privacy Preference
    Context-based access control management in                    Ontology (PPO) for Linked Data. In Procs of the 4th
    ubiquitous environments. In Procs of the 3rd IEEE Int.        Workshop about Linked Data on the Web
    Symposium on Network Computing and Applications               (LDOW-2011), 2011.
    (NCA-2004), pages 253–260, 2004.                         [21] H. Shen and Y. Cheng. A semantic context-based
[6] L. Costabello. DC Proposal: PRISSMA, Towards                  model for mobile web services access control. Int. J.
    Mobile Adaptive Presentation of the Web of Data. In           Computer Network and Information Security, 2011.
    Procs of the 10th Int. Semantic Web Conf.                [22] A. Toninelli, R. Montanari, L. Kagal, and O. Lassila. A
    (ISWC-2011), LNCS 7032, pages 269–276, 2011.                  semantic context-aware access control framework for
[7] M. J. Covington, W. Long, S. Srinivasan, A. K. Dey,           secure collaborations in pervasive computing
    M. Ahamad, and G. D. Abowd. Securing context-aware            environments. In Procs of the 5th Int. Semantic Web
    applications using environment roles. In Procs of the         Conf. (ISWC-2006), LNCS 4273, pages 473–486, 2006.
    6th ACM Symposium on Access Control Models and           [23] S. Villata, N. Delaforge, F. Gandon, and A. Gyrard.
    Technologies (SACMAT-2001), pages 10–20, 2001.                An access control model for linked data. In Procs of the
[8] F. Cuppens and N. Cuppens-Boulahia. Modeling                  7th Int. IFIP Workshop on Semantic Web & Web
    contextual security policies. Int. J. Inf. Sec.,              Semantics (SWWS-2011), LNCS 7046, pages 454–463,
    7(4):285–305, 2008.                                           2011.