Access Control Policies for Semantic Networks

2009 IEEE IEEE International International Symposium Symposium on Policies on Policy forfor Distributed Distributed Systems Systems and and Networks Networks

Access Control Policies for Semantic Networks Tatyana Ryutov Tatiana Kichkaylo Robert Neches University of Southern California Information Sciences Institute {tryutov, tatiana, rneches}@isi.edu

Abstract—As web-based technologies mature, dynamic graphs of interlinked resources are replacing hierarchical catalogs as means for storing and organizing information. Such graphs, or semantic networks, often span multiple static and dynamic resources from a variety of sources. It is often highly desirable to give users access only to parts of the semantic network without breaking its logical continuity or consistency. Traditional access control models, such as mandatory, discretionary and role-based access controls, are ill-suited for these new resource structures. New models that allow users to specify access rights in terms of semantic relationships between various objects within semantic networks are needed. In this paper we discuss requirements for an access control model for semantic networks and present our approach and an initial implementation. We also describe end user tools for policy specification and assessment.

I. M OTIVATION The World Wide Web has evolved into a powerful and pervasive storehouse of information and services. The next generation of this technology, the Semantic Web, allows users to publish not only simple content (e.g., web pages, articles, etc.) but also more complex, semantically rich objects such as models, as well as opening the Web to automated algorithms [4]. The Semantic Web views the World Wide Web as a distributed, dynamic, standardized semantic network (a directed graph) and a set of tools to operate on this graph. Semantics-based organization of information makes it easier to find relevant data; however, it also complicates access control issues. Semantic networks may span multiple static and dynamic resources from a variety of sources. It is often desirable to give users access only to parts of the semantic network without breaking its logical continuity or consistency. The Resource Description Framework (RDF) [1], a standardized data model for representing semantic networks, provides a foundation for most Semantic Web applications and higherlevel models, such as ontology languages. It is an important target for access control technology. Traditionally, access control approaches (such as mandatory, discretionary, and role-based access control) have dealt only with authorization decisions on a subject’s access rights to target resources, with both subjects and objects are specified statically and explicitly. These approaches do not consider rich semantics of the underlying data. Making decisions based on isolated entities while ignoring the semantic interrelationships among them may result in unintended data access, incomplete granting of access rights, and inconsistent state of the underlying semantic model. Furthermore, approaches utilizing only isolated explicit entities are often overly conservative for dynamic semantic networks, where new data is constantly added by various authorities. 978-0-7695-3742-9/09 $25.00 © 2009 IEEE DOI 10.1109/POLICY.2009.11

One of the main advantages of using a semantic network data organization is the ability to represent relationships between concepts. The meaning of a concept is determined by its relationship to other concepts; and the information is stored by interconnecting nodes with labeled arcs. While providing a number of advantages, such a data organization poses unique access control challenges: Granularity Access control rules must govern both nodes of the graph (entities) and edges connecting them (semantic relationships among the entities). For example, consider the submittedT o −→ Class. All following statement Assignment three entities: the Assignment, the Class it is submitted to, and the link submittedTo (the fact of the submission) can be subjects to access control. For instance: (1) only a teacher can modify Class, (2) students can modify assignments before submission, and (3) no modifications should be allowed once an assignment is submitted. Rules which only governed the entities/classes (e.g., Assignment and Class), could not enforce rule 3 of the policy outlined above, since the fact of submission (existence of a link submittedTo connecting Assignment and Class) can not be protected. Semantics awareness Access control rules need to manage semantic relationships between entities and access permissions. In the example above, if a user has read permission to Class, should he be able to find out what assignments have been submitted to it? That is: should the user have read permission to all objects connected to Class using a submittedTo link? Can he get access to the submittedTo link without being able to access the text of the assignment? Furthermore, creation of new links in some cases must entail changes in the access rights to the objects being linked. For example, suppose a user has modify permission to Assignment he is working on, so that he can revise the Assignment. The user submits the assignment by adding a submittedTo link which connects the Assignment and Class entities. Addition of this link should effectively withdraw the modify permission (i.e. the user can no longer make changes). Traditional access control mechanisms, such as Access Control Lists, define user rights to objects and thus cannot fully capture the interplay between permissions and semantics of the protected objects. Consistency Insertion/deletion of an entity must not compromise logical consistency of the underlying semantic network. Failure to create relevant links, as well as uncontrolled deletion of existing links between nodes can lead to a less complete, less accurate, and consequently less useful network. In particular, no operation should destroy consistency of data visible to any user by producing links with source or destination nodes that nobody can see. Additionally, it is just as

150

