RDF Access Control

There are several approaches to modelling access control using RDF. The approaches use RDF as a modelling language for permissions linking users with user’s rights on the one hand and on the other hand are used on RDF data granting access to users (linking permissions with data). All approaches grant access to RDF resources while assuming what is not granted is forbidden.

Related Work

The S4AC Vocabulary Specification 0.21 defines access rights tailored towards RDF query answering, i.e. SPARQL processing. The vocabulary defines access rights Create, Read, Update and Delete. The model is very expressive by allowing fine-grained access condition modelled as contextual queries against arbitrary context data to check. However, the integration with SPARQL is not applicable for our system as not all operations require a query such as a plain subscription to a stream.

SIOC Access is a part of the SIOC specification2. It is a very simple but extensible vocabulary to define permissions in the scope of the social Web. The vocabulary does not have any predefined rights. The lack of rights, the focus on social communities and its lack of traction on the Web are the drawbacks of this candidate when choosing a model for access control in our system.

The W3C WebAccessControl (WAC)3 is a generic vocabulary declaring some predefined rights (Read, Write, Append, Control) on Web information resources. Streams in our system are information resources so the vocabulary can be used without change. Access rights must be extended for our system to govern the real-time access Notify and Subscribe in addition to the predefined rights Read and Write for static data.

Our System, Using Access Control for Streaming Data

Data in our system4 is organized in streams (cf. topic-based publish/subscribe). Attributing access control on a per-stream granularity was chosen. Finer granularity such as per-event attribution was discarded. The expected performance impact at runtime was thought to be unnecessarily high when having to check each event for each of its recipients before delivery. Coarser granularity such as granting access to all streams at once, however, was contradicting our requirement for multitenancy without having the ability to separate users.

After analysing the existing RDF models for access control mentioned above we concluded that W3C WebAccessControl was the most viable candidate of the three available candidates S4AC, SIOC Access and the W3C WebAccessControl. Reasons were its traction on the Web, its generality, and its ease of use compared to the other candidates (e.g. linking permissions with plain RDF resources instead of complex SPARQL queries to define rights).

The figure below shows the concepts of WebAccessControl (WAC). The bottom of the figure shows that a single permission (Authorization in WAC terms) is a ternary relation. It consists of an agent (who can access), an information resource (what) and a mode (how), cf. middle line of the figure. An example ternary relation is: Roland can access the TwitterFeed with permissions Subscribe and Read. The top left of the figure shows an agent can be either a group or an individual user’s account. User accounts can be members in groups. If accounts are defined in several locations, they can be declared to be the same.

Access Control Lists

In the figure the concepts from the WAC vocabulary are highlighted in blue colour. WAC has predefined access rights Read and Write for static data, cf. top right of the figure. For the use with real-time data we extended WAC with the rights Notify and Subscribe. The classes on white background in the figure are defined as part of this work. Finally, the classes in yellow are from the SIOC vocabulary.

The following listing in Turtle syntax shows two example authorizations p0001 and p0002 in the namespace permission starting on line 10 and 15. A user person:rs who is member of the group group:administrators is shown starting on line 20. Both permissions exhibit the ternary relation between who, what and how access is granted. The first permission states that Roland (rs) can access the TwitterFeed with permissions Subscribe and Read. The second permission states that group:administrators can access the FacebookStatusFeed with permission Write.

@prefix acl: .
@prefix foaf: .
@prefix group: .
@prefix permission: .
@prefix person: .
@prefix s: .
@prefix sioc: .
@prefix wsnt: .

acl:accessTo s:TwitterFeed ;
acl:agent person:rs ;
acl:mode wsnt:Subscribe , acl:Read .

acl:accessTo s:FacebookStatusFeed ;
acl:agent group:administrators ;
acl:mode acl:Write .

sioc:member_of group:administrators ;
owl:sameAs .

When defining permissions, the streams are modelled as information resources (e.g. http://.../TwitterFeed on line 11 without the trailing #stream). Elsewhere, streams are modelled with their non-information resource (e.g. http://.../TwitterFeed#stream). Making this distinction (cf. the so-called httpRange-14 issue) we can attribute different metadata to the information for the stream (e.g. annotate permissions) and to the real-world stream (e.g. annotate its real-world event source or author).