XACML Policy Integration Algorithms - CiteSeerX

XACML Policy Integration Algorithms PIETRO MAZZOLENI CS Department, University of Milan BRUNO CRISPO Vrije Universiteit, Amsterdam and University of Trento SWAMINATHAN SIVASUBRAMANIAN Vrije Universiteit, Amsterdam ELISA BERTINO Cerias and CS Department, Purdue University XACML is the OASIS standard language specifically aimed at the specification of authorization policies. While XACML fits well security requirements of a single enterprise (even if large and composed by multiple departments), it does not address the requirements of virtual enterprises in which several autonomous subjects collaborate by sharing their resources to provide better services to customers. In this paper we highlight such limitation and we propose an XACML extension, the policy integration algorithms to address them. In the paper we also present the implementation of a system which makes use of the policy integration algorithms to securely replicate information in a P2P-like environment. In our solution, the data replication process considers the policies specified by both the owners of the data shared and the peers sharing data storage. Categories and Subject Descriptors: D.4.6 [Security and Protection]: Authorization Additional Key Words and Phrases: XACML, Security policies integration, Distributed Systems, Web Services,Content Distributed Networks, SOA

1. INTRODUCTION XACML (eXtensible Access Control Markup Language) [OASIS 2005] is the standard language developed by OASIS for expressing access control (AC) policies [OASIS 2005]. The language proposes an approach to manage AC constraints in large enterprise systems, that often have many policy elements and Points of Enforcement (PoE). The goal of XACML is to provide a common language through which an enterprise can manage all the elements of its security policies for all the components of its information systems. This is because there is an increasing pressure to demonstrate the adoption of “Best Practices” in the protection of the information [HIPAA 1996; EU 1995] but today it is virtually impossible to independently manage the configuration of each PoE and to have a complete view of the safeguards in effect throughout the enterprise [OASIS 2005; Anderson 2005a]. In this direction, XACML does not only provide a formalism to specify authorization policies, but it also comprises information useful to take authorization decisions as well as approaches to integrate constraints specified by multiple subjects. In this context, XACML defines some policy combination algorithms, through which a PoE can combine authorization decisions of policies specified by multiple administration entities. An example of policy combination algorithm is “Deny Override” according to which a set of policies deny a request if at least one of the composing policies denies it. ACM Journal Name, Vol. V, No. N, Month 20YY, Pages 1–0??.

2

·

P. Mazzoleni, B. Crispo, S. Sivasubramanian, E. Bertino

XACML is a very rich and flexible language; users and security administrators can directly represent, using XACML, a large variety of AC policies. However, XACML has not been built to manage security for systems in which enterprises are dynamically built with the collaboration of multiple independent subjects sharing their resources to provide better services to customers. With the growing popularity of the “service virtualization” business model [HP 2005; IBM 2004; Kusnetzky and Olofson 2004], computation and business processes are not longer constrained within a single administrative domain but distributed across service providers belonging to multiple enterprises. Furthermore, the owner of the data can be different from the parties providing the physical resources (e.g., memory, computing power, and network bandwidth) needed to run them. In such scenarios, it is reasonable for all entities to independently specify finegrained authorization constraints to protect their resources. Under these conditions, it is however unclear which entity should be entitled to choose the XACML policy combination algorithm to be used for integrating the policies specified by the various parties. In fact, XACML always assumes the existence of an “enterprise administrator” which can solve conflicts (of policies specified by different entities of the same company) by specifying the proper policy integration algorithm. To understand the motivation of our research, consider as example a collaborative Content Distribution Network (CDN) built using a P2P technology and in which subjects can replicate their data in storage made available by third party resource providers. Examples of real-world systems adopting this model are Lockss [Baker et al. 2005; Lockss ] and LionShare [Lionshare ; Morr 2004a]. In such systems, both the owner of the data and the owner of the storage can specify their AC policies in XACML. The former can place constraints on where its data can be placed and who can read it, while the latter can place constraints on who can upload and download information from the storage. In this scenario, to take the authorization decision upon a request for accessing some data, both the policy of the Data Owner (DO) and the policy of the Resource Owner (RO) hosting the data need to be combined. However, it is not clear how those XACML policies should be integrated and who, between DO and RO, is entitled to take such decision. In fact, if DO and RO are autonomous entities, RO might evaluate a request not considering the policies of the DO (with the risk of giving access to requests not authorized by the DO). On the other hand, DO needs to authorize access to its data independently from the RO hosting it. Despite some previous works that have applied XACML to distributed environments [Anderson 2004; Lorch et al. 2003; W3C 2003], in this paper we demonstrate XACML policy combination algorithms are not enough to integrate policies specified by autonomous parties. In addition, we relax the XACML assumption that that all PoEs of an organization are willing and available to enforce any policy (or combination of policies) set by a third party. Again, while such assumption is reasonable in case of a single company, this is not the case of scenarios in which PoEs are administered by autonomous parties. For instance, in the CDN scenario just introduced, a RO might not be willing to evaluate policies for each and every DO storing some data in its ACM Journal Name, Vol. V, No. N, Month 20YY.

XACML Policy Integration For Distributed Systems

·

3

resources. In this paper we propose an authorization method specifically built for distributed systems in which policies specified by autonomous parties need to be combined to authorized or deny the access to a request. We believe our solution applies to a large variety of domains, such as service oriented architectures, data sharing applications, CDNs, and Grid computing systems. Our proposed solution has two key components: a policy similarity process and a policy integration algorithm. The policy similarity process is a process through which policies are compared with respect to the sets of requests they authorize. Given two policies, the process determines which policy is the most restrictive. On the other hand, the policy integration preferences is an XACML extension through each entity can specify the approach to be follow in case its policies need to be integrated with the ones specified by others. With our solution, it is now possible to‘ implement systems in which the XACML policies of all parties are considered and flexibly integrated. Possible conflicts that may arise when integrating policies are solved (whenever possible) by means of a mutual agreement among the parties and not by an “authoritative” approach like the one XACML implies today. When mutual agreement cannot be reach, the situation is notified to the interested parties for further action. To demonstrate the applicability of our solution, we present a security aware data replication service we have implemented to securely distribute information across resources made available by autonomous subjects. The use of the service is demonstrated on a P2P network in which data owners are not only able to manage and share their data using their own resources, but also to replicate information at third party subjects while maintaining each other authorization requirements. The rest of the paper is organized as follows: Section 2 provides a brief overview of the main components of XACML. Section 3 presents motivating examples to demonstrate the limitations of XACML when applied to service-virtualization systems. Section 4 and Section Section 5 respectively describe policy similarity process and policy integration algorithms. Section 6 presents an algorithm for computing policy difference that together with the policy similarity is used to take an authorization decision. Section 7 presents the implementation of the data replication service and discusses its performance. Section 8 compares our solution with the state of the arts and Section 9 concludes the paper and outlines the future work. 2. XACML POLICY LANGUAGE The formalism adopted by XACML for specifying AC policies is based on four major components. Attributes and Functions. Attributes are characteristics of subjects, resources, actions, or environments that can be used to define a restriction. XACML does not pre-define a list of attributes; instead it specifies a list of (normative) datatypes and functions that subjects and/or communities can use to create the set of attributes which are valid for a system. String, Time, Boolean, Double, and AnyURI are some examples of valid data-types, whereas String-Equal, GreaterThen, Date-Equal, String-Is-In, and AnyURI-One-And-Only are examples of valid functions. ACM Journal Name, Vol. V, No. N, Month 20YY.

