The structure of the Semantic Web gives users the power to share and collaboratively generate decentralized linked data. In many cases, though, collaboration requires some form of authentication and authorization to ensure the security and integrity of the data being generated. Traditional authorization systems that rely on centralized databases are insu cient in this scenario, since they rely on the existence of a central authority that is not available on the Semantic Web. In this paper, we present a scalable system that allows for decentralized user authentication and authorization. The system described supports per-document access control via an RDF metadata le containing an access control list (ACL). A simple interface allows authorized users to view and edit the RDF ACL directly in a Web browser. The system allows users to e ciently manage read and write access to linked data without a centralized authority, enabling a collaborative authoring environment suited to the Semantic Web.
In the Semantic Web community there is a growing interest in collaborative authoring of linked data. In most collaborative environments, though, there must be an adequate authorization system in place to restrict which users can view and edit certain data. When designing such a system for use on the Semantic Web, the following important factors must be taken into account: Decentralized accounts. On the Semantic Web, data is stored on many machines in a decentralized manner. Requiring users to have separate accounts for each server that they edit data on would quickly become cumbersome; instead, having a single user identity would be ideal. Additionally, such a sign-on system should not be located on a centralized server. Instead, users should be able to maintain their own accounts on remote servers.
ts of the Semantic Web is the power to reason over data provided by multiple
sources. A good system should allow administrators to create rules for
authorization, such as \Only my friends and friends of my friends can access my data".
Authentication speed. Even though a decentralized authentication
mechanism will by design require that information be pulled down from a remote
server, the speed of the authentication itself should still be at least comparable
to traditional authentication mechanisms. To achieve this, the system should
ideally only need to make one request to a remote server in order to complete
authentication. Following this initial authentication, session caching should be
used to prevent repeated requests to remote servers, making repeated
authentication steps e ectively identical in speed to traditional authentication methods.
Ease of maintenance. The system should allow authorized users to intuitively
add and remove access for other users. Since the access control system is intended
for data shared on the Semantic Web, any ACL should also be editable from a
Web browser. This could potentially be accomplished using protocols such as
WebDAV [
The system we have implemented allows for decentralized accounts, fast authentication, and easy maintenance of ACL metadata. Support for rule-based authorization is not currently included in favor of a simpler ACL-based implementation, but we will show that support for such reasoning could be added. The resulting system allows users to collaboratively edit linked data stored on the Web server.
The remainder of the paper discusses our experiences in implementing and assessing our system. In Section 2, we brie y introduce the prior work that our system is based on. In Section 3, we describe the back-end system that allows for decentralized authentication and ACL-based authorization. Section 4 describes the interface for viewing and editing access control les. Finally, Sections 5, 6, and 7 discuss the performance of our implementation and potential future work that would expand and improve on the present system. 2
In this section, we brie y discuss the prior work related to our system and how that work a ected our design. 2.1
This is not the rst attempt at creating an RDF-based ACL system. Since 2002,
the World Wide Web Consortium (W3C) has used an RDF-based ACL system
[
Despite this, the W3C ACL system provides a strong base for developing a similar system for use on the wider Semantic Web. The major di erence between the W3C ACL system and our system is the prominence of linked data and standardized protocols. By moving all user and group data onto the Semantic Web and using a common login mechanism, we allow for access rules to be shared more readily between di erent organizations. 2.2
We identi ed two potential options for allowing collaborative authoring of les in our system: WebDAV and SPARQL/Update. Both have distinct advantages and disadvantages. As far as support for linked data, SPARQL/Update is the clear choice: it supports insertion and deletion of small amounts of data from the target graph. WebDAV, on the other hand, is not explicitly intended for authoring linked data documents. Instead, when performing a WebDAV PUT, the entire document must be rewritten to the server. If there were no other limiting factors, SPARQL/Update would be the obvious choice.
However, due to our desire to produce a usable Apache [
There exist two potential methods for performing decentralized authentication:
OpenID [
Brie y, the FOAF+SSL protocol works as follows: a user's public encryption key is stored in both a certi cate and a remote RDF le stored on a Web server. Additionally, the certi cate is created with the URI for the location of the remote RDF le stored in the certi cate's Subject Alternative Name eld. When a user sends a FOAF+SSL certi cate to a server, the server identi es the remote URI, pulls down the public key from that URI, and compares it with the public key in the user's certi cate. If the keys match, the user is authenticated as the entity associated with the (public key,remote URI) pair described in the certi cate. The server can then decide whether or not to authorize a user based on a set of rules{in our case, a simple access control list. By using self-signed certi cates, FOAF+SSL provides a trust-based user network that does not rely on any central authority, which by design works perfectly in a Semantic Web environment. 3
In this section, we describe the server-side implementation of our access
control system. The server is implemented as two Apache modules: an authentication
module (mod authn webid) and an authorization module (mod authz webid).
The general ow of the authentication and authorization process is depicted in
Figure 1.
The authentication module implements the FOAF+SSL protocol to determine if
the public keys in the user's certi cate and FOAF le match. Authentication via
this module is enabled in the server's Apache con guration with the AuthType
WebID Apache directive. To perform authentication, the module checks for a
URI in the Subject Alternative Name eld of the certi cate. Next, the certi
cate's signature is calculated using Apache's mod ssl [
?mod cert:hex ?mod_hex. } that matches the key and agent provided in the user's certi cate, the module authenticates the user as acting on behalf of the agent and returns control back to Apache. 3.2
The authorization module makes use of an N3 [
The three types of access that can be granted are Read, Write, and Control. Each type of access is bound to a speci c set of HTTP methods as described in Table 1. The Read and Write modes control access to normal les stored on the server. Control is essentially a special form of Write access: having Control access to a le allows a user to edit the ACL metadata for that le. As with the authentication module, authorization is determined by running a set of SPARQL queries to determine if the user is granted access either as an agent or as a member of an agent class. If a user attempts to use an HTTP method that they are not permitted to use, they receive a 403 response from the server. For example, using the ACL le from Figure 3, if a user authenticated with the URI http://www.example.com/foaf#me tried to delete foaf.rdf with an HTTP DELETE request, the server would see that only presbrey has Write access and respond with 403 Forbidden. @prefix acl: <http://www.w3.org/ns/auth/acl#> . [] a acl:Authorization ; acl:defaultForNew <.> ; acl:accessTo <foaf.rdf> ; acl:agent <http://presbrey.mit.edu/foaf#presbrey> ; acl:mode acl:Control, acl:Read, acl:Write . a acl:Authorization ; acl:accessTo <foaf.rdf> ; acl:agentClass <http://xmlns.com/foaf/0.1/Agent> ; acl:mode acl:Read. To demonstrate the functionality of the ACL editing system, we have developed a simple Firefox extension that allows users to edit the ACL for the document they are currently viewing. The extension is a sidebar that can be loaded alongside the current browser window. The ACL metadata for a given document is found by looking for the aforementioned link rel=meta HTTP header in the server's response for a given document. The metadata URI in the link header is dereferenced, and the ACL is displayed to the user as a list of agents and agent classes (See Figure 4).
Authorized users are able to modify the ACL directly in this interface by manipulating a series of checkboxes. New agents can be added, and current agents can be removed. When a user attempts to submit new ACL data, the interface serializes the state of the interface into a new ACL le. This modi ed le is then submitted to the server via a WebDAV PUT. Concurrent ACL modi cations are prevented optimistically using the HTTP ETag header. Successful changes to the ACL take e ect immediately. Though the FOAF+SSL authentication mechanism requires that the server make a request for a remote resource in order to perform authentication, it would be ideal for our system to nevertheless achieve performance comparable with traditional authentication mechanisms. To that end, we have performed performance tests in order to compare our authentication mechanism with traditional Apache authentication methods. The tests were run using ApacheBench, included with Apache, on an Apache instance running in single-process mode on a Quad-Core AMD Opteron 2350 2GHz Xen VM guest with 512MB of RAM. ApacheBench performed 1000 serial requests for a null document in each con guration. The four test con gurations used tested the time needed for Apache to complete authentication requests depending on whether or not a certi cate is presented and whether or not our authentication module is enabled. Table 2 shows the average performance of each con guration over the course of ve test runs. Apache Test Con guration Request Time (ms/request) without client certi cate, without mod authn webid 4.2 without client certi cate, with mod authn webid 4.43 with WebID client certi cate, without mod authn webid 4.63 with WebID client certi cate, with mod authn webid 11.31
Table 2. Benchmark results for mod authn webid.
The results clearly show that the module takes a few milliseconds to request the remote resource containing a user's certi cate information. In this case, the request time is relatively short, since the two machines were sitting quite close to each other. With the addition of a WebID cache, though, the need for repeated requests for remote resources has been removed{a cached version of the agent's data is used instead for the duration of a session. In many cases, the inital request will not have very high latency, as in this example. But even in those cases where an initial request takes some time, subsequent requests will run at a speed comparable to normal certi cate-based authentication, since the remote request is not repeated. 6
With our rst WebID- and Linked Data-based authorization system, we have created a highly functional codebase allowing for collaborative editing of Semantic Web documents. In this section, we describe a list of potential future enhancements that would greatly increase the ease with which users could edit data. 6.1
Our current implementation uses WebDAV to allow for collaborative editing.
However, this is by no means a requirement of the system. Over time, more
systems are coming into existence that support SPARQL/Update for editing
documents in an Apache environment, such as ARC2 [
While we currently provide access control at the document level, RDF is often stored as multiple resources described in a single at le or in a triple store that does not even have a notion of speci c documents. The current system is not able to restrict access on a per-resource basis unless resources are each stored in their own le. Such a system would require more complex analysis of an incoming update or query to determine exactly which resources are being read and written. While this feature is not included at present, it is worth noting that the ACL system used here could be modi ed to accommodate access de ned on a per-resource basis. The rst step in implementing such a system would probably be to have an engine capable of analyzing SPARQL/Update queries to decide which resources they a ect.
Of course, one of the most di cult parts of adding per-resource access control is identifying exactly what it means for a read or write operation to \a ect" a resource. A simple engine could designate a read or write operation as pertaining to a certain resource if the operation traverses or modi es an arc coming out of that resource. In this case, adding a \has child" property to a parent would be considered a write modi cation to the parent, but not its new child. Some examples, however, can have greater consequences for a given resource. For example, if a user has write access to a class de nition C, but is not granted write access to one of C's subclasses, the user could still greatly alter (or even break) the semantics of that subclass by simply modifying C. The importance of this issue will vary between use cases{for someone maintaining an open social network, the rst method may be more appropriate; but for someone editing ontologies, maintaining consistency will be key. 6.3
This project uses a very simple form of access control{a simple whitelist contained in a metadata le. However, some users might want to de ne dynamic rules like the \friend-of-a-friend" rule described in the introduction. While such rules are certainly more descriptive than a whitelist, designing an interface that allows users to quickly modify rules and add new agents as our ACL Editor does is much more di cult. On the back-end, however, one would simply need to hook into a rule engine immediately prior to authorizing a user. At this point, our system exposes a user's URI and the query that the user is trying to run. This information could easily be plugged into an external reasoner to decide if the user is permitted to perform a given action or log the user's actions for later analysis. It should also be noted that using complex rules to regulate access to resources in a triple store could greatly a ect the speed of the authentication process, since a proof would need to be constructed instead of searching for the appropriate triple indicating access. 7
The system described provides a solid base for future projects implementing Web Access Control and collaborative authoring of linked data. It provides an implementation of an RDF-based decentralized authentication protocol, namely FOAF+SSL. Authentication speeds, keeping in mind the need for an initial remote request, are comparable with traditional authentication systems. Users can quickly and easily add access for new agents without having to manually edit a metadata le.
That such a system can be implemented on a traditional Web server like Apache shows that there is potential for widespread adoption of accountable collaborative editing of linked data. The layout of this system allows for applications, linked data, and user agent authentication to all be stored on separate servers maintained by completely independent entities. By plugging services such as policy-aware query processors and data access logs into our system, one could create a complete policy-aware system based in an entirely decentralized environment, realizing the full potential of the Semantic Web. Acknowledgments Thanks go to the members and students of DIG and the W3C who provided excellent knowledge and feedback throughout the course of this project. This work was supported by IARPA Award #FA8750-07-2-0031 and National Science Foundation Cybertrust Grant award CT-M: 0831442.
The source code for this project is available at the following locations: Authentication Module: http://dig.csail.mit.edu/2009/mod_authn_webid/ Authorization Module: http://dig.csail.mit.edu/2009/mod_authz_webid/ ACL Editor: http://dig.csail.mit.edu/2009/aclsidebar/