important to avoid creating orphan resources. An example of such a resource is an object with no attached links originating from or pointing to it. Safety Supporting safe automated propagation of access control rules over semantic links, as well as automatic assignment of policies for newly created resources, is essential for a system to be practical. Automation reduces the number of explicit access control specifications and helps to derive consistent authorizations. It also helps address complexities that proliferate in a semantic network because policies propagate along the links connecting resources as well as subjects. For example, allowing all students of a class to view a class assignment, might grant read access to a node Assignment to a group studentsOfClass and propagate this policy along links of type memberOf. The challenge of unintended permission leaks then arises For example, if another rule granted read access to studentsOfClass, it could interact with the first rule to potentially allow students access to other students’ work once submitted to Class. Such undesirable interactions are essential to avoid. Access control must prevent (or at least alert about) granting potentially undesirable or unintended access. In particular, no operation by a user (e.g., deleting or adding links) must give anyone (including the user) more rights than the user executing the operation already has. It is also important to avoid creating resources that nobody can access. In many cases, automatic permission propagation solves this problem by propagating positive access rights. Understandability Understanding the interplay between policies is crucial for users to trust that policies meet their intent. The complexity and the dynamic nature of the semantic environment in which policies are evaluated demands automated reasoning techniques for explaining and debugging the policies. Judgments about trustworthiness of access control greatly depend on the ability to test the end effect of specified policies. For example, if a user permits access to his personal data to a social network of people who are his friends and allows policy to propagate along the links of type friendOfMine, he may end up granting access to a foe who is a friend of his friend. Efficiency Last, but not least, a practical implementation of an access control model for semantic networks should be efficient. Addressing the above five concerns typically requires computationally expensive models. The efficiency requirement means that in practice additional restrictions need to be placed on the models to keep reasoning tractable. To overcome these challenges, there is a need for semantic relationship-aware access control systems. Recent work in this area largely concentrates on two directions: 1) Restricting access to RDF triple stores [3], [7], [17]. The access is defined on the granularity of triples. 2) A concept-level access control considers semantic relationships supported by ontology and is enforced at the level of concepts defined in ontologies [11], [15], [16]. In contrast, our approach controls access to objects in semantic networks at the granularity of individual nodes and links, taking into account the semantic relationships between the nodes, links, and permissions. We describe our access control

model using our iLands framework [18] as an illustrative example. The remainder of this paper is structured as follows. Section II describes RDF and iLands. Section III shows that the formal definition of our access control model can be expressed in simple and relatively elegant terms. Section IV describes and evaluates an implementation. Section V presents the related work on this topic. Finally, Section VI underlines some conclusions and future research directions.

151

II. S EMANTIC N ETWORKS AND A PPLICATIONS A. Resource Description Framework The Resource Description Framework (RDF) [1] is the de facto standard language for representing semantic information about resources on the web. RDF describes semantic relationships between external entities using statements of the form subject predicate object, where both subject and predicate are URIs and the object is either a URI or a literal. A set of RDF statements describes a semantic network and can be drawn as a graph. For example, the statements “Professor Smith teaches course CS101; MrJones is a student with student id 12345 taking CS101; and MrJonesAssignment is an assignment submitted by MrJones to CS101” can be represented in RDF as shown in Figure 1. We omit namespace definitions for brevity. An RDF statement can be reified, i.e. assigned an identifier, so that it can be referred to by other statements. ProfSmith teaches CS101

MrJones takes

studentid “12345"

submittedTo MrJonesAssignment

Fig. 1.

Example of an RDF network as a graph

Several languages have been proposed to query RDF graphs. For example, SPARQL [2] allows one to find sub-graphs of a given structure in an RDF graph and to construct new RDF graphs. B. iLands iLands is a set of Java libraries and a methodology for constructing distributed semantic network based applications in which users may restrict visibility of resources they control. RAW (Risk Analysis Workbench) is an example iLands application [18]. RAW provides access to semantic objects, files, and remotely executable applications. RAW users include researchers at various research labs and universities, students, and analysts and decision makers from the Department of Homeland Security. Relationships between various resources in RAW are semantic and thus form not a fixed file system-like hierarchy but a dynamic network. This network has no single root and no single super user. Therefore, access control policies are specified in terms of semantic relationships between resources. As those relationships change, so do effective permissions.

