SHI3LD

Context-Aware Authorization for Graph Stores

Luca Costabello, Serena Villata, Fabien Gandon, Nicolas Delaforge

In the Web of Data providers expose content publicly, knowing that it is not safe. This may prevent further publication of datasets, at the expense of the growth of the Web of Data itself.

Mobile, ubiquitous Web is continuously evolving, enabling new scenarios in consuming and contributing to the Web of Data. We must therefore not ignore the mobile context in which data consumption takes place.

Looking for Shi3ld for HTTP instead?

Shi3ld Access Policy Manager Demo

Watch in High Definition on Vimeo

Direct download (HD, 40.2 MB)

Direct download (SD, 16.7 MB)

Enabling Techs

Named Graphs

The access control model is built over the notion of Named Graph (enforcing permission models is an envisioned use case for RDF named graphs). We rely on named graphs to avoid depending on documents (one document can serialize several named graphs, one named graph can be split over several documents, and not all graphs come from documents). At conceptual level, our policies can be considered as access control conditions over g-boxes (according to W3C RDF graph terminology)

Context Awareness

On-board sensors enable new scenarios in consuming the Web of Data from mobile. The choice and the design of a context model necessarily need a context definition first. We agree on the widely-accepted proposal by A. K. Dey:

"Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered rele- vant to the interaction between a user and an application, including the user and applications themselves."

A. K. Dey. Understanding and using context. Personal and Ubiquitous Computing, 5(1):4–7, 2001.

SPARQL 1.1 Semantics

We protect RDF stores by changing the semantics of incoming SPARQL queries, whose scope is restricted to triples included in accessible named graphs only. We use SPARQL Update language as access primitives, ASK as access conditions. and BINDINGS to contextualize conditions.

Features

Triple-Level Granularity

Data is protected with fine granularity, thanks to RDF named graphs adoption.

Mobile Context in the Loop

Our context-aware access control framework adopts PRISSMA, a lightweight vo- cabulary originally designed for context-aware adaptation of RDF data

Semantic Web Languages Only

We adopt exclusively Semantic Web languages and reuse existing proposals, thus we do not add new policy definition languages, parsers nor validation procedures.

Plug it to any RDF Store

Our proposal has the advantage of being a pluggable filter for generic SPARQL endpoints, with no need to modify the end- point itself.

Model

Our system relies on two complementary lightweight vocabularies: S4AC deals with core access control concepts and PRISSMA focuses on the mobile context.

For more info on used vocabularies, visit the S4AC namespace document and the PRISSMA namespace document.
datamodel

How it works

The RDF datastore must be previosly partioned in Named Graphs.

Preliminary Step: Policy Definition

Access Policies must be defined as a preliminary step, to protect named grpahs. Each Access Policy is associated to a privilege level and includes a set of context-aware Access Conditions, i.e. constraints that must be satisfied, conjunctively or disjunctively, to access the protected resources.

Example 1

What follows is a sample access policy defined on the named graph :ng1. It allows read access to :ng1 content if the user is located in a given geographic area, with a radius of 500m. 
  :policy1 a s4ac:AccessPolicy;
  s4ac:appliesTo :ng1;
  s4ac:hasAccessPrivilege [a s4ac:Read];
  s4ac:hasAccessConditionSet :acs1.
  
  :acs1 a s4ac:AccessConditionSet;
  s4ac:ConjunctiveAccessConditionSet;
  s4ac:hasAccessCondition :ac1.
  :ac1 a s4ac:AccessCondition;
  s4ac:hasQueryAsk
  """ASK {?context
	    a prissma:Context; 
		  prissma:environment ?env.
	  ?env prissma:currentPOI ?poi.  
	  ?poi prissma:radius "500";
		   foaf:based_near ?p. 
	  ?p geo:lat "43.615811";
		 geo:long "7.068532".}""".

The above :policy1 protects the named graph :ng1 from read access such as SELECT, ASK (s4ac:Read privilege). The access condition set :acs1 includes only one access condition, :ac1. The access condition allows access only if the user is located in a point of interest (POI) at given geo coordinates.

1. Query Contextualization

Context data is fetched by mobile sensors. Device, Enviroment and User information is associated to the SPARQL query to protect. This data is saved in the triple store as a named graph.

For further information on how to model context see the PRISSMA vocabulary namespace document.

2. Access Policy Evaluation

The Access Control Manager selects the set of policies affecting the client query, i.e. those with a matching Access Privilege. This is achieved by mapping the client query to one of the four Access Privileges defined by S4AC with the SPIN vocabulary. The Access Conditions (SPARQL ASK queries) included in the selected policies are executed. According to the type of Access Condition Set (i.e., conjunctive or disjunctive), for each verified policy, the associated named graph is added to the set of accessible named graphs .

More info on S4AC access control vocabulary on the vocabulary namespace document.

3. Query Execution

The client query is sent to the SPARQL endpoint with the addition of the FROM clause(s). Query execution is therefore performed only on the accessible named graphs, given the consumer contextual information.

Publications

Contacts

Luca Costabello, Serena Villata, Fabien Gandon, Nicolas Delaforge