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).


Real-time Web

Behind the idea of the Real-time Web is the motivation of the Web being situation-aware and in real-time. This idea was developed as a grand challenge 1 for the field of event processing. The purpose of this challenge is "to identify a single, though broad challenge that impacts society and at the same time measures the progress of research" 1. The challenge is to create a decentralized, global, Internet-like infrastructure, built upon widely-accepted open standards 1.

There are a number of terms (synonyms) given for a Web which is situation-aware. Examples are Real-time Web 2, Web of Events 3, Active Web 4, Reactive Web5 and Event Processing Fabric 1.

They have in common that data must be exchanged quickly after it is created. Moreover, Fromm 2 states that the Real-time Web (i) is a new form of communication which (ii) creates a new body of content, (iii) is real-time, (iv) is public and has an explicit social graph associated with it and (v) carries an implicit model of federation. Indeed, this work makes a contribution to the Real-time Web by enabling a new form of communication using event processing, working in real-time and supporting federated data-creation and consumption.

There are many technological developments on the Web today which can create a lot of events and thus support a Real-time Web. Such events are delivered in a push fashion as opposed to the traditional client–server Web of request and response. For one, there is the W3C Web Notification Working Group which is working on push notifications to actively notify running Web applications. Additionally, HTML5 defines two techniques to facilitate communication initiated by the server. These techniques are Server-Sent Events and WebSockets. They operate at different layers of the protocol stack to achieve push delivery to Web clients. Another approach to push-data on the Web is the Google PubSubHubbub protocol to enable mainly server-to-server notifications. It is designed to avoid inefficient polling of news feeds in Atom or RSS. Lastly, the Facebook Graph API provides an application-specific way to subscribe to Facebook real-time updates from changes to connected people’s profiles.

  1. Chandy, K. M.; Etzion, O. & von Ammon, R. (Eds.) 10201 Executive Summary and Manifesto — Event Processing Event Processing, Schloss Dagstuhl – Leibniz-Zentrum fuer Informatik, Germany, 2011 
  2. Fromm, K. The Real-Time Web: A Primer, 2009 
  3. Jain, R. Toward EventWeb IEEE Distributed Systems Online, IEEE Computer Society, 2007, 8 
  4. Ostrowski, K.; Birman, K. & Dolev, D. Live Distributed Objects: Enabling the Active Web IEEE Internet Computing, IEEE Educational Activities Department, 2007, 11, 72-78 
  5. Bry, F. & Eckert, M. Twelve theses on reactive rules for the web Proceedings of the Workshop on Reactivity on the Web, Munich, Germany, Springer, 2006