4

·


Fig. 1.

XACML rule and policy combination algorithms

Rule. A rule is the basic element of a policy. It identifies a complete and atomic authorization constraint which can exist in isolation with respect to the policy in which it has been created. A rule is composed by a Target, which identifies the set of requests to which the rule applies, an Effect, which is either “Permit”, to give access, or “Deny”, to prohibit access, and a set of Conditions which represent additional predicates specifying when the rule applies to a request. Policies. A policy is a combination of one or more rules. A policy contains a Target (specified using the same components as the rule Target), a set of rules, and a rule combination algorithm. The combination algorithm allow one to specify the approach to adopt in order to compute the decision result of a policy, when the policy contains rules with conflicting Effects. The rule combination algorithms specified as part of XACML are the ones reported in Figure 1. In the rest of the paper we will focus on “Deny Override” and “Permit Override” rule combination algorithms. Policy Set. Like multiple rules compose a policy, multiple policies compose a policy set which represents the conditions to apply in case the authorization decisions have to take into accounts requirements specified by multiple parties. A policy set is defined by a Target, a set of policies (or other policy sets), and a policy combination algorithm. The policy combination algorithms proposed in XACML are the same used for combining rules in a policy, that is, the ones in Figure 1. An XACML policy can also contain Obligations, which represent operations specified in a policy or policy set that should be performed by the PEP in conjunction with the enforcement of an authorization decision (e.g., data can be accessed from 5p.m. to 8a.m., provided the name of requester is sent by email to the data owner). However, obligations are outside the scope of this work and thus we do not consider them in the rest of the paper. XACML does not only provide a language for policy specification; it also provides a method for evaluating a policy based on the values of the policy attributes associated with a request. The process for evaluating and enforcing AC policies comprises three main elements: ACM Journal Name, Vol. V, No. N, Month 20YY.


·

5

—A Policy decision point (PDP) - This is the entity in charge of evaluating applicable policies and returning an authorization decision. —A Policy enforcement point (PEP) - This is the entity performing AC by enforcing the stated authorizations. —A Context handler - This is the entity in charge of converting decision requests from the native request format to the XACML canonical form and to convert the authorization results from XACML to the native format supported by a PEP. In a nutshell, the access requests are evaluated as follows: the requester sends a request to a PEP which in turn contacts the context handler in charge of converting the request from the PEP native format to the XACML request context. Such context is then sent to the PDP which evaluates the policy rules. We said that a rule applies to a request if the information of the context request satisfies both the rule target and rule condition predicates. If these predicates are not verified, the rule is “Not applicable” and its Effect ignored. In the same way, a policy is “Not applicable” if no rule applies to the request. The rule combination algorithm is used to resolve conflicts among applicable rules with different Effects. The result of the policy evaluation (“Permit”, “Deny”, or “Not applicable”) is returned back to the context handler which first converts it in the native format supported by the PEP and then forwards it to the PEP. The PEP evaluates the policy evaluation result and takes the final decision about the request. 3. MOTIVATING EXAMPLES: A TWO CASES FOR REQUIRING POLICY INTEGRATION The policy integration method process we propose in this paper can be applied to several applications ranging from Web Services, Grid systems to collaborative storage systems. In the following, we motivate our work using two real world scenarios: (i) Accommodating user-defined access control policies in a collaborative storage system (e.g., Lockss [Lockss ]), and (ii) an enterprise data processing firm. 3.1 Example 1: Collaborative Storage System Lockss (for “Lots of Copies Keep Stuff Safe”) is a P2P storage system that allows collaborating peers to form a storage network. It is used by the participating peers to safely preserve their content by replicating their data at other participating nodes. Such a replication not only improves availability by allowing content owners to survive temporary failures (e.g., network outages) but also permanent failures (e.g., irreparable disk failures). Lockss is now widely used by many public libraries in the United States to preserve their digital content safe [Lockss ]. The credentials of participating libraries are verified offline. Once a peer joins the system, the access control policy is globally defined by a central administrator. The system as of now does not support library-defined access control policy. Now let us explain how a collaborative system such as Lockss can support librarydefined access control policies. For example, let us consider that library A wants to preserve its contents by replicating it across multiple libraries. In this scenario, let us assume LibB and LibC to be two libraries willing to host replicas of peers participating in the storage system and the policies of these systems are: ACM Journal Name, Vol. V, No. N, Month 20YY.

6

·


Library B (LibB) policy: Users are not authorized to perform any retrieve/store action on any resource during its peak hours (10a.m. to 2p.m). However, users with an e-mail name in the “.gov” or in the “.edu” namespaces are always be authorized to access. Library C (LibC) policy: Any user with an e-mail name in the “.edu” namespace is allowed to perform any action on any resource. The same applies to users affiliated with Lockss. However, requests entered between 8a.m to 8p.m. should be denied the access. Let us assume Library A wishes to host its data into storage owned by B and C (ROs). Let us assume A’s AC policy to be: Library A (LibA) policy: Any user with an e-mail name in the “.edu” or in the “.gov” namespaces is authorized to read any information. However, no access should be allowed from 8a.m. to 12a.m. The specification of these AC policies according to XACML is reported in Appendix. Note that LibB and LibA adopt “Deny Override” as rule combination algorithm whereas LibC adopts “Permit Override” rule combination algorithm. In this scenario, LibA can either store its data in LibB or LibC’s storage. However, it is not clear which policy combination algorithm, among the ones defined by XACML, has to be used to combine the two policies and which party is entitled to decide it. “Permit Override” cannot be used because the Data Owner (LibA in the example) may grant access to requests which are not authorized by the Resource Owners (LibB and LibC int the example) hosting the information At the same time, “Permit Override” will create situations in which a request might be given access to the data bypassing Data owner policy only because the subject is authorized to access the resource hosting the information On the other hand, “Deny Override” cannot be used as the LibB (or LibC) might not be willing to assume the extra task of evaluating all the policies of the LibA (or any other data owner storing in its infrastructure). At the same time, LibA might not accept that some of its authorized users will be denied access to its data. Finally, using “Deny Override” to combine two policies might lead to a scenario in which no users will be authorized to access the requested resources. For instance, suppose that a Data Owner’s policy authorizes accesses only to users having email in the “.edu” namespace. Let also assume that the Resource Onwer hosting the data gives access to its resources only to subjects the email of which are in the “.com” namespace. In this example, the “Deny Override” combination algorithm results in denying access to all subjects wishing to access information by such a DO. 3.2 Example 2: Enterprise Data Processing Firm Let us consider an offshore accounting firm, say Company MPK , that provides accounting services to different companies (i.e., its clients) located worldwide. These companies obtain the data from its clients and return the processed information as result. These firms usually tend to store their information within an Internet Data Storage Provider. The reasons of such decision is because those Storage Providers guarantee highly available storage solutions and they are efficient in content distribution and provider faster download speeds. Examples of Internet storage providers ACM Journal Name, Vol. V, No. N, Month 20YY.