iLands provides a data model and a set of services for construction of distributed secure collaboration applications. Its data model is based on RDF [1] with a few restrictions necessary for managing resources residing inside the system, because RDF is designed to describe external resources. The differences are minor, and our access control model can be easily adapted to other RDF-based systems. iLands supports queries using a filter mechanism. The standard set includes filters for various components of the semantic graph – links, properties, types, etc. These filters can be combined into complex queries similar to those of SPARQL. In addition, application-specific filters can be created to explore deep structure of entities. iLands supports grouping related resources into bundles for access control purposes. Users can bundle information with identical access requirements (e.g., documents related to a particular project) and to issue only a single access control policy for the entire bundle. A bundle is an iLands entity composed of other entities (bundles and resources) connected by links of special type partof. Similarly, iLands supports grouping of users into groups. A group is an iLands entity composed of other entities (groups and users) connected by links of special type memberof. Groups and bundles can be organized into a Directed Acyclic Graph (DAG). Figure 2 shows an example of a bundle DAG. The purpose of the group/bundle hierarchy is to enable propagation of access permissions. The permissions are propagated from the top-level group/bundle to the low level groups/bundles and individual users/resources.

Fig. 2.

Example of a bundle DAG

III. M ODEL This section formally defines iLands access control model and compares it to the requirements laid out in Section I. A. iLands Access Control Policies iLands uses a “closed world” policy model: by default any resource created by a user is not accessible to others. To make the resource available, a user must specify an access control policy. The system maintains information about the authority who created the policy. In our model, an access control policy is a logical function. For a given semantic network and an access control request, which consists of a subject, object, and permission type, the function returns an answer in the set {allow, deny, not-applicable}. Not-applicable decision is returned when the policy does not cover the access request. iLand’s policy retrieval and evaluation algorithm tries to find a policy which explicitly grants or denies the access. In some

cases no such policy exists. For example, assume a policy governing a document D states that the members of group G can view the document. For any user, who is not a member of G no explicit allow or deny of view permission can be obtained (the policy returns not-applicable). Similarly, for any user requesting write access, no explicit allow or deny can be determined. In such cases, the system resorts to the default “closed world” behavior and denies the access. When multiple policies return conflicting results, a composition function (see Section III-C) produces the final answer. In addition to a set of logical formulas over the semantic network, a policy can specify conditions which regulate the applicability of a policy. The conditions may refer to the state of the external environment (e.g., time of the day) or userrelated attributes (e.g., user’s age or security clearance). iLands policy retrieval, evaluation, and enforcement is based on semantic queries using a filter mechanism. For example, if a user has view access to bundle Task1 Confidential, but the user cannot view resource R1 (Figure 2), the system will evaluate the policy and will hide (filter out) R1 from the bundle Task1 Confidential keeping only bundle Reports and the included resources R2, R3, and R4 visible. Allowing users to create access control policies for resources puts a lot of power in their hands. This creates a possibility of introducing errors and inconsistencies. Therefore, a model must be able to address the six challenges outlined in the Section I. Granularity iLands supports fine-grained access control. Policies can govern any entity addressable by the framework: user, group, bundle, resource or link. This allows for very flexible policies, as discussed in Section I. Semantics awareness In addition to fine-grained policies governing individual entities, policies can be applied to certain sub-graphs of a semantic network. Policy propagation is used to govern semantically connected nodes of the sub-graphs. Additionally, policies can be defined at a high level. For example, a policy may specify that any subject who teaches a class has view permission to any object which is an assignment submitted to this class. By construction, such policies are aware of the semantic relationships between nodes and edges of the semantic network (see Section III-D1 for examples). Consistency and Safety To enable enforcement of the consistency and safety requirements, we use policies of the same form, but applicable at different stages of the process. Safety policies are evaluated when a new policy is created to check whether the new policy satisfies a set of safety conditions. The conditions specify relationships between entities and access permissions which must always hold (e.g., a user can have view access to an entity only if the user has view access to the type of the entity). Consistency policies are applied after an operation is performed on the semantic network. If the operation violates the policies, it is rolled back. See Section III-F for details. Understandability In Semantic Web applications, it is important to be able to explain to the end user the reasons for decisions made by the system. Section IV-B describes our implementation of the user interfaces for policy specification and assessment.

152

