To encourage data providers to publish a maximum of data on the Web, we propose a mechanism to de ne lightweight access control policies for graph stores. In uenced by the steep growth of the mobile web, our Linked Data access control framework features context-aware control policies. The proposed framework is exclusively grounded on standard Semantic Web languages. The framework architecture is designed as a pluggable lter for generic SPARQL endpoints, and it has been evaluated on a test dataset.
Denying or allowing access to a set of resources or services is
a common problem in a large number of mobile computing
elds, from location-based services to personal area networks.
As ubiquitous connectivity spreads, access control has been
enhanced with location awareness and, to some extent, other
contextual dimensions such as the proximity of nearby
people or objects. The open nature of current Web of Data
information and the consumption of web resources on the go
may give providers the impression that their content is not
safe, thus preventing further publication of datasets, at the
expense of the growth of the Web of Data itself [
In this paper we address the problem of de ning an access control framework for querying Web of Data servers from mobile environments. Let us consider a content sharing service compliant with the Web of Data: Alice uploads some pictures together with the reviews of a rock concert to the platform. She prefers to share these media to everyone but her boss. Since her colleagues might view the content at work with their smartphones, moving from o ce to o ce, she decides that nobody is allowed to access the shared media from a mobile device if the boss is in the same room. Such application scenario raises three major challenges: (i) how to de ne a ne-grained access control model for the Web of Data, (ii) how to model context-aware, mobile consumption of such information, and (iii) how to integrate mobile context in the access control model, providing 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 re-inventing the wheel.
First, we describe the S4AC1 vocabulary, a lightweight
ontology which de nes ne-grained access control policies for
RDF data [
The Web Access Control vocabulary (WAC3) allows data
providers to specify access control lists de ned at RDF
document granularity (we grant access to speci c RDF data,
e.g. a few named graphs). Sacco and Passant [
Data. Moreover, the semantic technology adopted di ers, i.e.,
rule-based approach with description logic in their case and
SPARQL 1.1 in our proposal. Their contextual information
does not include the device dimension. Finally, their
solution is not meant to be a pluggable framework for SPARQL
endpoints. Flouris et al. [
Whenever a mobile application needs to access some
resources, the surrounding context (e.g. the physical
environment) must take part into the access evaluation procedure.
SPARQL queries must be associated with contextual data
for access evaluation, according to a proper model.
The choice and the design of a context model necessarily need
a context de nition rst: we agree on the widely-accepted
proposal by Dey [
Our work targets access control in the mobile Web of Data:
we need therefore a context model compliant with the Web of
Data paradigm. Our context-aware access control framework
adopts PRISSMA, a lightweight vocabulary originally designed
for context-aware adaptation of RDF data [
DisjunctiveACS
ConjunctiveACS prissma: class. To provide more exibility, the class can be used to model both user stereotypes and speci c users. prissma:Device represents the mobile device on which Web of Data resource consumption takes place, enabling devicespeci c access control. The class inherits from W3C Delivery Context Ontology 7 dcn:Device that provides an extensible and ne-grained model for mobile device features. prissma:Environment models the physical context in which the Web of Data resource consumption takes place. Di erent dimensions are involved in modelling the surrounding environment, delegating re nements and extensions to domain specialists. Location is modelled with the notion of Point of Interest (POI). The prissma:POI class consists in a simpli ed, RDFized version of the W3C Point of Interest Core speci cations8. Each prissma:POI consists of a geo:SpatialThing9 and can be associated with a given geo:Point coupled with a physical radius via the prissma:radius property. The properties prissma:poiCategory and prissma:poiLabel are used to assign a category and a label. Time is modelled extending the time:TemporalEntity class10. The prissma:descriptivePeriod property associates a description to each temporal entity (e.g. http://dbpedia.org/resource/Evening). Other dimensions are considered: the motion property associates any given high-level representation of motion to a prissma:Environment. The environmental proximity of a generic object can trigger di erent resource representations: nearby objects are associated with the Environment with the prissma:nearbyEntity property. The prissma:Activity class is a placemark aimed at connecting third-party solutions focused on inferring high-level representations of user actions (e.g.`running', `driving', `shopping', etc).
Example 1. Figure 2 visualizes a sample mobile context featuring all the dimensions described above. The user, Bob, knows Alice and is currently at work, near his and Alice's boss. Bob is using an Android tablet with touch display and is not moving.
Other context-related issues need to be considered beyond
context-model de nition, such as context fetch, context
trustworthiness and privacy. PRISSMA supports both raw context
data fetched directly from mobile sensors (e.g. GPS location,
mobile features) and re ned information processed on board
or by third-party, server-side services (e.g. POI resolution
or user activity detection). The present paper assumes that
context data is fetched and pre-processed beforehand.
The trustworthiness of contextual information sent by
mobile consumers should not be taken for granted. The
prissma:User's identity needs to be certi ed: this is an open
research area in the Web, and initiatives such as WebID11
speci cally deal with this issue. Hulsebosch et al. [
Context is sent to the data server along with the client query
for access evaluation (see Section 5 for details). Privacy
concerns arise while dealing with mobile user context. We
are aware that sensible data such as current location must be
handled with a privacy-preserving mechanism. In a previous
work, the myCampus experience [
THE CONSUMER'S
CONTEXT THE USER DIMENSION :dev1 a prissma:Device; hard:deviceHardware :dev1hw; soft:deviceSoftware :dev1sw. :dev1hw a hard:DeviceHardware;
dcn:display hard:TactileDisplay. THE DEVICE DIMENSION :dev1sw a soft:DeviceSoftware;
soft:operatingSystem :dev1os. :dev1os a soft:OperatingSystem;
common:name "Android". :env1 a prissma:Environment; prissma:motion "no"; prissma:nearbyEntity :ACME_boss#me; prissma:currentPOI :ACMEoffice. :ACMEoffice a prissma:POI; prissma:poiCategory example:Office; prissma:poiLabel example:ACMECorp. }
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
granularity of named graphs [
The model is grounded on the S4AC ontology (Figure 1). Our access control model is integrated with lightweight ontologies adopted in the Social Web and the Web of Data. In particular, S4AC reuses concepts from SIOC13, SKOS14, WAC, SPIN15 and Dublin Core16.
The main component of the S4AC model is the Access Policy, as presented in De nition 1. Roughly, an Access Policy denes the constraints that must be satis ed to access a given named graph or a set of named graphs. If the Access Policy is satis ed the data consumer is allowed to access the data. Otherwise, the access is denied. The constraints speci ed by the Access Policies may concern the data consumer, the device, the environment, or any given combination of these dimensions (see Section 3).
De nition 1. (Access Policy) An Access Policy (P ) is a tuple of the form P = hACS; AP; S; R; AECi where (i) ACS is a set of Access Conditions to satisfy, (ii) AP is an Access Privilege, (iii) S is the subject of the set of resources to be protected by P , (iv) R is the (set of) resource(s) to be protected by P , and (v) AEC is the Access Evaluation Context of P . 12The discussion about the use of named graphs in RDF 1.1 can be found at http://www.w3.org/TR/rdf11-concepts 13http://rdfs.org/sioc/spec 14http://www.w3.org/TR/skos-reference 15http://spinrdf.org 16http://dublincore.org/documents/dcmi-terms An Access Condition, as de ned in De nition 2, expresses a constraint which needs to be veri ed in order to have the Access Policy satis ed.
De nition 2. (Access Condition) An Access Condition (AC) is a condition which tests whether or not a query pattern has a solution.
In the S4AC model, we express Access Conditions as SPARQL 1.1 ASK queries. Note that no information is returned about the possible query solutions, just whether or not a solution exists.
De nition 3. (Access Condition veri cation) If the query pattern has a solution (i.e., the ASK query returns true), then the Access Condition is said to be veri ed. If the query pattern has no solution (i.e., the ASK query returns false), then the Access Condition is said not to be veri ed. Each Access Policy P is composed by a set of Access Conditions, as de ned in De nition 4.
De nition 4. (Access Condition Set) An Access Condition Set (ACS) is a set of access conditions of the form ACS = fAC1; AC2; : : : ; ACng.
Roughly, the veri cation of an Access Condition Set returns a true/false answer. We consider two standard ways to provide such an evaluation: conjunctively and disjunctively. De nition 5. (Conjunctive Access Condition Set) A Conjunctive Access Condition Set (CACS) is a logical conjunction of Access Conditions of the form CACS = AC1 ^ AC2 ^ : : : ^ ACn.
De nition 6. (Conjunctive ACS evaluation) A CACS is veri ed if and only if every contained Access Condition is veri ed.
De nition 7. (Disjunctive Access Condition Set) A Disjunctive Access Condition Set (DACS) is a logical disjunction of Access Conditions of the form DACS = AC1 _ AC2 _ : : : _ ACn.
De nition 8. (Disjunctive ACS evaluation) A DACS is veri ed if and only if at least one of the contained Access Conditions is veri ed.
We introduce the ACS, instead of using for instance the SPARQL UNION clause inside the ASK, because the idea is to de ne basic ACs with a simple and focused goal to allow their reuse by users without a SPARQL background. The second component of the Access Policy is the Access Privilege. The privilege speci es the kind of operation the data consumer is allowed to perform on the resource(s) protected by the Access Policy.
De nition 9. (Access Privilege) An Access Privilege (AP ) is a set of allowed operations on the protected resources of the form AP = fCreate; Read; U pdate; Deleteg.
We model the Access Privileges as four classes of operations to keep a close relationship with CRUD-oriented access control systems, allowing a ner-grained access control beyond simple read/write privileges. Moreover, we relate the four privilege classes to SPARQL 1.1 query and update language primitives through the SPIN ontology, which models the SPARQL primitives as SPIN classes. We show how this matching is actually used in Section 5.
As previously explained, policies protect data at named graph level. We o er two di erent ways of specifying the protected object: the provider may target one or more speci c named graphs, or a set of named graphs associated with a common subject. The former is achieved by providing the URI(s) of the named graph(s) to protect using the s4ac:appliesTo property. The latter is implemented by listing the subjects of the named graphs to protect using the property dcterms:subject. The assumption here is that named graphs have been previously annotated with such metadata. Summarizing, both S and R represent the data to protect, but R speci es the URI(s) of the named graphs, while S speci es the subject of the graphs (e.g., the policy protects the named graphs whose subject is Concert, http://dbpedia.org/resource/Concert).
Finally, the Access Policy is associated with an Access Evaluation Context. The latter provides an explicit link between the policy and the actual context data (in the case of the mobile context it is modelled with PRISSMA) that will be used to evaluate the Access Policy.
De nition 10. (Access Evaluation Context) An Access Evaluation Context (AEC) is a list of predetermined bound variables of the form AEC = (hvar1; val1i; hvar2; val2i; : : : ; hvarn; valni).
In this paper, we focus on the mobile context, thus the Access Evaluation Context list is composed only by a couple AEC = (hctx; U RIctxi). We map therefore the variable ctx, used in the policy's Access Conditions, to the URI identifying the actual mobile context in which the SPARQL query has been performed. More speci cally, we choose to implement the Access Evaluation Context as a SPARQL 1.1 BINDINGS clause to constrain the ASK evaluation, i.e. BINDINGS ?ctx {(U RIctx)}. However, the same result can be obtained by binding directly the variable ?ctx to the URI of the contextual graph.
The semantics of our Access Control Policies is mirrored in the semantics of the SPARQL language, in particular concerning the ASK query and the BINDINGS clause. The result of the veri cation of each access condition is composed, in case of multiple conditions, conjunctively or disjunctively 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 veri cation.
Con icts among policies might occur if the data provider uses Access Conditions with contrasting FILTER clauses. For instance, it is possible to de ne positive and negative statements such as ASK{FILTER(?u=<http://example#bob>)} and ASK{FILTER(!(?u=<http://example#bob>))}. If these two Access Conditions are applied to the same data, a logical con ict arises. This issue is handled in the framework by evaluating policies applied to a resource in a disjunctive way. We expect to add a mechanism to prevent the insertion of con icting policies as a future work.
Example 2. Let us consider the named graph :al:alice_reviews { ex:29900 a bibo:Article; dcterms:title "A great festival"; dcterms:date "2011"; dcterms:creator example:alice#me; bibo:abstract "Really enjoyed Coldplay". ex:29655 a bibo:Article; dcterms:title "Disappointed"; dcterms:date "2010"; dcterms:creator example:alice#me; bibo:abstract "Not up to the standards". } ice_reviews whose content is shown in Figure 3. We now present an example of Access Policy with a conjunctive Access Condition Set associated with a Read privilege (Figure 4). The policy protects the named graph :alice_reviews and allows the access to the named graph only if the consumer (i) knows Alice, and (ii) is not located near Alice's boss. Policy validation can be addressed in two di erent ways. First, the SPIN vocabulary can be used to express the literal representing the ASK query as RDF statements. On the other hand, we can perform a two-step validation, combining RDF validation for the policy and SPARQL validation for the literals of s4ac:hasQueryAsk, i.e. the ASK queries.
Our Access Control Manager is designed as a pluggable component for SPARQL endpoints (Figure 5). The access control ow is described below: 1. the mobile consumer queries the SPARQL endpoint to access the content. At the same time, contextual information is sent with the query and saved as a named graph using SPARQL 1.1 update language statements. Each time a context element is added we use an INSERT DATA, while we rely on a DELETE/INSERT when the contextual information is already stored and has to be updated. Summarizing, the mobile client sends two SPARQL queries: the rst is the client query aimed at
Query Contextual Information 3
Access Control
Manager
Access Enforc+ement
Policies Selection "secured"
Query 5
SPARQL endpoint
Datastore PAoclciceisess + Contextual
Graphs the datastore, the second provides contextual information (like the one visualized in Figure 2). 2. the client query is ltered by the Access Control Manager instead of being directly executed on the SPARQL endpoint. 3. the Access Control Manager selects the set of policies a ecting the client query and after their evaluation returns the set of named graphs the consumer is granted access to. 4. the client query is executed only on the accessible named graphs.
5. the result of the query is returned to the consumer. The aim of the Access Control Manager is twofold: it rst selects the Access Policies to assess and it veri es the set of Access Conditions included in the selected policies to grant or not the access. We describe the two algorithms to protect the access to the data (Figure 8).
Algorithm 1 is the main procedure for the execution of a query with access enforcement. The input of the algorithm is the client query Q and the RDF graph Gctx modeling 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 beginning, the set of accessible named graph N GS is empty (line 3). The selection of the Access Policies is addressed by the sub-routine Access Policies Selection (line 4), which returns the set of Access Policies the query is concerned by. Then, the algorithm runs all the Access Conditions composing the selected policies (lines 7-10). According to the type of Access Condition Set (i.e., conjunctive or disjunctive), for each veri ed policy, the associated named graph is added to the set of accessible named graphs (lines 11-12). Finally, after the execution of all Access Conditions, the client query is sent to the SPARQL endpoint with the addition of the FROM clause (line 16). Query execution is therefore performed only on the accessible named graphs, given the consumer contextual information. Line 18 outputs the triples resulting from Q.
Algorithm 2 is the Access Policies Selection routine. It selects the Access Policies concerned by the client query. The input of the algorithm is the query Q and the repository of the policies AP S. We do not want to verify all the Access Policies every time a query is run. Thus, we adopt a selection mechanism to obtain only a subset of Access Policies to PREFIX ctxgraphs: <http://example/contextgraphs/> ASK{?context a prissma:Context.
?context prissma:user ?u. THE CONSUMER'S ?u foaf:knows ex:alice#me.} CONTEXT
BINDINGS ?context {(ctxgraphs:bobCtx)} ASK {?context a prissma:Context.
?context prissma:environment ?env. ?env prissma:based_near ?p.
FILTER (!(?p=ex:ACME_boss#me))}
BINDINGS ?context {(ctxgraphs:bobCtx)} execute. In particular, the algorithm maps the client query to one of the four access privileges S4AC de nes using the SPIN vocabulary (line 1). Then, the algorithm selects all the Access Policies which have the identi ed Access Privilege (lines 3-7). The selected policies are returned to the main Access Enforcement algorithm (Algorithm 1).
Example 3. An example of client query is shown in Figure 7.a, where Bob wants to access all rock festival's reviews from the context described in Figure 2. When the query is received by the Access Control Manager, the latter selects the Access Policies concerning this query (for instance the policy shown in Figure 4). The Access Conditions included in the policies are then coupled with a BINDINGS clause, as shown in Figure 6, where the ?context variable is bound to Bob's actual context. The identi cation of the named graph(s) accessible by Bob returns only the graph :peter_reviews. The named graph :alice_reviews of Figure 3 is forbidden because Access Conditions evaluation leads to a false answer with Bob's context (Bob is near Alice's boss). The Access Control Manager adds the FROM clause to constrain the execution of the client query only on the allowed named graph. The \secured" client query is shown in Figure 7.b. Algorithm 1: Query Execution with Access Enforcement
To assess the impact on response time, we implemented the
Access Control Manager as a Java EE component and we
plugged it to the Corese-KGRAM RDF store and SPARQL
1.1 query engine17 [
In Figure 9 we execute 10 independent runs of a test query batch consisting in 50 identical queries of a simple SELECT over bsbm:Review instances (tests are preceded by a warmup run). We measure the response time with and without access control. When executed against the Access Control Manager, the test SPARQL query is associated with the mobile context described in Figure 2. Each Access Policy contains exactly one Access Condition. In Figure 9.a, to simulate a worst-case scenario, access is granted to all named graphs de ned in the base (i.e. all Access Conditions return true), so that query execution does not bene t from cardinality reduction. Larger datasets are less a ected by the delay introduced by our prototype, as datastore size plays a predominant role in query execution time (e.g. for 4M triples and 100 always-true 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 17http://tinyurl.com/corese-engine 18http://bit.ly/berlin-sparql on performance for various levels of cardinality reduction, using modi ed versions of the BSBM dataset featuring a larger amount of named graphs (we de ne a higher number of bsbm:RatingSites, thus obtaining more named graphs). When access is granted to a small fraction of named graphs, the query is executed faster than the case without access control (e.g. if access is granted to only 1% of named graphs, the query is executed 19% faster on the 1M triple test dataset). As more named graphs and triples are accessible, performance decreases. In particular, response time is a ected by the construction of the active graph, determined by the merge of graphs in FROM clauses. As shown in Figure 9.b, the cost of this operation grows with the number of named graphs returned by the evaluation of the Access Policies. In Figure 9.c we analyse the overhead introduced on response time by queries executed in dynamic mobile environments. We execute independent runs of 100 identical SELECT queries, dealing with a range of context change probabilities. In case of a context update, the query is coupled with a SPARQL 1.1 update (Section 5). Not surprisingly, with higher chances of updating the context, the response time of the query grows, since more SPARQL queries need to be executed. The delay of INSERT DATA or DELETE/INSERT operations depends on the size of the triple store and on the number of named graphs (e.g. after a DELETE query, the adopted triple store refreshes internal structures to satisfy RDFS entailment). Performance is therefore a ected by the number of active mobile users, since each of them is associated with a mobile context graph.
Accessing the Web of Data needs an access control mechanism. Moreover, consumption and production of linked data might origin from mobile devices immersed into pervasive environments. This paper presents an approach towards context-aware access control for the ubiquitous Web of Data. The proposed solution is conceived as an easy-to-integrate pluggable lter for data servers that support the SPARQL query language. Our framework relies only on Web of Data languages and existing vocabularies; no other formalism has been added. The prototype evaluation shows that, despite the overall performance needs to be ameliorated, the delay introduced by our ne-grained, context-based access control is acceptable given that data protection comes with a cost. Future testing campaign will be carried out to provide a thorough evaluation with other SPARQL query engines, such as Virtuoso, Sesame, Jena and AllegroGraph. An e ective backend user interface to de ne Access Policies has to be designed, as user interaction issues should not be underestimated. The trustworthiness of the information sent by the mobile consumer, including data describing context (e.g. location, device features, etc.) should not be taken for granted: future work needs to investigate this issue. Privacy concerns arise while dealing with mobile user context. We are aware that sensible data such as current location must be handled with a privacy-preserving mechanism, and we will therefore focus on this issue in the future.