One of the current barriers towards realizing the huge potential of Future Internet is the protection of sensitive information, i.e., the ability to selectively expose (or hide) information to (from) users depending on their access privileges. In this work we discuss the experiments conducted with our repository independent, portable across platforms system that supports ne-grained enforcement of RDF access control.
We concentrate on ne-grained RDF access control for read-only queries. An
access control permission is used to explicitly grant or deny to/from a given
user the ability to access an RDF triple, or a set of RDF triples, and can be
viewed as a query whose evaluation over an RDF graph results in a set of triples
which are accordingly granted or denied access. Access control permissions are
expressed using SPARQL [
Architecture: We implemented a main memory platform which serves as an additional access control layer on top of an arbitrary RDF repository. Our goal was for our system to be portable across platforms, so it was designed in a repository-independent way. The system's architecture is shown in Fig. 1. It is comprised of the following modules, all implemented in Java: the RDF Dataset Loader, responsible for loading the complete RDF dataset in the underlying repositories, the RDF Access Control Policy Manager that loads in memory the access control policies and the RDF Access Control Enforcement Module, which translates the access control policies into the appropriate programs that compute the accessible triples of an RDF dataset and annotates accordingly the data in the repositories with accessibility information.
To enforce an access control policy we produce a RDF access control query which implements the policies semantics of the policy and is expressed in the language RDPFolAiccycMesasnCaognetrrol policy ERnDfoFrAcecmceesnstCMoondtruolle supported by the underlying repository. The triples in the result of the evaluation of this datRaDsFet RDF Dataset Loader SPARQL Query query on the RDF graph are SPARQL UpSdaetreql QuerySQL query exactly the accessible triples
which are then annotated as RDF triples RDF triples reprreelsaetnitoantailon tsiuocnhs. cCanoncbeeptrueaplrleys,enatnendotbay
Jena of RDF triples adding a fourth column to an A SemantifcoWrJeabvFaramework RDF triple (hence obtaining a quadruple), denoting whether the triple is accessible or not;
Fig. 1. System Architecture if several di erent user roles
need to be supported, one column per role should be added. Annotations can
be stored using the named graphs mechanism of RDF repositories [
Experiments: Our experiments measured the time required to annotate the
set of RDF triples, using the above methodology, in state-of-the-art RDF
repositories (Sesame [
14 12 10 )sce 8 !( iem 6 T 4 2 0 0,5 1 1,5 2 2,5 3 3,5 4
Document!size!(MB) !
SeRQL SparqlJena SparUL SparqlJenaSDB ! (b) gp = 2,doc = 4M B
(c) ps = 80, doc = 4M B
We measured the time required for the annotation as a function of four di erent parameters: (i) document size (doc), i.e., the size of the input RDF graph (size ranging between 500KB-4MB with a 500KB increase); (ii) policy size (ps), i.e., the number of permissions in the access control policy (for sizes of 10, 20, 40, 80 and 100, with an equal share of positive/negative permissions in each case); (iii) permission size (gp), i.e., the number of triple patterns and constraints in the where clause of each access control permission (values considered: 2, 5, 10); and (iv) policy parameters, i.e., the values of the ds; cr parameters of the input policy (all 4 combinations considered).
Evaluation: Fig. 2 shows a subset of the results of our experiments: we run each experiment 5 times, and took the average time. In each graph, the annotation time is presented as a function of one of the parameters (i)-(iv), for xed values for the other parameters. We report here on policies with \deny" as default semantics (ds) and con ict resolution policy (cr) because it is the most common one. The results show that our approach scales along the considered parameters. All the platforms that we ran our experiments on demonstrated a linear behavior as document, policy sizes and permission complexity increased (except the Jena SPARUL and SPARQL Modules).