Efficiency It is hard to design an efficient general algorithm for enforcing access control policies that satisfy the criteria outlined above. Section III-B discusses simple assumptions about the semantic network structure which enable an efficient implementation with little loss of generality. B. Assumptions about the Structure of Semantic Networks In the overall semantic network, we distinguish two directed acyclic sub graphs (DAGs): one formed by entities representing groups and users connected by links of special type memberof, and the other has internal nodes of type bundle, and links of type partof (leaf nodes can be of any type). Each policy is attached by a link of type attached to one or more entities in the overall semantic network. To discover and compose policies applicable to a particular access request, our algorithm considers two types of policies: • Policies directly attached to the entities in question • Policies propagated along the two DAGs Policy attachment and propagation along the partof and memberof links defines the access rule hierarchy, and serves to filter access control policies for applicability and precedence. This avoids having to search and evaluate all existing policies. C. Policy Propagation and Composition Policies attached to any node in the network propagate along the memberof and partof DAGs greatly simplifying access control management, since far fewer explicit authorizations are needed. Support for positive and negative authorizations, combined with a path-based composition algorithm, provides a convenient way to handle exceptions. Although this can create problems of conflicting authorizations, it has been shown that this can be handled by defining contexts in which different decision criteria can be applied [14]. A path-based approach to policy composition (most specific policy along a path takes precedence) is intuitive and natural for hierarchical environments because it is clear what policy is more specific. However, when taking the leap to DAGs, resolution based on the “most specific” concept alone is not sufficient, since there maybe several applicable (and possibly equally “specific”) policies due to policy propagation along different paths. Our approach takes into account the fact that, even in the presence of a more specific authorization, the more general authorization might still be applicable and preferable because of other paths in the DAG. This is described in Section III-E.

Fig. 3. Example of a partof DAG (bundle hierarchy) with attached policies

For instance, consider the bundle hierarchy in Figure 3. Suppose we want to determine access to object x. There are seven policies attached to different nodes of the DAG. Assuming policy propagation along the DAG partof links, all seven policies apply. Policies p1 and p2 are directly attached to x. Intuitively, these are the most specific policies which must override all other policies. However, as discussed in Section III-A, policies p1 and p2 may not give us a definite permit/deny answer for a particular user or requested permission type. In this case, we have to consider the remaining policies. To decide which of the applicable policies is more specific with respect to node x, we introduce a notion of policy distance. Policy distance of policy p attached to node y with respect to node x (target of access control) is the number of nodes with attached policies found on the shortest path from x to y. In our example, the policy distance of p1 and p2 from x is 0, since the policies are directly attached to x. The policy distance of policies p3 , p6 , p4 and p5 from x is 1, since there is one node (x) with attached policies on the direct path along links of type memberof from x to y, from x to v and from x to w. Similarly, the policy distance of p7 is 2. Thus, to determine which policy is more specific, we calculate policy distances for each policy. The policy with the smallest policy distance from x is the most specific to x If the policy distances are equal, the policies are considered to have equal priority. In our current implementation, we take a logical disjunction of such policies at policy distance of 1 or more. However, we take a logical conjunction of policies at policy distance 0 to support conservative policies when needed. D. Policy Language: Formal Representation We use many-sorted first order logic to formally represent our policy language [9]. We assume that the vocabulary Φincludes the following sorts: S for subjects, U for users, G for groups of users: S = U ∪ G; P for permissions (e.g., view, modify, add, etc); O for objects, B for bundles, R for resources, L for links, Σ for literal properties, T for types: O = B ∪ R ∪ L ∪ Σ ∪ T ; E for entities, E = S ∪ O; Π for predicates, ΠS for standard predicates, ΠC for custom predicates that support applicationspecific conditions: Π = ΠS ∪ ΠC ; Γ for policies. We will use the following predicates to describe the structure of the semantic network: link(l, t, ef rom, eto ), where l ∈ L, t ∈ T , ef rom ∈ E and eto ∈ E, denotes a link l of type t from entity ef rom to entity eto . property(x, t, ef rom ), where x ∈ Σ, t ∈ T and ef rom ∈ E, denotes an entity x which is a literal property of type t attached to an entity ef rom . type(e, t), where e ∈ E − (L ∪ Σ) and t ∈ T , denotes an entity e of type t. For instance, the semantic network given in Section II can be formally represented as follows: U = {P rof Smith, M rJones} R = {CS101, M rJonesAssignment} Σ = {“12345}

153