·

7

include Amazon S31 , and iDisk2 . Now, let us consider the scenario where Company MPK (DO) wants to use one or more storage providers (ROs) to store and distribute its data. Similar to the previous example Company MPK has to choose one or more storage providers such that its clients can obtain the data. However, contrary to the traditional client server model, each client of Company MPK needs to be authorized not only by the access control policy of the (chosen) ROs but also by the access control policy of Company MPK. Similar to the previous example, if XACML policy combination algorithms (e.g., “Deny Override” or “Permit Override”) are used to combine the policies of storage providers and the processing firm, the result could can be too restrictive or lead to unforeseen access control decisions. Thus, each client must be authorized by an “integrated” policy of considering both Company MPK and of the storage provider. 3.3 Discussion As illustrated in the above examples, when policies are specified by multiple autonomous parties (for simplicity our examples refer only to three parties but they can be easily generalized to any number of parties) to control their resources (either physical or logical), it is not clear which party is entitled to set the policy combination algorithm. XACML does not address such problem because it assumes that there always exists a sort of “enterprise administrator” who decides in advance on behalf of all the concerned parties. We believe this is a very restrictive assumption and does not scale well for large scale multi-party systems autonomous and independent parties. In this paper, we address such a problem by extending the XACML language with a set of policy integration algorithms. These algorithms can be specified by all involved parties as a part of their access control policy and dictates the integration approach that must be followed in case their policies have to be integrated with policies of other parties. The decision about policy integration is therefore computed dynamically by taking into account the requirements of all involved parties. 4. POLICY SIMILARITY PROCESS Before introducing the policy integration algorithms, we need to analyze the behavior of the policies to be integrated with respect to the requests they authorize. In other words, we need to identify whether there are requests authorized by a policy and denied by another. In this section, we describe the process for extracting such information which we refer to as Policy Similarity of two policies. For example, saying that the Policy Similarity between pi and pj policies is “Restrict” means that there are requests authorized by pj which are not authorized by pi , whereas the opposite is not true. The reason of introducing Similarity prior Policy integration algorithms is because to protect the policy integration requirements set by the various entities, we 1 http://www.amazon.com/s3/ 2 http://www.apple.com/dotmac/idisk.html

ACM Journal Name, Vol. V, No. N, Month 20YY.

8

·


first need a method to compare the behavior of the policies with respect of the requests they authorize. The process for computing policy similarity between XACML policies is not trivial. In particular, three elements need to be considered: the rule targets and conditions, representing the predicates to be evaluated; the rule effects, specifying the intended consequence (either “Permit” or “Deny”) of the rules; and the rule combination algorithms, specifying how to combine the effects of the rules in each policy. In such context, it is important to recall that “Not Applicable” rules (i.e., no rules in the condition of the target of which are verified by the context request) do not take part in the authorization decision. This means, for example, that a rule, denying access from 8a.m. to 8p.m., does not give any indication (in terms of authorization) for requests issued at night time. The same discussion applies to policies. A “Not Applicable” policy in neither Permit nor Deny. However, for a policy we can assume the least privilege principle applies, that is, a request is denied if the evaluation of the policy ( for a given the request) is either “Deny” or “Not Applicable”. In the rest of this section we describe the process we developed to compute the similarity between two XACML policies. The process is organized according to three steps: (1) the similarity is computed among single rules by considering their targets and conditions only; (2) rules similarity are grouped and simplified by considering their Effects; (3) the policy similarity is extracted by using the rule combination algorithms specified by the two policies. STEP1: Computing rules similarity Given two XACML policies, the first step is to compute the similarity between pairs of rules defined using the same policy attribute. The goal is to identify, for each attribute, which policy specifies the most restrictive condition. To obtain such information, our integration methodology analyzes the conditions of the two rules and based on data types and functions extracts and compares the sets of values for which the two expressions hold. As graphically illustrated in Figure 2, we distinguish five types of rules similarity: —Converge. Two rules “Converge” if the sets of values with respect to which their conditions hold are equal. —Diverge. Two rules “Diverge” if the sets of values with respect to which their conditions hold do not intersect. —Restrict and Extend. A rule “Restricts” (“Extends”) another rule if the sets of values with respect to which its condition holds contains (is contained in) the set of values computed for the other rule. —Shuffle. Two rules “Shuffle” if the sets of values for which their conditions hold intersect but no one is contained in the other. Example 1. In our running Lockss example, the rule similarity computed between LibA and LibC policies are the following: the LibA e-mail “Extends” LibC e-mail condition whereas LibA condition on Time “Restricts” time condition set by LibC. 4 ACM Journal Name, Vol. V, No. N, Month 20YY.


Fig. 2.

·

9

Policy Rule similarity type

A different approach is taken for rules the policy attribute of which is specified in one of the two policies only. In this case, the above strategy cannot be applied because there are no two conditions that can be compared. In such case, the rule similarity is computed considering which one of the two policies contains the rule. In this context, when computing the similarity between pi and pj policies, if pi has a rule the attribute of which is not in pj , the rule similarity is “Restrict”; on the other hand, if pj contains a rule the attribute of which is not in pi , the rule similarity is “Extend”. Rule Ef f In the rest of the paper we refer to the rule similarity using the notation P ol Attsim type where P ol Att is the attribute specified by the two rules, Rule Ef f their Effects 3 , and sim type the similarity value from the set {Converge, Diverge, Restrict, Extend, Shuffle}. Example 2. According to our formalism, the rules similarity computed for the policies of our motivating example are the following: P ermit —The rules similarity computed comparing LibA and LibB policies are E-mailConverge , Deny Current-T imeShuf f le P ermit , —The rules similarity computed comparing LibA and LibC policies are E-mailExtend Deny P ermit Current-T imeRestrict , and Af f iliationExtend 4

STEP2: Group rules similarity based on rule Effects and apply transformation functions 3 For

the sake of readability, at this time we restrict the problem by assuming the two policies do not contain rules defined with the same policy attribute but with conflicting Effects. ACM Journal Name, Vol. V, No. N, Month 20YY.

10

·


