The efficient implementation of a Semantic Web application particularly depends on the underlying RDF API and triple store. Today's RDF triple stores are mostly build upon relational database management systems with dedicated database schemata and corresponding API methods which rewrite knowledge base queries into database queries (e.g. [1] and [2]). However, access control at the level of the underlying relational database lacks granularity if based on the entities table, row and database. There exist APIs which do not depend on a relational database (e.g. Redland [3] and Sesame [4]) but also when basing on them, the Semantic Web application has to establish access control mechanisms on their own.
We are convinced, that future RDF triple stores will be used as backends for application systems in analogy to existing relational databases. Assuming this, it is important to develop access control methods which do rely on the RDF data model and enable access controll with respect to metamodels based on the RDF data model, such as RDF-Schema and the different OWL flavors. A longer term aim is to make such methods integral part of future triple stores.
To have a more solid starting point for the formulation of requirements we selected the application scenario of Semantic Wikis. We define a Semantic Wiki as a collaborative software for modifying a shared knowledge base. Further, we assume this knowledge base to be an RDF graph which consists of RDF triples. A Semantic Wiki supports the collaborative process of instance acquisition and curation with respect to an often fuzzy and not well defined goal. This definition does not make any assumptions about the user frontend, because these wiki design principles are defined in [5] and are independent of the prefix "semantic".
In a 'classic' wiki we are used to think in access categories like account and page: an account has certain rights with respect to a page1 . The specific rights which can be granted or revoked are typically the rights to read, modify, delete and annotate the page and to grant such rights for this page to some other account.
Further, pages can be arranged in a page tree, which makes the application of access control rules on a page subtree necessary. For a Semantic Wiki, the base entities we have to consider are not accounts and pages but sets of triples. Also, accounts and annotations can be identified using URI references and information about them represented as triples. Hence, access control should work on the granularity level of triples as well as on higher levels, such as the description of a resource (i.e. all triples having the same subject) or instances of a certain class.
Based upon our Semantic Wiki definition and the work with our prototype 3ba.se [6] we identified the following requirements for access control on the underlying RDF triple store:
-Efficiency and scalability should have precedence over expressive power. In modern web applications with complex and dynamic user frontends, query processing has to be as fast as possible. This requirement is more important than expressive power of the access control language since there are usually hundreds of queries to the store triggered by a single web request. -As a minimal requirement we need context-and content-sensitive triple filtering in a declarative way. This means the access to a tiple set depends on the accounts metadata (e.g. membership information) as well as on the content of the wanted triple set itself (e.g. enforce to give all needed attributes to some resource). -Access control declaration should be able to use organisational information like command structure and group membership information from inside the controlled or another RDF model. For the most common architectures used for the storage of organisational data inside a company etc., methods exist to migrate or RDF-ify such organizational memory (e.g. [7] for relational databases and [8] for LDAP directories). It should be possible to use this data to express access control declarations.
In the next section we survey shortly existing research projects which are related to the topic of access control on RDF triple stores.
The research field policy management for the Semantic Web addresses machine interpretable policies to control programs, services and agents on the Web. It is not restricted to security and privacy but also tackles problems related to trust (e.g. trust in resource quality or agents), information filtering, accountability and others. An overview of the current projects is available in the workshop proceedings [9] and [10]).
However, most projects have a different intentions than this work. A policybased management framework in the sense of [11] aims at an open semantic network environment. In this network the behavior of agents and services is controlled by reasoned decisions over policies. This is necessary due to the complexity of the global approach of controlling all possible agents and services with all possible actions. An example for such a system is Rei [12] which supports specification of policies, analysis and reasoning in pervasive computing applications.
Due to the fact that reasoning procedures are still not scalable to scope with larger knowledge bases, such capabilities can not applied in RDF triple stores today. Another objection to reasoning is the open world assumption, because no external sources are used and access control answers in a closed triple store are limited to yes and no.
Policy management is not only access control but also information filtering based on quality and trust properties. This is necessary whilst operating in a network of distributed resources which are not trustworthy per default. The TriQL.P [13] browser uses queries for filtering information from different sources and qualities. This filter approach is also part of the framework described here.
Another possible approach is the usage of explicit rules (which our approach also makes use of). An example for such a system is [14]. Again, the scope of this system is not an RDF triple store but distributed resources on a network and the access to these resources.
Summarizing we can state that all these systems operate with a different communication model. However, an RDF triple store can be seen as an agent in these frameworks, while the access control layer for the RDF triple store itself operates on a more basic and lightweight model.
In order that we can develop an access control framework which solves the given requirements, we have to specify a clear communication model for the target environment. In this basic model for access on RDF triple stores, we define three atomic actions:
-Reading a set of triples from a stored model: The account queries the triple store with a formal query language (e.g. [15], [16] and [17]) or selects some triples with a more simple method (e.g. a triple pattern). The answer of the triple store is a set of triples which constitutes the intersection of the wanted and the allowed triple set. Most of todays query languages can query not only for submodels. A common result value is a set of variable bindings.
Nevertheless there was a requested set of triple which was necessary for the computation of the result set. -Adding a set of triples to a stored model: The account sends the dedicated triple set to the triple store. The store removes all the triples which are not allowed to be written and adds each of the remaining triples, if they are not already contained in the model. -Removing a set of triples from a stored model: The account sends the dedicated triple set to the triple store. The store removes all the triples which are not allowed to be deleted and deletes each of the remaining triples, if they exist in the stored model.
The approach presented in [18] adds more atomic actions here to the above listed ones. They distinguish between one-triple actions, triple-set actions and reasoned-set actions. In this basic model neither one-triple actions nor reasonedset actions need to be considered because:
-A one-triple action can be seen as a specialization of a triple-set action.
-We define a reasoner application as an agent which holds a specific account with certain rights to a triple store. Following this, reasoned-set actions are combinations of normal triple-set actions which are performed by the reasoner agent.
In the next section, we describe an access control framework which is based on this communication model.
As denoted in section 2, we use explicit rules and query filters as the primarily parts of our framework. The whole framework consists of four parts:
-A query engine which can apply subset selection query filters to a given model. In this paper we assume that this is a query engine for the SPARQL query language [15] but generally the approach is not limited to a specific query language. -A rule processor which decides whether a query filter is fired for a given action or not. We assume that the used decision rules are described by using the Semantic Web Rule Language (SWRL, [19]) but also, this part can be replaced by an equivalent one.
-A minimalistic RDF schema called Lightweight Access Control Schema (LACS, [20]), which describes a basic vocabulary to store rules and query filters. -The access control processor, which starts the query engine and rule processor as needed and maintains some session data.
A fundamental concept of the framework is the presentation of a virtual model to the account instead of the real one. This virtual model is created from the real model and modified through the query filters selected by the rule processor. Thereby, the decision rules can reference to and use resources from the following three different models:
-Session Model: This model holds information about the active session (which account is doing what). The triple of this model are dynamically created for every new action on the triple store. -User model: This is the data which the account wants to get access to but it can used by the decision rules too. -Maintenance Model: This model consists of decision rules and filters as well as all other maintenance data like group or account information. The vocabulary for the filter and rule description comes from the lightweight access control schema and from the SWRL specification. The maintenance data which is used by the rules to decide the application of a query filter is not fixed, so rules can be created for every available environment, e.g. a FOAF database or an LDAP backend.
The following example maintenance model consists of two filters and rules. They are created for the following two reading conditions:
-All admins can read every triple.
-All accounts which are from type foaf:Person2 may read only triples where the subject is of type foaf:Person.
The rules to effect this behavior are:
rdf:type(lacs:CurrentAction, lacs:Read) ∧ rdf:sameAs(lacs:CurrentAccount, ?a) ∧ foaf:member(:Admins, ?a) → lacs:addAndStop(:currentAction, :AllFilter) rdf:type(lacs:CurrentAction, lacs:Read) ∧ rdf:sameAs(lacs:CurrentAccount, ?a) ∧ rdf:type(foaf:Person, ?a) → lacs:add(:currentAction, :FoafOnlyFilter) They reference triples in the maintenance model, which describe a group and a member of this groups with the commonly used FOAF vocabulary:
: Admins a foaf : Group ; foaf : member : UserSD .
: UserSD a foaf : Person ; foaf : name " Sebastian Dietzold ".
These rules reference two query filters. These query filters are given in a specific query syntax and are represented in the RDF with the LACS vocabulary: To give explicit instructions for the access control processor, the rules are represented in RDF and enriched with metadata. The first one is annotated by using the SWRL vocabulary referenced by the namespace ruleml, the latter by using the LACS vocabulary.
The next part defines two lacs:rule entities which references to SWRL implication rules (not displayed here). Important for the access control processor is the priority of the rules, since the rule selection (see figure 1) is ordered by this property. Based on this example maintenance model, a sample reading action is processed according figure 1.
First of all, the Session Model is modified by the access control processor to represent the current session. Again, the LACS vocabulary is used: lacs : currentUser = : User2 . lacs : currentAction a lacs : Read . After that, the first rule is selected and evaluated by the rule engine. In the example maintenance model, this is the "Admins can read everything" rule. Due to this rule, no filter is fired because the user is not member of the admin group. The next rule will be selected and due to this rule, the filter "read only FOAF address book" is fired. So the query process creates the virtual model as it applies filters to the user model. Because there is no other rule, the processor leaves this cycle and presents the virtual model to the user.
This was an example for a reading action. For this type of action, the user query is processed against the virtual model. For writing actions, the filters are not processed against the user model but rather against the model which is supplied by the user (i.e. the triples, he wants to add or delete). After modifying this model according the rules, the add or delete action is processed.
We have presented a lightweight access control framework for RDF triple stores based on requirements derived from usage scenarios within a Semantic Wiki application. The basic idea of this framework is the presentation of a virtual model instead of the real one. This model is generated by filtering the original model. Filter are selected by rules. In the examples, we use SPARQL for filtering and SWRL as rule language.
The presented framework strongly depends on the lightweight communication model given in section 3. So it is not intended to be a general access control framework for the Semantic Web. Instead it is designed to be a fast, reliable and easy to implement as part of an RDF triple store. In order to achieve this, we focused on a clear execution algorithm with explicit rules, but do not use any reasoning capabilities.
One important advantage when compared to other approaches is the possibility to create both simple and complex access control environments as necessary. Also, the minimal requirements to the underlying maintenance model are small, so that administrators can maximally reuse existing models within their rules.