T = {studentid, teaches, submittedT o, takes} L = {l1 , l2 , l3 } link(l1 , teaches, P rof Smith, CS101) link(l2 , submittedT o, M rJonesAssignment, CS101) link(l3 , takes, M rJones, CS101) property(“12345, studentid, M rJones) We will use predicate permitA to represent definitive result of a policy created by an authority A: {allow, deny}. The authority who created a policy can be a user or system (default policies). We will omit the indication of an authority for clarity and will use it only when it is needed to express the policy rules. The notation permit(s, p, o), where s, p, and o are terms of sorts S, P and O respectively, means that subject s is allowed to perform action of type p on object o. The notation ¬permit(s, p, o) means that the action is denied. 1) Policies: A policy statement under Φ is a formula of the form: ∀Q1 x1 , ..., ∀Qn xn (π1 ∧ ... ∧ πm → [¬]permit(s, p, o)) (1) where each xi represents a variable of the sort Qi , s is a term of the sort S, p is a term of the set P, o is a term of the sort O; each of πj is a term of the sort Π that may include the variables x1 , ..., xn . Example 1: Policy: A user (subject) can view (has a permission of type view) any document (object) submitted to the class (object) taught by the user. The fact that a document is submitted to the class is represented by a link of type submittedTo, which connects the document and the class. Similarly, the fact that a user teaches a class is represented by a link of type teaches connecting the user and the class. Note that existential quantification can be converted to equivalent universal formulas as described in [9]. ∀S x ∀O y ∀O z (∃L l1 link(l1 , teaches, x, y) ∧ ∃L l2 link(l2 , submittedT o, z, y) → permit(x, view, z)) Example 2: Policy: Nobody except the owner (subject) can view (has permission of type view) private information (object has property private). ∀S x ∀O y (∃Σ p property(p, private, y) ∧ ¬∃L l link(l, ownerof, x, y) → ¬permit(x, view, y)) Example 3: Policy: Submitted assignments cannot be modified by anybody. ∀S x ∀O y ∀O z (∃L l link(l, submittedT o, y, z) → ¬permit(x, modif y, y)) 2) Permission Propagation Policies: If the left part of a policy statement contains one or more permit predicates, the policy specifies policy propagation rules. Permission transfer along group and bundle DAGs allows for compact policy specification. Note that to enable policy propagation along the DAGs, the policies described below must be explicitly defined. The following policy describes permission transfer from a group to its members. Namely, a subject inherits all privileges (positive and negative) from a group the subject is a member

of. This means that if group g has permission p to object y, then any member x of g also has permission p to y. ∀G g ∀S x ∀P p ∀O y (memberof (x, g) ∧ permit(g, p, y) → permit(x, p, y)) ∀G g ∀S x ∀P p ∀O y (memberof (x, g) ∧ ¬permit(g, p, y) → ¬permit(x, p, y)), where memberof(s, g) ⇔ ∃L l link(l, memberof, s, g), s ∈ S and g ∈ G. Similarly, the following policy denotes permission transfer from bundle y to all its constituents. This means that any user/group z that has (or is denied) permission p to bundle y also has (or is denied) permission p to any object included in the bundle. ∀S z ∀P p ∀O x ∀B y (partof (x, y) ∧ permit(z, p, y) → permit(z, p, x)) ∀S z ∀P p ∀O x ∀B y (partof (x, y) ∧ ¬permit(z, p, y) → ¬permit(z, p, x)), where partof(x, y) ⇔ ∃L l link(l, partof, x, y), x ∈ O and y ∈ B. When a policy attached to an object does not explicitly deny (or allow) access for a particular user, the access can be allowed (denied) by other policies due to the policy propagation along the partof links in a DAG. To avoid unintended access to sensitive objects, conservative policies can be defined. For example, concider the following policy: Nobody except the members of a group g can view object o. ∀S x (¬memberof (x, g) → ¬permit(x, view, o)) Since policies attached to an object overide all propagated policies, no additional access can be allowed, the access can only be further denied. Similarly, to avoid denial of access by propagated policies, explicit authorizations can be defined and attached to the object. E. Policy Composition Algorithm An iLands policy consists of several policy statements expressed by the formula (1) introduced in Section III-D. As described in Section III-C, to decide whether or not to allow a given subject access of a certain type to a given object, our algorithm collects and combines applicable policies along memberof and partof DAGs. To decide which policy has precedence, the algorithm considers where the policy is attached and the distance of the attachment point from the target entities. In particular, policies closer to the node which is the target of access control take precedence over the policies located further from the node. We take logical disjunction of policies at the same distance and logical conjunction of directly attached policies. A policy is directly attached to a node if there is a link connecting the policy to the node:

154

∀Γ p ∀B∪S x attached(p, x) ⇔ ∃L y link(y, attached, p, x) (2)

To obtain the final answer for subject s, object o, and permission p, the access control module calls the algorithm shown below providing 0 as the initial distance value. nodeFlags contains the results of evaluation (allow/deny) of all policies directly attached to a node. allFlags contains the results of policies at the same distance. EvaluatePolicies (s, o, p, distance): // collect nodes with attached policies at a given distance nodes = GetNodesOfPolicyDistance(o, distance) if nodes is empty return deny; // default behavior allFlags = [ ] for every node in nodes // get policies directly attached to the node policies = GetAttachedPolicies(node) nodeFlags = [ ] for every policy p in policies nodeFlags.append(p.evalute(s, o, p)) allFlags.append(doAnd(nodeFlags)) res = doOr(allFlags) if res == noanswer // neither explicit allow nor deny return EvaluatePolicies(s, o, p, distance+1) return res As shown, when no applicable policy returns a definite answer, the default behavior of this algorithm is to deny access. An alternative is to define a default policy (or a set of policies). F. Ensuring Safety and Consistency