The next step in the process of computing the policy similarity is to group rules similarity based on their Effects and then to apply some transformation functions which apply some logic to reduce the number of rules similarity to be considered. The goal of this step is to obtain two similarity values only, one for the rules the Effect of which is “Deny” and one for the rules defined with “Permit” as Effect. In the last step, such information will finally be integrated based on the rules combination algorithms specified by the two policies. From this step on, the XACML rules are not used any longer; only the rules similarity are considered. In the following, we also replace the policy attributes defined in the rule similarity with a generic term R. A rule similarity is therefore denoted Rule Ef f by Rsim type . With such consideration, Rules similarity can now be organized in two groups: the rules similarities of the Permit Rules and the rule similarity of the Deny rules. For each group the following transformation functions are applied: Definition 1. Let i ∈{Converge, Diverge, Restrict, Extend, Shuffle} be a similarity value and m ∈ {P ermit, Deny} be rules Effect. The following rule similarity transformation functions apply: —{Rim , Rim } = Rim m m m —{RConverge , Ri(i6 ={Diverge}) } = Ri m m m —{RDiverge , Ri(i6 ={Diverge}) } = RShuf f le m m m —{RExtend , RRestrict ) = RShuf f le m m m —{RShuf f le , Ri } = RShuf f le

2

The transformation functions take in input pairs of rules similarity and return a single similarity which is the combination of the two. The functions are commutative, so the order of which the rules appear in the functions does not matter. Again, the order of functions used in a policy similarity process is not important, given the order in which the rules appear in the policy is not relevant. Example 3. In our running example, the application of the transformation functions to the rules similarity computed in Example 2 will generate the following values: P ermit —The similarities computed when comparing LibA and LibB policies are RConverge , Deny RShuf f le Deny —The similarities computed when comparing LibA and LibC policies are RRestrict P ermit and RExtend 4

STEP3: Apply rules combination algorithms As a final step, we consider in the process the rule combination algorithms specified by the two policies. Four cases are possible: Step 3a. Both policies specify “Permit Override” as rule combination algorithm. This is the simplest case. Given that we assumed a policy is denied if the AC decision is either “Deny” of “Not Applicable” (because of least privilege principle), the policy similarity can be computed considering the similarity of the Permit rules only. Formally: ACM Journal Name, Vol. V, No. N, Month 20YY.


·

11