∀S A∀S x∀P y∀O z(¬permit(A, y, z) ∧ permitA (x, y, z) → f ail) Consistency policies can be attached to any nodes of the network, or used as default policies that apply to the whole semantic network. Whereas safety policies are checked when a new policy is added and access control policies are evaluated before the action is carried out, consistency policies are checked after the action is performed. Note that it is necessary to evaluate consistency policies only for operations that change the structure of the network, and not for more frequent read only access. If a consistency policy evaluates to fail, the action that caused the corresponding change is rolled back. The set of consistency policies is usually applicationdependent. Some default consistency policies include: • Nobody can delete an object if there is at least one link pointing to the object: ∀L l∃O y∃T t (link(l, t, x, y) ∧ ¬∃O x → f ail) • Nobody can create an object not connected to the semantic network with at least one link pointing to the object: ∀L l ∃O y∃T t(∃O x ∧ ¬link(l, t, x, y) → f ail) This rule protects against creating resources nobody can find. In iLands implementation this rule is enforced automatically by linking any entity created by a user to the user’s default bundle. Similar to safety and consistency policies, one can define verification policies, whose right hand side contains a function to raise a warning. Verification policies do not roll back actions immediately and can contain more expressive queries to be evaluated later (e.g., during periods of lower activity).

In our framework, consistency and safety conditions are represented as policies with statements of the form (3). ∀Q1 x1 , ..., ∀Qn xn (π1 ∧ ... ∧ πm → f ail)

(3)

Safety policies are applied once a new policy is added to the system. If a safety policy evaluates to fail, the new policy that caused the corresponding change is disabled and its author is notified. Sample built-in policies include: 1) View permission on entity requires view on its type. ∀S x∀O y∀T t (permit(x, view, y) ∧ type(t, y) ∧ ¬permit(x, view, t) → f ail) 2) Permission to create a link to an object requires view permission to the object. ∀S x∀L l (permit(x, add, l) ∧ ¬permit(x, view, y) → f ail) 3) Any permission on a property requires the same permission on entities that have the property: ∀S x∀O ef rom ∀O y∀P z∀T t(¬permit(x, z, ef rom ) ∧ permit(x, z, y) ∧ property(y, t, ef rom ) → f ail) 4) Any permission on a link requires the same permission on its value. ∧ ∀S x∀L y∀P z∀T t∀E eto (¬permit(x, z, eto ) permit(x, z, y) ∧ link(y, t, ef rom, eto ) → f ail) 5) User may not grant anybody more permissions than the granting user has. Note that we use notation permitA (x, y, z) to denote that user A granted permission y to access object z to user x.

IV. I MPLEMENTATION Our implementation is based on the client-server architecture of the RAW application implemented in Java on top of the iLands framework (Figure 4). Before reaching the semantic network storage and application-dependent services, all user access requests are fowarded to the Access Control Module to determine what part of the semantic network is visible to the user.

Fig. 4.

Architecture of a RAW application

A. Access Control Framework

155

The main components of the framework include: Policies The system supports two types of policies: 1) Subject-level policies are associated with users or groups. These policies are useful to specify user-related constraints: e.g., read only user, resource consumption limits, delegation constraints, etc.

2) Object-level policies are policies associated with resources/bundles. Explicit policies are created using a graphical user interface (described below), and are directly attached to an entity (resource/bundle or user/group). Users can make policies propagate along the memberof and partof links in a DAG (as just described in Section III-D) by selecting a checkbox during policy creation. Otherwise, the policy will apply only to the node to which the policy is attached (no propagation). In the current implementation, this decision is made per policy. Policy Retrieval Engine collects relevant explicit and propagated subject- and object-level policies. Policy Evaluation Engine evaluates each policy. Access Control Module starts the policy retrieval and policy evaluation engines as needed and maintains some session data. The module provides a checkAuthorization() method, which takes id (URI) of a user/group who attempts to access an object, id of the object which is the target of request, and id of requested operation as input and returns tentatively authorized or not authorized decision. The module first collects and evaluates all subject-level policies associated with the user according to the algorithm described in Section III-E. Subjectlevel policies have the highest priority and are evaluated first. If the system does not reach a definite allow/deny decision using subject-level policies, it retrieves and evaluates relevant object-level policies. During the policy evaluation process, the system retrieves and applies user/group memberships. If no explicit authorization is granted by the policies, the access is denied. If the access is granted by object- or subject-level policies, the next step is to evaluate consistency. The system enforces consistency policies, as described in Section III-F, for actions that result in modifications to the underlying semantic network (e.g., delete, modify). If the consistency checks succeed, the requested action is allowed, otherwise it is denied. The final step is the verification check – a background process which assesses store state according to a set of rules (see Section III-F), and generates reports flagging violations and warnings triggered by the rules. B. User Interfaces The “RAW Permissions Check” user interface (Figure 5(a)) answers the questions: “What are my (or someone else’s) permissions? What are the members of this group? To what groups does this user belong?” The interface presets tabs, each of which shows results of a semantic query applied to the data currently in the system. Results of each query are filtered based on the requester’s (a user who queries the interface) permissions. Thus objects/users/groups that the requester is not authorized to see do not show up and therefore are not displayed in the resource/group hierarchy. The interface of the administration tab allows a requester to determine which parts of the tabs visible to the requester will be accessible by user X, assuming the requester is allowed to know about existence of X. Color coding is used to indicate whether a user is allowed (green), denied (red), or granted partial (yellow) access to

(a) RAW Permissions Check Fig. 5.

(b) RAW Policy Editor

RAW User Interfaces

a certain resource. Additionally, users can view group and bundle memberships, as well as view the members of a particular group/bundle. The “RAW Policy Editor” user interface (Figure 5(b)) displays a selected bundle with indications of the nodes where explicit policies have been added. The user can click on the node and view/edit the explicit policy for the node. Once a new policy is specified, or existing policy is edited, the safety policies are applied. Note that, if a requester is not authorized to view particular objects, view policies for specific users or bundles or view group or bundle memberships, that requester will not be able to view or select the corresponding options. V. R ELATED W ORK A number of formal languages for access control policy representation have been proposed. [19] describes an authorization language based on default logic. [10] presents a formal language based on locally stratified logic. [9] describes a fragment of First Order Logic which is tractable and sufficiently expressive to capture policies for many applications. We adopt the latter model to reason about policies in RDF-based semantic networks, while introducing safety and consistency policies, and providing an initial implementation and user-level tools for managing the policies. The problem of restricting access to RDF data has been considered, and several approaches have been proposed. [17] presents a policy-based mechanism for controlling access to RDF stores. The policies support restrictions on inserting a set of triples into the store, deleting a triple, and querying whether or not a triple is in the store. [7] describes an access control model for RDF triple store for a semantic wiki application. [3] presents a policy-based query rewriting access control mechanism for RDF repositories. These systems define access control policies at the level of triples, not considering a higher level semantic relationships. Our system supports policies at the level of individual nodes and links, thus supporting fine-grained access control. Furthermore, our semantic-aware policies ensure consistency and safety of the RDF store. Like our system, [11], [15], [16] consider semantic relationships between entities. However, these systems enforce access control at the level of concepts defined in ontologies, thus leaving a gap between static concepts and dynamics

156

of the underlying semantic network. The process of associating a newly created resource with a particular concept is not clear and is vulnerable to authorization errors. Our system addresses this problem by enforcing policies defined in terms of relationships between nodes and edges of a semantic network. [16] introduces a concept-level semantic access control model supported by an ontology. The model facilitates granting of permissions based on propagation of semantic relationships among concepts. Thus, a subject is allowed to access instance data if he has permission for the corresponding concept. However, the authors do not define how the instances are associated with the ontological concepts and how to enforce access control requirements on these concepts. iLands implementation supports grouping resources into DAGs and allows attaching policies to the DAG nodes. [15] proposes a system to support secure data sharing and interoperation among heterogeneous databases. The system extends traditional RBAC by considering semantics of objects to be protected and associates permissions with concepts rather than the objects. [11] describes SBAC – an access control model for protecting Semantic Web resources. SBAC takes into account semantic interrelations among entities and considers propagation of policies based on the interrelations. The paper does not describe an implementation of the model, it only provides a sketch of an architecture for implementing the SBAC. Many policy languages (e.g., KAoS [12], Rei [13], PeerTrust [8], Protune [5] and Ponder [6]) enable policy-based access control on the Semantic Web. While these languages support flexible and expressive policies (and some of them apply semantic web technologies to policy representation and reasoning), none of them is well suited for controlling access in RDF-based semantic networks, since they do not fully support the requirements outlined in Section I. KAoS and Rei are two representative projects that make use of Semantic Web technology to specify security policies. KAoS uses ontology concepts to specify policies. While the KAoS policies support relationships among actors, operations and other policies, the policies do not consider semantic relationships between governed entities, whereas our system controls access to semantically organized resources. Like our system, Rei provides constructs for policy conflict resolution. However, a policy must be explicitly associated with an entity. No policy propagation is supported. Furthermore, Rei does not provide a means to query permissions, which is very important in dynamic environments. Our system mitigates these issues by supporting automated policy propagation and query interfaces to ensure policy correctness. VI. S UMMARY AND F UTURE W ORK The vision of Semantic Web promises more flexible and powerful ways to access data for humans and automated systems alike. However, it also poses new challenges for access control systems. In this paper we have identified several criteria an access control model for semantic networks should satisfy. They include fine granularity of access control decisions to enable creation of clear boundaries within continuous semantic network, awareness of the data semantics,