Definition 2. Let pm and pn be two policies defined using “Permit Override” as rule combination algorithm. Moreover, let i, j ∈{Converge, Diverge, Restrict, Extend, Shuffle} be similarity values. The policy similarity between pm and pn is computed as follows: {RiDeny , RjP ermit } = j 2 Step 3b. Both policies specify “Deny Override” as rule combination algorithm. This scenario is more complex. In fact, it is important to consider that for a policy to be “Permit”, not only no “Deny” rules exist that are satisfied, but also the context request must satisfy at least one of the rules the Effect of which is “Permit”. In this context, the policy similarity is computed as follows: Definition 3. Let pm and pn be two policies both defined using “Deny Override” as rule combination algorithm. Moreover, let i, j ∈{Converge, Diverge, Restrict, Extend, Shuffle} be similarity values. The policy similarity between pm and pn is computed as follows: Deny —{RConverge , RjP ermit } = j Deny P ermit —{RDiverge , Rj(j6 =Diverge) } = Shuf f le P ermit —{RiDeny , RDiverge } = Diverge Deny P ermit —{Ri(i6 =diverge) , RShuf f le } = Shuf f le Deny P ermit , Rj(j∈[Converge,Extend]) } = Extend —{RRestrict Deny P ermit —{RRestrict , RRestrict } = Shuf f le Deny P ermit —{RExtend , Rj(j∈[Converge,Restrict]) } = Restrict Deny P ermit —{RExtend , RExtend } = Shuf f le

2

Step 3c. One policy specifies “Permit Override” whereas the other policy specifies “Deny Override”. In this scenario, the similarity computed for the “Permit” rules represents, for both rules combination algorithms, the sets of requests authorized by the two policies. However, while in case of “Deny Override” such set of authorized requests has to be pruned from the requests which satisfy at least one “Deny” rule, no pruning is needed in case of “Permit Override”. Therefore, the policy similarity is computed as follows: Definition 4. Let pm and pn be policies Moreover, let i, j ∈{Converge, Diverge, Restrict, Extend, Shuffle} be similarity values. If pm specifies “Permit Override” and pn specifies “Deny Override” as rule combination algorithms, the policy similarity between pm and pn is computed as follows: P ermit —{RConverge,Extend , RiDeny } = Extend P ermit —{RDiverge , RiDeny } = Diverge Deny P ermit —{RRestrict,Shuf } = Shuf f le f le , Ri

On the other hand, if pm specifies “Deny Override” and pn “Permit Override”, the policy similarity between pm and pn is computed as follows: P ermit —{RConverge,Restrict , RiDeny } = Restrict P ermit —{RDiverge , RiDeny } = Diverge ACM Journal Name, Vol. V, No. N, Month 20YY.

12

·


Deny P ermit —{RExtend,Shuf } = Shuf f le f le , Ri

2

Example 4. In our example, the policy similarity computed for the policies specified by LibA and LibC (both using “Deny Override”) is “Extend” because the similarity computed for the “Deny” rules is “Restrict” and the one computed for the “Permit” rules is “Extend”. This mean that all requests authorized by LibC will be authorized by LibA whereas the opposite is not true. On the other hand, the similarity between the policies specified by LibA and LibB is “Restrict” because the similarity for the “Permit” rules is “Converge” whereas the similarity for the “Deny” rules is “Shuffle”. Therefore, all requests authorized by LibA are also authorized by LibB. In addition, there are requests which will be authorized by LibB and denied by LibA. 4 5. POLICY INTEGRATION ALGORITHMS As discussed in the previous section, to complete the policy integration process, the policy similarity must be combined with the policy integration requirements of all subjects involved. As briefly introduced in Section 1, in a service virtualization model it is likely for both subjects sharing their resources and subjects using such resources to provide their services to specify the behaivour of its policies when integrated with the ones specified by others. Therefore, in case of services involving multiple independent and autonomous entities, the XACML approach according to which all PoEs are managed by a single centralized entity has to be replaced by a more flexible solution. An approach is to assume each RO, at which policies will be ultimately enforced, to perform policy integration between its policy and the ones of third parties (DOs) using its resources by using its own PoE. In this context, the owner of the PoE (PoE owner ) can specify a PoE owner policy integration requirement, which indicates the approach to be used in case its PoE is asked to evaluate policies specified by other entities. The available PoE owner policy integration requirements are the following: —Converge Override. This is the most restrictive case in which the PoE owner specifies its PoE should not be used to evaluate policies other than the ones defined by the PoE owner. —Restrict Override. This specifies that the PoE can be used to evaluate third party policies only if they do not authorize requests which are denied by the policies specified by the PoE owner. —Deny Override. As in XACML, this specifies that the PoE can evaluate policy specified by a third party entity. A context request is then authorized only if both policies are Permit. The difference with “Restrict Override” is that in this case the PoE owner evaluates any policy, whereas in case of “Restrict Override” only non conflicting policies are considered for evaluation. —Permit Override. This specifies that the PoE can evaluate any policy specified by a third party entity. A context request will be authorized if at least one of the two policies is Permit. ACM Journal Name, Vol. V, No. N, Month 20YY.


·

13

PoE Guests Policy Int PoE Owner Preference Policy Int.Preference

Fig. 3.

Policy Integration Results

Like the PoE owner also the subject, called PoE guest, the policy of which will be evaluated by a PoE owned by a third party subject, can specify its policy integration requirement. As example, in our Lockss scenario, a DO might be interested to specify that no requests authorized by the DO policy should be denied access to the data. Such requirement, called PoE guest policy integration requirement, takes one of the following values: —Restrict Override. This is the case in which the most important security goal of the PoE guest is to prevent unauthorized accesses to the information. On the other hand, the PoE guest might accept that PoE might deny accesses to some of its authorized users. —Extend Override. Unlike the previous case, protection from denial of service is the main security goal of the PoE guest. In other words, the PoE might accept unauthorized requests but should not deny access to any request authorized by the PoE guest. —Converge Override. This is the most restrictive scenario in which the PoE guest requires its policies to be fully enforced by the PoE. In other words, the PoE must authorize only each and every requests authorized by the PoE guest. When two policies are integrated, the policy integration requirements of both PoE guest and PoE owner have to be satisfied. To achieve such goal, the two requirements are combined by using the policy similarity computed in the previous section. Given PoE owner and PoE guest requirements, Figure 3 shows the set of policy similarities which guarantee both policy integration requirements to be satisfied. In the Figure, the rows represent the PoE owner requirements, whereas the columns represent the PoE guests requirements. Again, the values in the cell represent which policy similarities values guarantee the restrictions set by the two subjects. Example 5. Consider our running example. Assume LibA, the PoE guest, has specified “Converge Override” as policy integration requirement, whereas LibB, the PoE Owner, has specified “Deny Override”. In this scenario, the policy integration ACM Journal Name, Vol. V, No. N, Month 20YY.

14

·


is possible because the policy similarity computed for these two parties is “Restrict”. Therefore, replicating LibA data in LibB storage will guarantee that all requests authorized by LibA will get access to both the resources and the data. On the other hand, there are no requests which could violate LibA policies and gain access to the data only because authorized by the party, that is, LibB, hosting the data. The same does not apply if LibA replicates its data at the storage resource owned by LibC. In fact, if LibC specifies “Deny Override”, the policies cannot be integrated because the similarity is “Extend” and therefore there might be requests authorized by LibA which will not be authorized to access to resources of LibA. Under our approach the policy combination is thus not super-imposed by an “enterprise administrator” that, as in XACML, can decide on all the policies and the PoEs of the enterprise, but it is dynamically computed by considering the requirements of the parties involved and the XACML policies they specify. 6. POLICY HINTS Policy similarity determines how two policies relate with respect of the sets of requests they authorize. For instance, saying two policies Converge means that both policies exactly authorize the same sets of requests. Policy similarity is needed in case of a request has to be evaluated against a collection of policies specified by multiple independent and autonomous entities. The collaborative storage system illustrated in Section 3 is an example of system requiring policy similarity. In such systems, usually there is not an administrator deciding upon the behavior of all PoEs, but each PoE owner is free to decide if and how to enforce the policies specified by other entities. In this context, policy integration algorithms have been introduced to protect security requirements for both subjects sharing resources and PoEs and subjects sharing only resources (and relying on PoEs made available by others for enforcement). As example, in our motivating scenario the combination of policy similarity and policy integration algorithms help DO to decide which RO should hosts its data such as no requests, other than the ones he authorizes, will be granted access. Although policy similarity and policy integration algorithms give valuable information concerning the process of integrating XACML, this is not enough. Consider again our collaborative storage systems scenario. According to table in Figure 3, if DO policy Extends RO policy and RO PoE owner is Deny Override, than DO can replicate its data in the RO without the risk that no unauthorized requests will get access to DO data. However, some requests authorized by the DO might get rejected because failing RO policies. Therefore, how the DO can select the ROs such that all its authorized requests will be served To answer such questions, in this section we introduce the notion of Policy Hints which characterizes the difference between two XACML policy. Policy Hints is a set containing the following three policies: Restrict Pol, Extend Pol, and Integrate Pol. Specifically, when comparing poli and polj policies, we call Restrict Pol the policy which authorizes all the requests which are authorized by polj and denied by poli . On the other hand, we call Extend Pol the policy which authorizes all the requests which are authorized by poli and denied by polj . Finally, we call Integrate Pol the policy which authorizes all requests authorized by both poli and polj . ACM Journal Name, Vol. V, No. N, Month 20YY.


·

15

Example 6. To understand how Policy Hints is used, consider Example 1 with an additional RO, Library D, which has the following policy: Library D (LibD) policy: Any user with an e-mail name in the “.edu” or in the “.gov” namespace is allowed to perform any action on any resource. However, requests entered between 8a.m to 8p.m. should be denied the access. The XACML specification of LibD policy is reported in Appendix. LibD adopts “Deny Override” as rule combination algorithm. In this example, the Restrict Pol (the requests authorized by LibD (RO) and not by LibA (DO)) computed as a difference between LibA and LibD authorizes the requests entered between 12a.m. and 8p.m. By knowing such information, LibA knows which changes it has to make on its policies to be able to secure replicate its data into LibD’s data storage. On the other hand, if LibD would authorize requests only from 8a.m. to 10a.m., the Policy Hints will contain, as Extend Pol (the requests authorized by LibA (DO) and not by LibD (RO)) a policy which authorizes the requests issues between 10a.m. and 12p.m.. Such information is useful for LibA to decide which additional ROs to select in order to download the information and to have all its requests accepted. 4

The process for computing Policy Hints is specified in Algorithm 6. The algorithm takes an approach similar to the one described in Section 4. It takes in input two policies (pi and pj ) and, for each rule ri in pi , searches a rule rj in pj the policy attribute of which corresponds to the one in ri . If such rj exists, the system extracts the rule similarity by comparing the set of values which validate the two logical expressions. The process continues by extracting a rule whose validated requests are the one validated by rj and not by ri . we denote such process as rj - ri . Based on the rule similarity, such expression is either added to Restrict Pol, Extend Pol or Integrate Pol. If pj does not contain rules defined with the same policy attribute as ri , ri is added to Restrict Pol and the policy similarity set to Extend. Once the algorithm has processed all rules in pi , it continues by processing all the rules in pj , the policy attributes of which are not specified into pi ’s rules. if such rules exist, the policy similarity is set to Restrict (or Shuffle in case it was previously set to Extend) and the rules added to Restrict Pol. Example 7. Consider the policies introduced in Example 7. The policy hints computed between policyLibA and policyLibD would contain the following policies: Restrict Pol : Requests entered between 12.a.m to 8a.m. should be granted the access. Restrict Pol : null; Integrate Pol : Any user with an e-mail name in the “.edu” or in the “.gov” namespace is allowed to perform any action on any resource. However, requests entered between 8a.m to 12a.m. should be denied the access. 4 Note that like policy integration algorithm, policy hints algorithm does not specify the result of the AC decision. In fact, such decision is up to the specific AC system and might change based on the subjects participating to the AC decision. In the next section, we will demonstrate the use of Policy similarity, policy integration algorithm, and policy hints in a system we have implemented to support secure replication of data across peers each one potentially specifying different auACM Journal Name, Vol. V, No. N, Month 20YY.

16

·


INPUT: Two policies poli and polj OUTPUT: Policy Similarity Type, Pol Sim Restrict Pol and Extend Pol, and Integrate Pol For each policy rule rulei ∈ poli Do Begin Mark rulei as visited If rulei .pol att defined into polj Let rulej ∈ polj the rule such as rulej .pol att = rulei .pol att Mark rulej as visited compute Rule similarity type between rulei and rulej Case rule similarity “Converge”: Pol Sim=“Converge”; add rulei to Integrate Pol; “Diverge”: Pol Sim=“Diverge”; Restrict Pol=Extend Pol=Integrate Pol = ∅; Exit; “Restrict”: add rulej - rulei to Restrict Pol; add rulej - rulei to Integrate Pol If Pol Sim==“Extend” Then Pol Sim=“Shuffle” If Pol Sim!=“Shuffle” Then Pol Sim=“Restrict” “Extend”: add rulei to Extend Pol; add rulei to Integrate Pol If Pol Sim==“Restrict” Then Pol Sim=“Shuffle” If Pol Sim!=“Shuffle” Then Pol Sim=“Extend” “Shuffle”: add rulej - rulei to Restrict Pol;add rulei - rulej to Extend Pol add rulei - (rulei - rulej ) to Integrate Pol Pol Sim=“Shuffle” Else /* rulei .pol att is not defined in pj */ add rulei to Restrict Pol; add rulei to Integrate Pol If Pol Sim=“Restrict” Then Pol Sim=“Shuffle” If Pol Sim!=“Shuffle” Then Pol Sim=“Extend” End For each policy rule rulej ∈ pj Not Marked Do Begin /* rulej .pol att is not defined in pi */ Mark rulej as visited add rulej to Extend Pol; add rulej to Integrate Pol If Pol Sim==“Extend” Then Pol Sim=“Shuffle” If Pol Sim!=“Shuffle” Then Pol Sim=“Restrict” End If Pol Sim==“Extend” Then Integrate Pol=pj If Pol Sim==“Restrict” Then Integrate Pol=pi Fig. 4.

Policy Similarity Algorithm



·

17

thorization policies. 7. IMPLEMENTATION 7.1 Policy Integration

Seconds

To analyze the performance of the proposed policy integration process, we have developed a prototype using Java and XACML. Specifically, we have implemented the policy integration process using JXACML [Sun ], a java API which includes a PDP (Policy Decision Point) and a PEP (Policy evaluation point) to evaluate XACML policies. The main task we have carried out has been overwriting the functions XACML provides for rule evaluation. The new functions, instead of evaluating policy rules based on the information in the request profile, compute the rule similarity according to the approach described in Section 4 (step 1). To collect the policy integration algorithms, we extended the XACML framework with two new tags, that is, and ; the values of these tags are the values described in Section 5. To assess our approach, we have developed a tool which generates well-formed XACML policies with a random number of rules. The policy rules have been created using predefined policy attributes and logical expressions defined using different types of functions. The experiments were conducted on a Pentium4 3.2 Ghz, 512 Mb Ram machine. Figure 5 presents the cumulative cost of our process when integrating a policy composed by four rules with up to 10.000 policies, each one composed by a number of rules ranging between one and four. 1,6 1,4 1,2 1 0,8 0,6 0,4 0,2 0

1 Rule 4 Rules

2000

Fig. 5.

4000 6000 Num peers

8000

10000

Performance of the policy integration process. One and Four Rules per Policy

As the graphs reported in the figure show, the process scales well even when a policy is integrated with large number of other policies. Such result is important because, as we will discuss in the next subsection, one of the possible applications of our policy integration process is to select, among a large number of resources, the ones the XACML policies of which are compliant with the security constraints of the subjects requesting the resource. The reported results are also very encouraging because the current version of our approach do not take into consideration possible techniques to organize policies for efficiently evaluating a large number of constraints. In this respect, our previous work [Mazzoleni et al. 2005] demonstrates how it is possible to efficiently evaluate ACM Journal Name, Vol. V, No. N, Month 20YY.

18

·


a large number of XACML policies if they are grouped according to rules and organized based on those. We plan to enhance our approach to policy integration with such a strategy for organizing the policies. 7.2 Secure replication service To demonstrate the applicability of our solution, in this section we discuss the data replication service we have implemented to share data across Collaborative Storage Systems in which both DOs and ROs can autonomously specify (and enforce) XACML policies. Referring to our LOCKSS example, the replication service can be used by LibA (DO) to choose on which libraries (ROs) can replicate its content without violating each other policies. The input of the service is the policy the DO wants to enforce on the information to be replicated. The service first apply Algorithms 1 and computes policy similarity and policy difference between the policies of the ROs available to store information 4 and the one specified by the DO. The next step, in which DO selects the ROs in which to replicate the information, is semi-automatic: the DO is free to select the ROs in which to replicate its data whereas the data replication service guarantees the following two conditions are verified: (A) No access requests could bypass the AC policy of the DO and get access to the information only because authorized by the RO hosting the information and (B) All requests authorized by the DO should find at least a RO, among the ones which will host the information, the policy of which will authorize the request to access the physical resource. The first condition is verified by pruning from the ROs available to host DO information the ones the policy similarity of which is Diverge and by replicating Restrict Pol along with the information in case RO Enlarge DO policies and RO is willing to enforce DO policies. On the other hand, to verify the second condition, the tool orders ROs based on the amount of requests authorized by the DO will get access to the RO physical resources. The idea is to support DO suggesting the ROs which will grant access to as many of the requests he authorizes as possible. In this context, we built a RO coloring process according to which ROs are organized into the following four groups (identified by different colors): —Green ROs. These are ROs the policies of which authorize all the requests authorized by the DO. —Yellow ROs. These are ROs the policies of which authorize only some of the requests authorized by the DO. —Red ROs. Like yellow ROs, these are ROs the policies of which authorize only some of the requests authorized by the DO. Different from yellow ROs, Extend Pol of Red ROs contain some rules the policy attributes of which are not used in the DO policy. Red ROs are less adapt to host DO information than Yellow ROs because a request, other than be authorized by the DO, need to provide additional attributes (not needed by the DO) in order to get access to the resource. 4 In

this paper, we intentionally omit the problem of distributing the replication service to avoid bottleneck. Existing solutions developed for P2P systems can be applied here ACM Journal Name, Vol. V, No. N, Month 20YY.


Fig. 6.

·

19

Data Replication Tool - Java Interface

—Black ROs. These are ROs the policies of which do not authorize any request authorized by the DO. In a nutshell, to color a RO, the coloring process analyzes the Enlarge Pol policy and verifies if the policy rules are defined using attributes not defined in the Content Access policy. Each time a DO selects a RO, the data replication service re-orders the remaining ROs highlighting the ones the policies of which grant access to DO authorized requests not yet authorized by any of the selected ROs. The implementation of the service replication service has been done in Java whereas JSP has been used to build the Web-based interface. A graphical user interface for the data replication service has been implemented both as stand alone application and web application. The screenshots of the two interfaces are illustrated in Figure 7 and 0??. As shows in the Figures, the service presents to the DO the ROs each one colored according to the criterion discussed above. In addition, for each available RO, the DO can access the Restrict Pol and the Enlarge Pol policies. In the Figures, Host selected and Hosts coverage represent respectively the number of ROs selected to host the information and the minimum number of ROs which will grant access to each DO authorized request. By construction, if the DO selects a green RO to host its information, then host coverage and host selected correspond. On the other hand, in case the DO selects yellow or red ROs, the number of selected hosts will be less than the number of coverage hosts. To test our solution, we compare the performance of computing policy similarity and policy difference with the algorithm used to organize to color the ROs. We assume each RO has only one Resource Access policy. The experiments were conducted on a Pentium4 3 Ghz, 1 Gb Ram machine. Figure 8 presents the results ACM Journal Name, Vol. V, No. N, Month 20YY.

20

·


Fig. 7.

Data Replication Tool - Web Interface

of a specific experiment we have carried out to analyze the computational cost of integrating and coloring up to 15.000 RO policies each one composed by a single policy rule. In the Figure, the first line represents the cost of Algorithm 1 whereas the second is the additional cost of coloring the ROs. As shown in the figure, the incidence of coloring the ROs once the policy similarity has been computed, is between 20% and 40% of the total cost. However, if the ROs specify more complex rules, such incidence decreases. As example, Figure Figure:4RuleColoring presents another experiment in which policies to be integrated are all composed of four rules. In this second example, the incidence of the policy organization is always less than 25%. This because the performance of the ROs coloring process is related to the number of Extend Pol policies generated by integrating DO and ROs policies. ROs the policy of which diverge the one specified by the DO are labeled as Black RO and pruned from the list of available ROs. However, our experiments demonstrated both processes scale well even with large number of ROs’ policies. 8. RELATED WORK Since XACML has been proposed as standard by OASIS, a lot of work has been done to apply the language to multiple distributed scenarios ranging from Web Services to Grid systems. A comprehensive (even if not complete) list of references related to XACML can be found in [OASIS 2006]. Note that in this paper we focus on XACML and we do not propose a generic solution to integrate business policies specified using any XML-based language. Therefore, approaches based on other languages [W3C 2004b; OASIS 2002; OMG ] are orthogonal to the problem addressed in this work. Again, solutions proposing ACM Journal Name, Vol. V, No. N, Month 20YY.

Seconds

XACML Policy Integration For Distributed Systems 2,75 2,5 2,25 2 1,75 1,5 1,25 1 0,75 0,5 0,25 0 1000

·

21

Policy Organization Matching Time

3000

5000

7000

9000

11000

13000

15000

Num of Policies

Seconds

Fig. 8.

Peer coloring performance - 1 rule per policy

2,75 2,5 2,25 2 1,75 1,5 1,25 1 0,75 0,5 0,25 0 1000

Policy Organization Matching Time

3000

5000

7000

9000

11000

13000

15000

Num of Policies

Fig. 9.

Peer coloring performance - 4 rules per policy

semantic models to determine policy equivalence [Huang 2005; W3C 2004a] can be used in combination with our policy integration process in case policies are defined using different vocabularies. An interesting solution is proposed by [Backes et al. 2004]. They propose an efficient algorithm for checking refinement between two privacy policies. The work is relevant to our since refinement is a subset of the general problem of integration. Compared to our work however, they limit their study only to privacy policies and only to the problem of refinement, Also, their study is on EPAL rather than XACML. This is an important difference since the only rules and policies combination algorithm defined by EPAL is First-one-applicable. Barth, Mitchell, and Rosenstein [Barth et al. 2004] have described some of the language issues that arise from this choice of conflict resolution algorithm. One significant issue is that two policies cannot be merged automatically (such as when two organizations merge). Among the papers addressing XACML policies, [Zhang et al. 2004], present a translator from RW language to XACML. AC policies specified in RW can be verified algorithmically and the translation into XACML can be guaranteed to produce systems which correctly implement the required AC policies. However, they do not address the problem of integration neither of the RW policies nor of the resulting XACML policies. More relevant to our work is the approach presented by the Web Service Policy Constraints Language, WSPL [Anderson 2004; 2005b; Morr 2004b] on the use of XACML to manage authorization in the Web Service domain. The language ACM Journal Name, Vol. V, No. N, Month 20YY.

22

·


proposes solutions to specify, verify, and apply constraints on the set of policy attributes included in a policy. In addition, the language proposes an interesting approach to intersect two policies. The intersection of two policies is a single policy that will validate exactly a set of context requests that is the intersection of the sets of context requests validated by the two policies. At first sight, such an intersection approach might look similar to the approach presented in this paper. However, WSPL considers neither rule Effects nor XACML rules combination algorithms in the intersection. The policy intersection is simply computed by taking the cross product of the policy rules in the two policies. Like our solution, policy rules specifying the same attributes are compared based on the conditions they use. However, if the intersection of two rules is “Diverge”, the constraints are incompatible and simply eliminated by the integrated policy. Two policies are incompatible only if all the policy rules are incompatible. By comparing WSPL intersection policy with our policy integration solution, we can say that WSPL solves the policy integration policy only if the policies contains “Permit” rules only and they both specify “Permit Override” as combination algorithm. While such assumption is adapted to identify for instance an acceptable value for price or encryption mechanisms, we believe it is an oversimplification for many other cases. More recently, [Fisler et al. 2005] proposed Margrave, a tool that given in input some properties determine whether a XACML policy satisfies or not these properties. Margrave can perform also an automated change-impact analysis on the policy to determine the impact of changing one or more rules on the whole policy. This is particularly useful for very complex policy. The motivation of their work however is quite different than ours. Their work is motivated by the need of simplifying policy maintenance. Our work is motivated by the need of integrating different policies defined by independent entities and to know the effect of such integration on the set of access requests that satisfy the policy resulting by the integration process. 9.

CONCLUSION AND FUTURE WORK

In this paper, we have addressed the problem of integrating two well-formed XACML policies specified by autonomous parties. A key characteristic of the proposed integration process is that it allows parties to specify their preferences concerning the approaches to be used to integrate their policies with the policies specified by other parties. According to our solution, the policy integration process is not carried out offline by a central “enterprise administrator”, as in XACML, but it is dynamically carried out based on the requirements of all parties involved. Our proposed solution consists of three parts: a policy similarity process, a policy integration algorithm and a policy difference process. The similarity process is used to identify which policy is the most restrictive, such as the policy which authorizes the smaller set of requests. Other than the rule conditions, the similarity process takes into account XACML rules effects and XACML rule combination algorithms. Policy integration algorithm is an XACML extension through each resource owner can specify the approach to be follow if its policies need to be integrated with others. With our solution, it is now possible to implement systems in which the XACML policies of ACM Journal Name, Vol. V, No. N, Month 20YY.


·

23

all parties involved are considered and flexibly integrated. Finally, we presented an algorithm to compute the policy difference. This is used along with the policy similarity value to extract the policies the authorized requests of which are the requests either authorized by both policies or the set of requests authorized by a policy and not by the other. Recalling our motivation scenario. Knowing the set of requests authorized by the RO policy and not by the DO policy is useful to the DO in order to replicate its data in several ROs and making sure that all requests authorized by the DO to find at least a RO in which to access both data and resources. The implementation of our proposed solution is quite comprehensive and the data replication service can potentially be used in combination with many existing applications. As a future work, we plan to extend our approach by relaxing some constraints we had put on the XACML polices. For instance, we plan to consider also Obligations. Moreover, we intend to generalize the policy integration process to be able to integrate any number of policies. In Section 5, we defined the policy integration for the approach where the PoE owner performing the integration is the RO. As a future work we extend the policy integration process to other approaches as for example the one where both ROs and DOs buy the PoE as an external service from a third party. REFERENCES Anderson, A. 2004. An introduction to the web services policy language. In IEEE Policy 2004 Workshop. Anderson, A. 2005a. A Comparison of Two Privacy Policy Languages: EPAL and XACML. Anderson, A. 2005b. Ws-policyconstraints: A domain-independent web services policy assertion language. Backes, M., Bagga, W., Karjoth, G., and Schunter, M. 2004. Efficient comparison of enterprise privacy policies. In Proceedings of the ACM Symposium on Applied Computing. Baker, M., Kimberly, K., and Sean, M. 2005. Why traditional storage systems do not help us save stuff forever. HPL-2005-120. HP Labs 2005 Technical Reports. Barth, A., Mitchell, J. C., and Rosenstein, J. 2004. Conflict and combination in privacy policy languages. In Workshop on Privacy in the Electronic Society. EU. 1995. Eu directive on data privacy 95/46/ec. Fisler, K., Krishnamurthi, S., Meyerovich, L., and Tschantz, M. 2005. Verification and change impact analysis of access-control policies. In International Conference on Software Engineering (ICSE). HIPAA. 1996. U.s. government department of health and human services health. Insurance Portability and Accountability Act. HP. 2005. Virtualized infrastructure solutions for mysap business suite. http://h71028.www7.hp.com/enterprise/downloads/HP-virtualSAP Solution-Brief.pdf . Huang, D. 2005. Semantic policy-based security framework for business processes. In 4th Semantic Web and Policy Workshop. IBM. 2004. Automate and integrate within and across it processes to support the continually changing needs of business processes. IBM White paper . Kusnetzky, D. and Olofson, C. W. 2004. Oracle 10g: Putting grids to work. http://www.oracle.com/technology/tech/grid/ collateral/idc oracle10g.pdf . Lionshare. Project [online]. http://lionshare.its.psu.edu/main/ . Lockss. Project [online]. http://lockss.stanford.edu/ . ACM Journal Name, Vol. V, No. N, Month 20YY.

24

·


Lorch, M., Proctor, S., Lepro, R., Kafura, D., and Shah, S. 2003. First experiences using xacml for access control in distributed systems. In XMLSEC ’03: Proceedings of the 2003 ACM workshop on XML security. ACM Press, New York, NY, USA, 25–37. Mazzoleni, P., Crispo, B., Sivasubramanian, S., and Bertino, E. 2005. Efficient integration of fine-grained access control in large-scale grid services. In SCC 2005: IEEE International Conference on Service Computing. Morr, D. 2004a. Lionshare: A federated p2p app. In Internet2 members meeting. Morr, D. 2004b. Wspl: an xacml-based web services policy language. In Internet2 members meeting. OASIS. 2002. ebxml collaboration protocol profile and agreement technical committee. Collaboration-Protocol Profile and Agreement Specification Version 2.0 . OASIS. 2005. Security services technical committee. e{X}tendible {A}ccess {C}ontrol {M}arkup {L}anguage Committee specification 2.0 . OASIS. 2006. http://docs.oasis-open.org/xacml/xacmlrefs.html. OMG, O. M. G. Response to the uml 2.0 ocl rfp (ad/2000-09-03), revised submission, version 1.6, 6 january 2003. OMG Document ad/2003-01-07 . Sun. Xacml implementation [online]. http://sunxacml.sourceforge.net/ . W3C. 2003. Enterprise privacy authorization language (epal). W3C. 2004a. Owl web ontology language. W3C. 2004b. W3c workshop on constraints and capabilities for web services. Zhang, N., Ryan, M., , and Guelev, D. P. 2004. Synthesising verified access control systems in xacml. In 2nd ACM Workshop on Formal Methods in Security Engineering.



·

25

The following are the policies used in our example specified using XACML: LibA Content Access policy: Any user with an e-mail name in the “.edu” or in the “.gov” namespaces is authorized to read any information. However, no authorizations should be given from 8a.m. to 12a.m. < Policy PolicyId=“LibA-Policy” RuleCombiningAlgId=“Permit-Overrides”> .gov .edu 08:00 12:00

LibB Resource Access Policy: Users are not authorized to perform any action on any resource from 10a.m. to 2p.m. However, users with an e-mail name in the “.gov” or in the “.edu” namespaces are always authorized to access. < Policy PolicyId=“LibB-Policy” RuleCombiningAlgId=“Permit-Overrides”> .gov .edu ACM Journal Name, Vol. V, No. N, Month 20YY.

26

·


10:00 14:00

LibC Resource Access policy: Any user with an e-mail name in the “.edu” namespace is allowed to perform any action on any resource. The same applies to users affiliated with HP. However, requests entered between 8a.m to 8p.m. should be denied the access. < Policy PolicyId=“LibC-Policy” RuleCombiningAlgId=“Deny-Overrides”> .edu 08:00 20:00 HP

LibD Resource Access policy: Any user with an e-mail name in the “.edu” or in the “.gov” namespace is allowed to perform any action on any resource. However, requests entered between 8a.m to 8p.m. should be denied the access. ACM Journal Name, Vol. V, No. N, Month 20YY.


·

27

< Policy PolicyId=“LibD-Policy” RuleCombiningAlgId=“Deny-Overrides”> .gov .edu 08:00 20:00