and the ability to enforce application-dependent consistency and safety rules. We also presented a model that satisfies these requirements and an implementation of this model for an RDFlike framework called iLands. Our model relies on a semantic query mechanism, suitable versions of which exist both for iLands and RDF, thus our algorithms can be easily applied to other frameworks. We described access control interfaces of the Risk Analyst Workbench application, which allow users to explore effects of policies. Our future plans include extending the implementation, supporting advanced user interfaces for specification and evaluation of policies, and improving performance of the algorithms. R EFERENCES [1] http://www.w3.org/RDF/. [2] http://www.w3.org/TR/rdf-sparql-query/. [3] F. Abel, J. L. De Coi, N. Henze, A. W. Koesling, D. Krause, and D. Olmedilla. Enabling advanced and context-dependent access control in RDF stores. Lecture Notes In Computer Science, 2007. [4] T. Berners-Lee, J. Hendler, and O. Lassila. The Semantic Web. Scientific American, May 2001. [5] P. Bonatti and D. Olmedilla. Driving and monitoring provisional trust negotiation with metapolicies. Proceedings of IEEE International Workshop on Policies for Distributed Systems and Networks, pages 14– 23, 2005. [6] N. Damianou, N. Dulay, E. C. Lupu, and M. S. Sloman. The Ponder policy specification language. Proceedings of IEEE International Workshop on Policies for Distributed Systems and Networks, 2001. [7] S. Dietzold and S. Auer. Access control on RDF triple stores from a Semantic Wiki perspective. Proceedings of Scripting for the Semantic Web Workshop at the ESWC, pages 1613–0073, 2006. [8] R. Gavriloaie, W. Nejdl, D. Olmedilla, K. Seamons, and M. Winslett. No registration needed: How to use declarative policies and negotiation to access sensitive resources on the semantic web. Lecture Notes in Computer Science, 3053:342–356, 2004. [9] J. Halpern and V. Weissman. Using first-order logic to reason about policies. In IEEE Computer Security Foundations Workshop, pages 187– 201, 2003. [10] S. Jajodia, P. Samarati, M. Sapino, and V. Subrahmanian. Flexible support for multiple access control policies. ACM Transactions on Database Systems, 25(2):214–260, 2001. [11] S. Javanmardi, A. Amini, and R. Jalili. An access control model for protecting semantic web resources. In Proceedings of Semantic Web Policy Workshop, 2006. [12] M. Johnson, P. Chang, R. Jeffers, J. M. Bradshaw, V. W. S. amd M. R. Breedy, L. Bunch, S. Kulkarni, J. Lott, N. Suri, and Uszok. KAoS semantic policy and domain services: An application of DAML to web services-based grid architectures. Proceedings of the workshop on Web Services and Agent-Based Engineering, 2003. [13] L. Kagal, M. Paolucci, N. Srinivasan, G. Denker, T. Finin, and K. Sycara. Authorization and privacy for semantic web services. IEEE Intelligent Systems, 19(4):50–56, 2004. [14] E. C. Lupu and M. Sloman. Conflicts in policy-based distributed systems management. IEEE Transactions on Software Engineering, 25(6):852– 869, 1999. [15] C. Pan, P. Mitra, and P. Liu. Semantic access control for information interoperation. Proceedings of ACM Symposium on Access control models and technologies, pages 237–246, 2006. [16] L. Qin and V. Atluri. Concept-level access control for the semantic web. Proceedings of the 2003 ACM workshop on XML security, pages 94–103, 2003. [17] P. Reddivari, T. Finin, and A. Joshi. Policy-based access control for an RDF store. Policy Management for the Web, pages 78–83, 2005. [18] T. Ryutov, T. Kichkaylo, R. Neches, and M. Orosz. SFINKS: Secure focused information, news, and knowledge sharing. IEEE International Conference on Technologies for Homeland Security, 2008. [19] T. Y. C. Woo and S. S. Lam. Authorizations in distributed systems: A new approach. Journal of Computer Security, 2:107–136, 1993.

157