XACML Policy Integration Algorithms - ACM Digital Library
XACML Policy Integration Algorithms (Not to be confused with XACML Policy Combination Algorithms!) P. Mazzoleni
E. Bertino
B. Crispo
CS Department University of Milan, Italy
Cerias and CS Department Purdue University, USA
[email protected]
[email protected]
CS Department Vrije Universiteit, Amsterdam DIT Department University of Trento, Italy
[email protected] S. Sivasubramanian CS Department Vrije Universiteit, Amsterdam
[email protected] ABSTRACT
goal of XACML is to propose a common language through which an enterprise can manage all the elements of its security policies in 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 [2, 3] but today it is virtually impossible to independently manage the configuration of each point of enforcement and have a complete view of the safeguards in effect throughout the enterprise [1, 4]. 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 is denied if at least one of the composing policies is evaluated “Deny”. XACML is a very rich and flexible language; users and security administrators can directly represent in XACML a large variety of AC policies. However, XACML has not been built to manage security in large distributed systems in which virtual enterprises are dynamically built with the collaboration of multiple independent subjects sharing their resources (or services) to provide new (or better) services to customers. This is the case of systems adopting the emerging business model referred to as “Service Virtualization” [5, 6, 7] in which the parties providing the services may be distributed across multiple enterprises and in which the owners of the services might be different from the parties providing the resources (e.g., memory, computing power, bandwidth, etc.) running those services. For example, the SUN grid network allows its customers to use its resources on-demand by providing highly virtualized resources. In a “Service Virtualization” scenario, applications are no longer statically allocated and managed within silos (represented by servers or clusters). Instead they can run on any server in the distributed system that provides its computing and storage resources [5, 8].
XACML is the OASIS standard language for the specification of authorization and entitlement policies. However, while XACML well addresses security requirements of a single enterprise (even if large and composed by multiple departments), it does not address the requirements of virtual enterprises built through collaboration of several autonomous subjects sharing their resources. In this paper we highlight such limitations and we propose an XACML extension, the policy integration algorithm, to address them. In the paper we also discuss in which respect the process of comparing two XACML policies differs from the process used to compare other business rules.
Categories and Subject Descriptors D.4.6 [Security and Protection]: Authorization
General Terms Security, Language, Standardization
Keywords XACML, Security policies integration, Distributed Systems, Web Services,Content Distributed Networks
1.
INTRODUCTION
XACML (Extensible Access Control Markup Language) is the OASIS standard language for expressing access control (AC) policies [1] in large enterprise systems, that often have many policy elements and points of enforcement (PoE). The
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SACMAT’06, June 7–9, 2006, Lake Tahoe, California, USA. Copyright 2006 ACM 1-59593-354-9/06/0006 ...$5.00.
219
In such scenarios, all parties in the system can independently specify fine-grained authorization constraints to protect their resources. Under these conditions, it is however unclear which entity should be entitled to choose the approach to be used for integrating the policies specified by the various parties. The problem of conflicting policies can occur even more frequently than the cases of single enterprises composed by multiple sectors. Consider, as example of “Service Virtualization” system, a Content Distribution Network (CDN) built on P2P network in which parties can replicate their data in storage made available by third party resource providers. Real systems adopting this model are for instance Lockss [9, 10] and LionShare [11, 12]. In such scenario, both the owner of the data and the owner of the storage can specify their XACML policies. The former can place constraints on where its data can be placed and which subjects can read it, while the latter can place constraints on which subjects can upload and download information from its resources. To take authorization decisions upon subjects requesting access to some data available the network, 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. Despite some previous work has applied XACML to distributed environments [13, 14, 15], XACML policy combination algorithms are not enough to integrate policies specified by parties which are autonomous and which might not be willing to share or lease the ownership of their resources. This because XACML assumes all PoEs be available to enforce any policy (or combination of policies) set by any party in the enterprise and there always exists an “enterprise administator” who can solve conflicts. However, this is not the case of scenarios in which PoEs are administered by autonomous parties. For instance, in the CDN scenario, a RO might not be willing to evaluate policies for each and every DO storing some data in its resources. Again, approaches [16, 17] for the integration of AC policies either consider non standard languages or make assumptions which oversimplify XACML. In this paper we propose an XACML policy integration process specifically developed for distributed systems in which the involved parties can autonomously specify their AC policies. Applications of our solution can be found in a large variety of domains, such as Web Service technology, organizational data sharing, CDN systems, and Grid. The solution we propose has two key components: a policy similarity process and a policy integration preferences. The policy similarity process is the process through which policies are compared with respect of the sets of requests they authorize. Given two policies, the policy similarity determines which policy is the most restrictive. On the other hand, the policy integration preferences is an XACML extension by which a party can specify the approach to be taken if their policies have to be integrated with others. The rest of the paper is organized as follows: Section 2 gives a brief overview of the main components of XACML. Section 3 presents a motivating example to demonstrate the limitations of XACML when applied to distributed systems. The following two sections are the core of the paper: Section 4 proposes the policy similarity process, whereas Section 5 presents the policy integration preferences. Section 6
Figure 1: XACML rule and policy combination algorithms
presents an overview of the implementation of our approach. Section 7 compares our solution with the state of the arts and Section 8 concludes the paper and outlines future work.
2. XACML POLICY LANGUAGE The formalism for specifying AC policies in XACML 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 predefine a list of attributes; instead it specifies a list of (normative) datatypes that subjects and/or communities can use to create the attributes which are valid for a given system. String, Time, Boolean, Double, and AnyURI are some examples of valid data-types. Similarly, functions are possible operators which can be used for normative data-types. String-Equal, Greater-Then, Date-Equal, String-Is-In, and AnyURI-OneAnd-Only are examples of valid functions. Rule. A rule is the basic element of a policy. It identifies a complete and atomic authorization constraint which exists in isolation with respect to the policy in which it has been created. A rule is composed by a Target, to identify the set of requests the rule is intended to restrict, an Effect, which is either “Permit” or “Deny”, and a set of Conditions which represent 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 rule combination algorithm specifies the approach to be adopted to compute the decision result of a policy containing rules with conflicting Effects. The XACML normative rule combination algorithms 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 decision has to consider AC requirements of 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 the rules of a given policy, that is, the ones in Figure 1.
220
An XACML policy can also include Obligations, which represent functions to be executed 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 DO). 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 is based on three main entities: 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 requests from the native format to the XACML canonical form and to convert the authorization decision from XACML to the native format supported by a PEP. In a nutshell, an access request is evaluated as follows. The requester sends a request to a PEP which in turn contacts the context handler in charge of converting the attributes of the subject, resource, action, and environment describing 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 applicable to the request. A rule is applicable to a request if the information in the request context satisfies both the rule target and the rule condition predicates. If these predicates are not verified, the rule is “Not applicable” and its Effect ignored. A policy is “Not applicable” if no policy rule applies to the request. The rule combination algorithm is used to resolve conflicts among applicable rules with different Effects, whereas the policy combination algorithm is used to resolve conflicts among applicable policies. 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 authorization decision concerning the request.
3.
In addition, assume Bill to be a DO hosting his data into storage owned by third party subjects. The AC policy Bill wishes to enforce for users requiring access to his data is the following: BILL 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 Jane and Bill adopt “Deny Override” as rule combination algorithm whereas John adopts “Permit Override” rule combination algorithm. In this simple scenario, Bill can either store his data in John or in Jane storage. However, it is not clear which policy combination algorithm, among the ones defined by XACML, has to be used to combine DO and RO policies and which party is entitled to decide it. “Permit Override” cannot be used because the resource owner might not accept its storage be accessed by unauthorized subjects. Also, “Permit Override” will create situations in which a subject is given access to the data, thus bypassing the DO policy, only because the subject is authorized to access the storage hosting the information. On the other hand, “Deny Override” cannot be used as the RO might not be willing to assume the extra task of evaluating all the policies of all the DOs storing information into its storage. At the same time, the DO might not accept that some of its authorized users will be denied access to its data only because hosted by a RO the policy of which deny the access to the resource. Finally, using “Deny Override” to combine RO and DO policies might lead to a scenario in which no user will be authorized to access the requested resources. For instance, suppose that a DO, the policy of which authorize access to the data only to users with an email in the “.edu” namespace, stores its data in a third party RO. Moreover, suppose the policy of the RO hosting such information gives access only to subjects the email of which are in the “.com” namespace. In such case, the “Deny Override” combination algorithm results in denying access to all requests wishing to access DO information. In general, in scenarios in which policies are specified by multiple autonomous parties, all interested in controlling their resources (either physical or logical), it is not clear which party is entitled to set the policy combination algorithm. In a distributed system the underlying relationship among the parties is peer-to-peer rather than hierarchical. In other words, while it is reasonable to think that there exists a unique policy administrator which decides upon integrating multiple rules, this is not always the case when dealing with policies specified by autonomous subjects. 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 involved parties. In our solution, we address such a problem by extending the XACML language with a set of policy integration preferences. Those preferences can be specified by all subjects involved in the system and aim at collecting users requirements with respect of the approach to be followed in case their policies have to be integrated with policies of other parties. The decision about policy integration is therefore dynamically computed by taking into account the requirements of all involved subjects.
MOTIVATING EXAMPLE
The policy integration method we propose in this paper can be applied to several applications ranging from Web Services to Grid systems. However, in the following we motivate our work by presenting a very simple scenario related to the CDN introduced in Section 1. In this scenario, let us assume Jane and John be two ROs making available their resources to host third party information. Consider the following be the policies John and Jane want to apply to protect access on their resources: JANE 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. JOHN 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.
221
4.
POLICY SIMILARITY
Before introducing the policy integration preferences, we need to analyze the behavior of the policies to be integrated with respect of the requests they authorize. In other words, we need to determine whether there are requests authorized by a policy and denied by another. In this section, we describe the process for computing such information which we refer to as Policy Similarity. 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 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 that have 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 a policy. In such context, it is important to recall that the “Not Applicable” rules, that is, the rules the conditions of which are not verified by the context request, do not take part in the authorization decision. For example, a rule denying access from 8a.m. to 8p.m. does not give any indication, in terms of authorization, about 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 that the least privilege principle applies, that is, a request is denied if the evaluation of the XACML policy for 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 each composed of multiple rules, 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 their data types and functions extracts and compares the sets of values for which their expressions hold. In our work, we simply adopt syntactical analysis to identify policies specifying the same attribute. The use of more complex rule comparison methods using patterns or semantic analysis are outside the scope of this paper; they could however be easily integrated in our solution. As graphically illustrated in Figure 2, we distinguish five types of rules similarity:
Figure 2: Policy Rule similarity type
its condition holds is a subset (superset) of 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 a subset of the other. Example 1. In our CDN example, the rule similarity computed between Bill and John policies are the following: the Bill e-mail rule “Extends” John email rule, whereas Bill rule on Time “Restricts” time rule set by John. A different approach is taken for rules the policy attributes of which are specified in one of the two policies only. In this case, the above strategy cannot be applied because there are no two sets of values that can be compared. In such case, the rule similarity is computed considering which one of the two policies contains the extra rule. Therefore, when computing the similarity between policies pi and pj , if pi has a policy 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”. In the rest of the paper we refer to the rule similarity Ef f using the notation P ol AttRule sim type where P ol Att is the attribute specified by the two rules, Rule Ef f their Effects 1 , and sim type is a 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 example are the following:
• Converge. Two rules “Converge” if the sets of values with respect to which their conditions hold are equal.
• The rules similarity computed for Bill and Jane poliP ermit , Current-T imeDeny cies are E-mailConverge Shuf f le
• Diverge. Two rules “Diverge” if the set of values with respect to which their conditions hold do not intersect.
1 For the sake of readability, at this time we restrict the problem by assuming the two policies do not contains rules defined with the same policy attribute but with conflicting Effects.
• Restrict and Extend. A rule “Restricts” (“Extends”) another rule if the set of values with respect to which
222
• The rules similarity computed for Bill and John poliP ermit cies are E-mailExtend , Current-T imeDeny Restrict , P ermit Af f iliationExtend
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 are satisfied, but also that at least one applicable rule is “Permit”. In this context, the policy similarity is computed as follows:
STEP2: Group rules similarity based on rule Effects and apply transformation functions The next step in the process of computing the policy similarity is to group rule similarities based on their Effects and then to apply some transformation functions 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 the Effect of which is “Permit”. From this step on, the XACML rules are not used any longer; only the rule similarities 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 Rule Ef f therefore denoted by Rsim type . The transformation functions applies to the rules similarity are as follows:
Definition 3. Let pm and pn be two policies 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 , RjP ermit } = j • {RConverge Deny P ermit • {RDiverge , Rj(j =Diverge) } = Shuf f le P ermit • {RiDeny , RDiverge } = Diverge Deny P ermit , Rj(j • {Ri(i =diverge) } = Shuf f le =diverge)
Definition 1. Let i ∈{Converge, Diverge, Restrict, Extend, Shuffle} be a similarity value and m ∈ {P ermit, Deny} be a set of rule Effects. The following rule similarity transformation functions apply:
Deny P ermit • {RRestrict , Rj(j∈[Converge,Extend]) } = Extend Deny P ermit • {RRestrict , RRestrict } = Shuf f le
• {Rim , Rim } = Rim
Deny P ermit , Rj(j∈[Converge,Restrict]) } = Restrict • {RExtend
m m m • {RConverge , Ri(i ={Diverge}) } = Ri m m m • {RDiverge , Ri(i ={Diverge}) } = RShuf f le
•
m m {RExtend , RRestrict )
=
Deny P ermit • {RExtend , RExtend } = Shuf f le
✷
m RShuf f le
m m m • {RShuf f le , Ri } = RShuf f le
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:
✷
The transformation functions take as input pairs of rule similarity values and return a single rule similarity value which is the combination of the input values. The sequence of transformation functions used is not important, given that the order according to which the rules appear in the policy is not relevant. Example 3. The application of the transformation functions to the rule similarities computed in Example 2 generates the following rule similarity values:
Definition 4. Let pm and pn be policies defined using “Permit Override” as rule combination algorithm. Moreover, let i, j ∈{Converge, Diverge, Restrict, Extend, Shuffle} be similarity values. If pm specifies “Permit Override” and pn specifies “Deny Override”, the policy similarity between pm and pn is computed as follows:
• The similarities computed comparing Bill and Jane Deny P ermit policies are RConverge , RShuf f le • The similarities computed comparing Bill and John Deny P ermit policies are RExtend , RRestrict STEP3: Apply rules combination algorithms As a final step, we complete the Policy Similarity process by considering rule combination algorithms specified by the two policies. Three cases are possible: Step 3a. Both policies specify “Permit Override” as rule combination algorithm. This is the most simple case. Given that we assumed a policy to be denied if the AC decision is either “Deny” of “Not Applicable” (because of the least privilege principle), the policy similarity can be computed by considering the similarity of the Permit rules only. Formally:
P ermit • {RConverge,Extend , RiDeny } = Extend P ermit • {RDiverge , RiDeny } = Diverge Deny P ermit } = Shuf f le • {RRestrict,Shuf 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 , RiDeny } = Restrict • {RConverge,Restrict
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 ✷
P ermit • {RDiverge , RiDeny } = Diverge Deny P ermit • {RExtend,Shuf } = Shuf f le f le , Ri
223
✷
Example 4. In our example, the policy similarity computed for the policies specified by Bill and John (the first using “Deny Override” whereas the other use “Permit 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 John will be authorized by Bill whereas the opposite is not true. On the other hand, the similarity between the policies specified by Bill and Jane (both using “Deny Override”) is “Shuffle” because the similarity for the “Permit” rules is “Converge” whereas the similarity for the “Deny” rules is “Shuffle”. Therefore, some requests authorized by Bill are rejected by Jane and vice versa.
PoE Guests Policy Int PoE Owner Preference Policy Int . Preference
Figure 3: Policy Integration Results
5.
POLICY INTEGRATION PREFERENCES
The policy similarity gives important information about which policy is the most restrictive, such as the policy which authorizes the smaller set of requests. However, to complete the policy integration process, such information must be combined with the policy integration preferences of all subjects involved. In a distributed system, instead of assuming all PoEs be managed by a single centralized entity, a more flexible solution is to consider each RO to be also the administrator of the PoE in which policies will be enforced 2 . As briefly introduced in Section 1, in a Service Virtualization model both subjects sharing resources and subjects using such resources might be interested in specifying AC requirements concerning how their policies should be integrated with other policies. As example, in our CDN scenario, a RO might want to specify that its PoE should not be used to evaluate policies of each and every DO storing information in its resources. In this context, the owner of the PoE (PoE owner ) can specify its PoE owner policy integration preferences, which identifies the approach to be used in case its PoE is asked to evaluate policies specified by third parties. The available PoE owner policy integration preferences are the following:
Like the PoE owner also the subject, called PoE guest, the policy of which will be evaluated by a third party PoE, can specify policy integration preferences. As example, in our CDN scenario, a DO might be interested in specifying that no requests authorized by its policies should be denied access to the data. Such preferences, called PoE guest policy integration preferences, are as follows. • 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 the PoE might deny accesses to some of its authorized users. By considering the CDN scenario, this is the case in which the data owner will replicate its information into multiple hosts to be sure that each of its authorized request find at least a node in which to access the data. • 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 granting access to unauthorized requests but it should not deny access to requests authorized by the PoE guest.
• 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 he/she specifies.
• 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.
• Restrict Override. The PoE owner specifies its PoE can evaluate third party policies only if they do not authorize requests which are denied by the policies he/she specifies.
When two policies are integrated, the policy integration preferences of both the PoE guest and PoE owner have to be satisfied. To achieve such goal, the two preferences are combined considering the policy similarity computed in the previous section. Given PoE owner and PoE guest preferences, Figure 3 shows the set of policy similarities which guarantee both requirements to be satisfied. In the figure, the rows represent the PoE owner preferences, whereas the columns represent the PoE guest preferences. Again, the cell represents the set of policy similarities for the policy integration to be applied while maintaining both AC policies and integration preferences set by the two subjects.
• Deny Override. As in XACML, the PoE owner specifies that its PoE can evaluate third party policies. 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 the previous case only non conflicting policies are considered for evaluation. • Permit Override. As in XACML, the PoE owner specifies that its PoE can evaluate third party policies. A context request will be authorized if at least one of the two policies is Permit. 2
Example 5. In our example, assume Bill, the PoE guest, has specified “Restrict Override” as policy integration requirement, whereas Jane, the PoE owner, has specified “Deny”.
Other scenarios will be analyzed as part of future work.
224
constraints of the subjects requesting the resource. For instance, in our CDN scenario, the policy integration process is useful for a DO in order to determine at which ROs to replicate its data. The reported results are also very encouraging because the current version of our approach does not take into consideration possible techniques to organize policies for efficiently evaluating a large number of constraints. In this respect, our previous work [19] demonstrates how it is possible to efficiently evaluate 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.
In this scenario, the policy integration is possible because the policy similarity computed for these two parties is “Extend”. Under our approach the policy combination is thus not superimposed 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 integration preferences of the parties involved and the XACML policy they specify.
6.
PERFORMANCE EVALUATION
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 [18], 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 specification. 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 requirements, 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 (no significant differences have however been noticed when changing the function). The experiments were conducted on a Pentium4 3.2 Ghz, 512 Mb Ram machine. Figure 4 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.
7. RELATED WORK Because 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 [20]. 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 [21, 17, 22] are orthogonal to the problem addressed by our work. Again, solutions proposing semantic models to determine policy equivalence [23, 24] can be used in combination with our policy integration process in case policies are defined using different vocabularies. Among the languages based on XACML to manage authorization in the Web Service domain, an important contribution is represented by the Web Service Policy Constraints Language, WSPL [13, 16, 25]. Such language proposes solutions to specify, verify, and apply constraints. In addition, the language proposes an interesting approach to intersect two policies. The intersection of two policies is a single policy that validates exactly a request set which is the intersection of the sets of requests validated by the two policies. 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 process. 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, in WSPL if the intersection of two rules is “Diverge”, the constraints are incompatible and simply eliminated by the integrated policy. Again, 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 integration among generic business rules (for instance an acceptable value for price or encryption mechanisms), we believe it is an oversimplification for AC policies.
Num Policies
Figure 4: Performance of the policy integration process in the cases of 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 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
8.
CONCLUSION AND FUTURE WORK
In this paper we have addressed the problem of integrating two well-formed XACML policies specified by autonomous parties. This work comprises two main contributions: a pol-
225
[7] D. Kusnetzky and C. W. Olofson, “Oracle 10g: Putting grids to work.” http://www.oracle.com/technology/tech/grid/ collateral/idc oracle10g.pdf, 2004. [8] Synapse, “Virtualization: The transformation of enterprise it. [online],” 2005. [9] M. Baker, K. Kimberly, and M. Sean, “Why traditional storage systems do not help us save stuff forever,” HPL-2005-120. HP Labs 2005 Technical Reports, 2005. [10] “Lockss program web page [online],” http://lockss.stanford.edu/. [11] “Lionshare project [online],” http://lionshare.its.psu.edu/main/. [12] D. Morr, “Lionshare: A federated p2p app,” in Internet2 members meeting, Fall 2004. [13] A. Anderson, “An introduction to the web services policy language,” in IEEE Policy 2004 Workshop, June 2004. [14] M. Lorch, S. Proctor, R. Lepro, D. Kafura, and S. Shah, “First experiences using xacml for access control in distributed systems,” in XMLSEC ’03: Proceedings of the 2003 ACM workshop on XML security. New York, NY, USA: ACM Press, 2003, pp. 25–37. [15] “Enterprise privacy authorization language (epal),” 2003. [16] A. Anderson, “Ws-policyconstraints: A domain-independent web services policy assertion language,” November 2005. [17] “Oasis ebxml collaboration protocol profile and agreement technical committee, collaboration-protocol profile and agreement specification version 2.0, september 2002.” [18] “Sun’s xacml implementation web page [online] http://sunxacml.sourceforge.net/.” [19] P. Mazzoleni, B. Crispo, S. Sivasubramanian, and E. Bertino, “Efficient integration of fine-grained access control in large-scale grid services.” in SCC 2005: IEEE International Conference on Service Computing, July 2005. [20] “http://docs.oasis-open.org/xacml/xacmlrefs.html.” [21] W3C, “W3c workshop on constraints and capabilities for web services,” October 2004. [22] “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.” [23] D. Huang, “Semantic policy-based security framework for business processes,” in 4th Semantic Web and Policy Workshop, November 2005. [24] “W3c web ontology language.” [25] D. Morr, “Wspl: an xacml-based web services policy language,” in Internet2 members meeting, Fall 2004.
icy similarity process and the notion of policy integration preferences. The similarity process is used to identify which policy is the most restrictive, such as the policy which authorizes the smaller set of requests. In addition to rule conditions, the similarity process takes into account XACML rules Effects and XACML rule combination algorithms. A key characteristic of the integration preferences is that it allows all parties to specify the approaches to use when integrating their policies with the policies specified by other parties. According to our solution, the policy integration process is not statically carried out by a central “enterprise administrator”, as in XACML, but it is dynamically carried out based on the requirements of all involved parties. The solution we have developed has been fully implemented and is quite comprehensive. As part of future work, we plan to extend our approach by relaxing the assumptions underlying our current approach. The policy integration process should be generalized in order to integrate multiple policies. Again, along with the policy similarity value, we will extract the policies having common set of authorized requests or having a disjoint set of authorized requests. To understand the need of such information, consider again the CDN scenario presented in Section 1. 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 at several ROs and to make sure that all requests authorized by the DO find at least a RO at which they can access both the data and the processing resources.
9.
ACKNOWLEDGMENT
The work of Elisa Bertino is partially supported by the US National Science Foundation under Grant No. 0430274 and by the sponsors of CERIAS
10. REFERENCES [1] XAMCL and OASIS Security Services Technical Committee, “eXtendible Access Control Markup Language (xacml) committee specification 2.0,” Feb 2005. [2] “U.s. government department of health and human services. health insurance portability and accountability act (hipaa). 1996.” [3] “European union. directive on data privacy,” 1998. [4] A. Anderson, “A comparison of two privacy policy languages: Epal and xacml,” September 2005. [5] HP, “Hp virtualized infrastructure solutions for mysap business suite.” http://h71028.www7.hp.com/enterprise/downloads/HPvirtualSAP Solution-Brief.pdf, 2005. [6] IBM, “Automate and integrate within and across it processes to support the continually changing needs of business processes.” IBM White paper, 2004.
226
APPENDIX The following are the policies used in our example specified using XACML: BILL 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=“Jane-Policy” RuleCombiningAlgId=“Permit-Overrides”> <SubjectAttributeDesignator AttributeId=“E-Mail” DataType =“#String”/> <Apply FunctionId=“function:string-bag”> .gov .edu <Apply FunctionId=“Time-one-and-only”> <SubjectAttributeDesignator AttributeId=“current-Time” DataType =”#Time”/> 08:00 12:00
JANE 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 be authorized to access. < Policy PolicyId=“Jane-Policy” RuleCombiningAlgId=“Permit-Overrides”> <SubjectAttributeDesignator AttributeId=“E-Mail” DataType =“#String”/> <Apply FunctionId=“function:string-bag”> .gov .edu <Apply FunctionId=“Time-one-and-only”> <SubjectAttributeDesignator AttributeId=“current-Time” DataType =”#Time”/> 10:00 14:00
JOHN 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=“John-Policy” RuleCombiningAlgId=“Deny-Overrides”> <Apply FunctionId=“String-one-and-only”> <SubjectAttributeDesignator AttributeId=“E-mail” DataType =“#String”/> .edu <Apply FunctionId=“Time-one-and-only”> <SubjectAttributeDesignator AttributeId=“current-Time” DataType =”#Time”/> 08:00 20:00 <Apply FunctionId=“String-one-and-only”> <SubjectAttributeDesignator AttributeId=“Affiliation” DataType =“#String”/> HP
227
E. Bertino
B. Crispo
CS Department University of Milan, Italy
Cerias and CS Department Purdue University, USA
[email protected]
[email protected]
CS Department Vrije Universiteit, Amsterdam DIT Department University of Trento, Italy
[email protected] S. Sivasubramanian CS Department Vrije Universiteit, Amsterdam
[email protected] ABSTRACT
goal of XACML is to propose a common language through which an enterprise can manage all the elements of its security policies in 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 [2, 3] but today it is virtually impossible to independently manage the configuration of each point of enforcement and have a complete view of the safeguards in effect throughout the enterprise [1, 4]. 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 is denied if at least one of the composing policies is evaluated “Deny”. XACML is a very rich and flexible language; users and security administrators can directly represent in XACML a large variety of AC policies. However, XACML has not been built to manage security in large distributed systems in which virtual enterprises are dynamically built with the collaboration of multiple independent subjects sharing their resources (or services) to provide new (or better) services to customers. This is the case of systems adopting the emerging business model referred to as “Service Virtualization” [5, 6, 7] in which the parties providing the services may be distributed across multiple enterprises and in which the owners of the services might be different from the parties providing the resources (e.g., memory, computing power, bandwidth, etc.) running those services. For example, the SUN grid network allows its customers to use its resources on-demand by providing highly virtualized resources. In a “Service Virtualization” scenario, applications are no longer statically allocated and managed within silos (represented by servers or clusters). Instead they can run on any server in the distributed system that provides its computing and storage resources [5, 8].
XACML is the OASIS standard language for the specification of authorization and entitlement policies. However, while XACML well addresses security requirements of a single enterprise (even if large and composed by multiple departments), it does not address the requirements of virtual enterprises built through collaboration of several autonomous subjects sharing their resources. In this paper we highlight such limitations and we propose an XACML extension, the policy integration algorithm, to address them. In the paper we also discuss in which respect the process of comparing two XACML policies differs from the process used to compare other business rules.
Categories and Subject Descriptors D.4.6 [Security and Protection]: Authorization
General Terms Security, Language, Standardization
Keywords XACML, Security policies integration, Distributed Systems, Web Services,Content Distributed Networks
1.
INTRODUCTION
XACML (Extensible Access Control Markup Language) is the OASIS standard language for expressing access control (AC) policies [1] in large enterprise systems, that often have many policy elements and points of enforcement (PoE). The
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SACMAT’06, June 7–9, 2006, Lake Tahoe, California, USA. Copyright 2006 ACM 1-59593-354-9/06/0006 ...$5.00.
219
In such scenarios, all parties in the system can independently specify fine-grained authorization constraints to protect their resources. Under these conditions, it is however unclear which entity should be entitled to choose the approach to be used for integrating the policies specified by the various parties. The problem of conflicting policies can occur even more frequently than the cases of single enterprises composed by multiple sectors. Consider, as example of “Service Virtualization” system, a Content Distribution Network (CDN) built on P2P network in which parties can replicate their data in storage made available by third party resource providers. Real systems adopting this model are for instance Lockss [9, 10] and LionShare [11, 12]. In such scenario, both the owner of the data and the owner of the storage can specify their XACML policies. The former can place constraints on where its data can be placed and which subjects can read it, while the latter can place constraints on which subjects can upload and download information from its resources. To take authorization decisions upon subjects requesting access to some data available the network, 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. Despite some previous work has applied XACML to distributed environments [13, 14, 15], XACML policy combination algorithms are not enough to integrate policies specified by parties which are autonomous and which might not be willing to share or lease the ownership of their resources. This because XACML assumes all PoEs be available to enforce any policy (or combination of policies) set by any party in the enterprise and there always exists an “enterprise administator” who can solve conflicts. However, this is not the case of scenarios in which PoEs are administered by autonomous parties. For instance, in the CDN scenario, a RO might not be willing to evaluate policies for each and every DO storing some data in its resources. Again, approaches [16, 17] for the integration of AC policies either consider non standard languages or make assumptions which oversimplify XACML. In this paper we propose an XACML policy integration process specifically developed for distributed systems in which the involved parties can autonomously specify their AC policies. Applications of our solution can be found in a large variety of domains, such as Web Service technology, organizational data sharing, CDN systems, and Grid. The solution we propose has two key components: a policy similarity process and a policy integration preferences. The policy similarity process is the process through which policies are compared with respect of the sets of requests they authorize. Given two policies, the policy similarity determines which policy is the most restrictive. On the other hand, the policy integration preferences is an XACML extension by which a party can specify the approach to be taken if their policies have to be integrated with others. The rest of the paper is organized as follows: Section 2 gives a brief overview of the main components of XACML. Section 3 presents a motivating example to demonstrate the limitations of XACML when applied to distributed systems. The following two sections are the core of the paper: Section 4 proposes the policy similarity process, whereas Section 5 presents the policy integration preferences. Section 6
Figure 1: XACML rule and policy combination algorithms
presents an overview of the implementation of our approach. Section 7 compares our solution with the state of the arts and Section 8 concludes the paper and outlines future work.
2. XACML POLICY LANGUAGE The formalism for specifying AC policies in XACML 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 predefine a list of attributes; instead it specifies a list of (normative) datatypes that subjects and/or communities can use to create the attributes which are valid for a given system. String, Time, Boolean, Double, and AnyURI are some examples of valid data-types. Similarly, functions are possible operators which can be used for normative data-types. String-Equal, Greater-Then, Date-Equal, String-Is-In, and AnyURI-OneAnd-Only are examples of valid functions. Rule. A rule is the basic element of a policy. It identifies a complete and atomic authorization constraint which exists in isolation with respect to the policy in which it has been created. A rule is composed by a Target, to identify the set of requests the rule is intended to restrict, an Effect, which is either “Permit” or “Deny”, and a set of Conditions which represent 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 rule combination algorithm specifies the approach to be adopted to compute the decision result of a policy containing rules with conflicting Effects. The XACML normative rule combination algorithms 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 decision has to consider AC requirements of 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 the rules of a given policy, that is, the ones in Figure 1.
220
An XACML policy can also include Obligations, which represent functions to be executed 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 DO). 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 is based on three main entities: 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 requests from the native format to the XACML canonical form and to convert the authorization decision from XACML to the native format supported by a PEP. In a nutshell, an access request is evaluated as follows. The requester sends a request to a PEP which in turn contacts the context handler in charge of converting the attributes of the subject, resource, action, and environment describing 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 applicable to the request. A rule is applicable to a request if the information in the request context satisfies both the rule target and the rule condition predicates. If these predicates are not verified, the rule is “Not applicable” and its Effect ignored. A policy is “Not applicable” if no policy rule applies to the request. The rule combination algorithm is used to resolve conflicts among applicable rules with different Effects, whereas the policy combination algorithm is used to resolve conflicts among applicable policies. 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 authorization decision concerning the request.
3.
In addition, assume Bill to be a DO hosting his data into storage owned by third party subjects. The AC policy Bill wishes to enforce for users requiring access to his data is the following: BILL 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 Jane and Bill adopt “Deny Override” as rule combination algorithm whereas John adopts “Permit Override” rule combination algorithm. In this simple scenario, Bill can either store his data in John or in Jane storage. However, it is not clear which policy combination algorithm, among the ones defined by XACML, has to be used to combine DO and RO policies and which party is entitled to decide it. “Permit Override” cannot be used because the resource owner might not accept its storage be accessed by unauthorized subjects. Also, “Permit Override” will create situations in which a subject is given access to the data, thus bypassing the DO policy, only because the subject is authorized to access the storage hosting the information. On the other hand, “Deny Override” cannot be used as the RO might not be willing to assume the extra task of evaluating all the policies of all the DOs storing information into its storage. At the same time, the DO might not accept that some of its authorized users will be denied access to its data only because hosted by a RO the policy of which deny the access to the resource. Finally, using “Deny Override” to combine RO and DO policies might lead to a scenario in which no user will be authorized to access the requested resources. For instance, suppose that a DO, the policy of which authorize access to the data only to users with an email in the “.edu” namespace, stores its data in a third party RO. Moreover, suppose the policy of the RO hosting such information gives access only to subjects the email of which are in the “.com” namespace. In such case, the “Deny Override” combination algorithm results in denying access to all requests wishing to access DO information. In general, in scenarios in which policies are specified by multiple autonomous parties, all interested in controlling their resources (either physical or logical), it is not clear which party is entitled to set the policy combination algorithm. In a distributed system the underlying relationship among the parties is peer-to-peer rather than hierarchical. In other words, while it is reasonable to think that there exists a unique policy administrator which decides upon integrating multiple rules, this is not always the case when dealing with policies specified by autonomous subjects. 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 involved parties. In our solution, we address such a problem by extending the XACML language with a set of policy integration preferences. Those preferences can be specified by all subjects involved in the system and aim at collecting users requirements with respect of the approach to be followed in case their policies have to be integrated with policies of other parties. The decision about policy integration is therefore dynamically computed by taking into account the requirements of all involved subjects.
MOTIVATING EXAMPLE
The policy integration method we propose in this paper can be applied to several applications ranging from Web Services to Grid systems. However, in the following we motivate our work by presenting a very simple scenario related to the CDN introduced in Section 1. In this scenario, let us assume Jane and John be two ROs making available their resources to host third party information. Consider the following be the policies John and Jane want to apply to protect access on their resources: JANE 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. JOHN 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.
221
4.
POLICY SIMILARITY
Before introducing the policy integration preferences, we need to analyze the behavior of the policies to be integrated with respect of the requests they authorize. In other words, we need to determine whether there are requests authorized by a policy and denied by another. In this section, we describe the process for computing such information which we refer to as Policy Similarity. 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 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 that have 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 a policy. In such context, it is important to recall that the “Not Applicable” rules, that is, the rules the conditions of which are not verified by the context request, do not take part in the authorization decision. For example, a rule denying access from 8a.m. to 8p.m. does not give any indication, in terms of authorization, about 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 that the least privilege principle applies, that is, a request is denied if the evaluation of the XACML policy for 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 each composed of multiple rules, 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 their data types and functions extracts and compares the sets of values for which their expressions hold. In our work, we simply adopt syntactical analysis to identify policies specifying the same attribute. The use of more complex rule comparison methods using patterns or semantic analysis are outside the scope of this paper; they could however be easily integrated in our solution. As graphically illustrated in Figure 2, we distinguish five types of rules similarity:
Figure 2: Policy Rule similarity type
its condition holds is a subset (superset) of 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 a subset of the other. Example 1. In our CDN example, the rule similarity computed between Bill and John policies are the following: the Bill e-mail rule “Extends” John email rule, whereas Bill rule on Time “Restricts” time rule set by John. A different approach is taken for rules the policy attributes of which are specified in one of the two policies only. In this case, the above strategy cannot be applied because there are no two sets of values that can be compared. In such case, the rule similarity is computed considering which one of the two policies contains the extra rule. Therefore, when computing the similarity between policies pi and pj , if pi has a policy 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”. In the rest of the paper we refer to the rule similarity Ef f using the notation P ol AttRule sim type where P ol Att is the attribute specified by the two rules, Rule Ef f their Effects 1 , and sim type is a 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 example are the following:
• Converge. Two rules “Converge” if the sets of values with respect to which their conditions hold are equal.
• The rules similarity computed for Bill and Jane poliP ermit , Current-T imeDeny cies are E-mailConverge Shuf f le
• Diverge. Two rules “Diverge” if the set of values with respect to which their conditions hold do not intersect.
1 For the sake of readability, at this time we restrict the problem by assuming the two policies do not contains rules defined with the same policy attribute but with conflicting Effects.
• Restrict and Extend. A rule “Restricts” (“Extends”) another rule if the set of values with respect to which
222
• The rules similarity computed for Bill and John poliP ermit cies are E-mailExtend , Current-T imeDeny Restrict , P ermit Af f iliationExtend
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 are satisfied, but also that at least one applicable rule is “Permit”. In this context, the policy similarity is computed as follows:
STEP2: Group rules similarity based on rule Effects and apply transformation functions The next step in the process of computing the policy similarity is to group rule similarities based on their Effects and then to apply some transformation functions 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 the Effect of which is “Permit”. From this step on, the XACML rules are not used any longer; only the rule similarities 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 Rule Ef f therefore denoted by Rsim type . The transformation functions applies to the rules similarity are as follows:
Definition 3. Let pm and pn be two policies 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 , RjP ermit } = j • {RConverge Deny P ermit • {RDiverge , Rj(j =Diverge) } = Shuf f le P ermit • {RiDeny , RDiverge } = Diverge Deny P ermit , Rj(j • {Ri(i =diverge) } = Shuf f le =diverge)
Definition 1. Let i ∈{Converge, Diverge, Restrict, Extend, Shuffle} be a similarity value and m ∈ {P ermit, Deny} be a set of rule Effects. The following rule similarity transformation functions apply:
Deny P ermit • {RRestrict , Rj(j∈[Converge,Extend]) } = Extend Deny P ermit • {RRestrict , RRestrict } = Shuf f le
• {Rim , Rim } = Rim
Deny P ermit , Rj(j∈[Converge,Restrict]) } = Restrict • {RExtend
m m m • {RConverge , Ri(i ={Diverge}) } = Ri m m m • {RDiverge , Ri(i ={Diverge}) } = RShuf f le
•
m m {RExtend , RRestrict )
=
Deny P ermit • {RExtend , RExtend } = Shuf f le
✷
m RShuf f le
m m m • {RShuf f le , Ri } = RShuf f le
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:
✷
The transformation functions take as input pairs of rule similarity values and return a single rule similarity value which is the combination of the input values. The sequence of transformation functions used is not important, given that the order according to which the rules appear in the policy is not relevant. Example 3. The application of the transformation functions to the rule similarities computed in Example 2 generates the following rule similarity values:
Definition 4. Let pm and pn be policies defined using “Permit Override” as rule combination algorithm. Moreover, let i, j ∈{Converge, Diverge, Restrict, Extend, Shuffle} be similarity values. If pm specifies “Permit Override” and pn specifies “Deny Override”, the policy similarity between pm and pn is computed as follows:
• The similarities computed comparing Bill and Jane Deny P ermit policies are RConverge , RShuf f le • The similarities computed comparing Bill and John Deny P ermit policies are RExtend , RRestrict STEP3: Apply rules combination algorithms As a final step, we complete the Policy Similarity process by considering rule combination algorithms specified by the two policies. Three cases are possible: Step 3a. Both policies specify “Permit Override” as rule combination algorithm. This is the most simple case. Given that we assumed a policy to be denied if the AC decision is either “Deny” of “Not Applicable” (because of the least privilege principle), the policy similarity can be computed by considering the similarity of the Permit rules only. Formally:
P ermit • {RConverge,Extend , RiDeny } = Extend P ermit • {RDiverge , RiDeny } = Diverge Deny P ermit } = Shuf f le • {RRestrict,Shuf 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 , RiDeny } = Restrict • {RConverge,Restrict
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 ✷
P ermit • {RDiverge , RiDeny } = Diverge Deny P ermit • {RExtend,Shuf } = Shuf f le f le , Ri
223
✷
Example 4. In our example, the policy similarity computed for the policies specified by Bill and John (the first using “Deny Override” whereas the other use “Permit 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 John will be authorized by Bill whereas the opposite is not true. On the other hand, the similarity between the policies specified by Bill and Jane (both using “Deny Override”) is “Shuffle” because the similarity for the “Permit” rules is “Converge” whereas the similarity for the “Deny” rules is “Shuffle”. Therefore, some requests authorized by Bill are rejected by Jane and vice versa.
PoE Guests Policy Int PoE Owner Preference Policy Int . Preference
Figure 3: Policy Integration Results
5.
POLICY INTEGRATION PREFERENCES
The policy similarity gives important information about which policy is the most restrictive, such as the policy which authorizes the smaller set of requests. However, to complete the policy integration process, such information must be combined with the policy integration preferences of all subjects involved. In a distributed system, instead of assuming all PoEs be managed by a single centralized entity, a more flexible solution is to consider each RO to be also the administrator of the PoE in which policies will be enforced 2 . As briefly introduced in Section 1, in a Service Virtualization model both subjects sharing resources and subjects using such resources might be interested in specifying AC requirements concerning how their policies should be integrated with other policies. As example, in our CDN scenario, a RO might want to specify that its PoE should not be used to evaluate policies of each and every DO storing information in its resources. In this context, the owner of the PoE (PoE owner ) can specify its PoE owner policy integration preferences, which identifies the approach to be used in case its PoE is asked to evaluate policies specified by third parties. The available PoE owner policy integration preferences are the following:
Like the PoE owner also the subject, called PoE guest, the policy of which will be evaluated by a third party PoE, can specify policy integration preferences. As example, in our CDN scenario, a DO might be interested in specifying that no requests authorized by its policies should be denied access to the data. Such preferences, called PoE guest policy integration preferences, are as follows. • 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 the PoE might deny accesses to some of its authorized users. By considering the CDN scenario, this is the case in which the data owner will replicate its information into multiple hosts to be sure that each of its authorized request find at least a node in which to access the data. • 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 granting access to unauthorized requests but it should not deny access to requests authorized by the PoE guest.
• 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 he/she specifies.
• 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.
• Restrict Override. The PoE owner specifies its PoE can evaluate third party policies only if they do not authorize requests which are denied by the policies he/she specifies.
When two policies are integrated, the policy integration preferences of both the PoE guest and PoE owner have to be satisfied. To achieve such goal, the two preferences are combined considering the policy similarity computed in the previous section. Given PoE owner and PoE guest preferences, Figure 3 shows the set of policy similarities which guarantee both requirements to be satisfied. In the figure, the rows represent the PoE owner preferences, whereas the columns represent the PoE guest preferences. Again, the cell represents the set of policy similarities for the policy integration to be applied while maintaining both AC policies and integration preferences set by the two subjects.
• Deny Override. As in XACML, the PoE owner specifies that its PoE can evaluate third party policies. 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 the previous case only non conflicting policies are considered for evaluation. • Permit Override. As in XACML, the PoE owner specifies that its PoE can evaluate third party policies. A context request will be authorized if at least one of the two policies is Permit. 2
Example 5. In our example, assume Bill, the PoE guest, has specified “Restrict Override” as policy integration requirement, whereas Jane, the PoE owner, has specified “Deny”.
Other scenarios will be analyzed as part of future work.
224
constraints of the subjects requesting the resource. For instance, in our CDN scenario, the policy integration process is useful for a DO in order to determine at which ROs to replicate its data. The reported results are also very encouraging because the current version of our approach does not take into consideration possible techniques to organize policies for efficiently evaluating a large number of constraints. In this respect, our previous work [19] demonstrates how it is possible to efficiently evaluate 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.
In this scenario, the policy integration is possible because the policy similarity computed for these two parties is “Extend”. Under our approach the policy combination is thus not superimposed 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 integration preferences of the parties involved and the XACML policy they specify.
6.
PERFORMANCE EVALUATION
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 [18], 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 specification. 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 requirements, 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 (no significant differences have however been noticed when changing the function). The experiments were conducted on a Pentium4 3.2 Ghz, 512 Mb Ram machine. Figure 4 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.
7. RELATED WORK Because 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 [20]. 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 [21, 17, 22] are orthogonal to the problem addressed by our work. Again, solutions proposing semantic models to determine policy equivalence [23, 24] can be used in combination with our policy integration process in case policies are defined using different vocabularies. Among the languages based on XACML to manage authorization in the Web Service domain, an important contribution is represented by the Web Service Policy Constraints Language, WSPL [13, 16, 25]. Such language proposes solutions to specify, verify, and apply constraints. In addition, the language proposes an interesting approach to intersect two policies. The intersection of two policies is a single policy that validates exactly a request set which is the intersection of the sets of requests validated by the two policies. 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 process. 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, in WSPL if the intersection of two rules is “Diverge”, the constraints are incompatible and simply eliminated by the integrated policy. Again, 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 integration among generic business rules (for instance an acceptable value for price or encryption mechanisms), we believe it is an oversimplification for AC policies.
Num Policies
Figure 4: Performance of the policy integration process in the cases of 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 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
8.
CONCLUSION AND FUTURE WORK
In this paper we have addressed the problem of integrating two well-formed XACML policies specified by autonomous parties. This work comprises two main contributions: a pol-
225
[7] D. Kusnetzky and C. W. Olofson, “Oracle 10g: Putting grids to work.” http://www.oracle.com/technology/tech/grid/ collateral/idc oracle10g.pdf, 2004. [8] Synapse, “Virtualization: The transformation of enterprise it. [online],” 2005. [9] M. Baker, K. Kimberly, and M. Sean, “Why traditional storage systems do not help us save stuff forever,” HPL-2005-120. HP Labs 2005 Technical Reports, 2005. [10] “Lockss program web page [online],” http://lockss.stanford.edu/. [11] “Lionshare project [online],” http://lionshare.its.psu.edu/main/. [12] D. Morr, “Lionshare: A federated p2p app,” in Internet2 members meeting, Fall 2004. [13] A. Anderson, “An introduction to the web services policy language,” in IEEE Policy 2004 Workshop, June 2004. [14] M. Lorch, S. Proctor, R. Lepro, D. Kafura, and S. Shah, “First experiences using xacml for access control in distributed systems,” in XMLSEC ’03: Proceedings of the 2003 ACM workshop on XML security. New York, NY, USA: ACM Press, 2003, pp. 25–37. [15] “Enterprise privacy authorization language (epal),” 2003. [16] A. Anderson, “Ws-policyconstraints: A domain-independent web services policy assertion language,” November 2005. [17] “Oasis ebxml collaboration protocol profile and agreement technical committee, collaboration-protocol profile and agreement specification version 2.0, september 2002.” [18] “Sun’s xacml implementation web page [online] http://sunxacml.sourceforge.net/.” [19] P. Mazzoleni, B. Crispo, S. Sivasubramanian, and E. Bertino, “Efficient integration of fine-grained access control in large-scale grid services.” in SCC 2005: IEEE International Conference on Service Computing, July 2005. [20] “http://docs.oasis-open.org/xacml/xacmlrefs.html.” [21] W3C, “W3c workshop on constraints and capabilities for web services,” October 2004. [22] “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.” [23] D. Huang, “Semantic policy-based security framework for business processes,” in 4th Semantic Web and Policy Workshop, November 2005. [24] “W3c web ontology language.” [25] D. Morr, “Wspl: an xacml-based web services policy language,” in Internet2 members meeting, Fall 2004.
icy similarity process and the notion of policy integration preferences. The similarity process is used to identify which policy is the most restrictive, such as the policy which authorizes the smaller set of requests. In addition to rule conditions, the similarity process takes into account XACML rules Effects and XACML rule combination algorithms. A key characteristic of the integration preferences is that it allows all parties to specify the approaches to use when integrating their policies with the policies specified by other parties. According to our solution, the policy integration process is not statically carried out by a central “enterprise administrator”, as in XACML, but it is dynamically carried out based on the requirements of all involved parties. The solution we have developed has been fully implemented and is quite comprehensive. As part of future work, we plan to extend our approach by relaxing the assumptions underlying our current approach. The policy integration process should be generalized in order to integrate multiple policies. Again, along with the policy similarity value, we will extract the policies having common set of authorized requests or having a disjoint set of authorized requests. To understand the need of such information, consider again the CDN scenario presented in Section 1. 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 at several ROs and to make sure that all requests authorized by the DO find at least a RO at which they can access both the data and the processing resources.
9.
ACKNOWLEDGMENT
The work of Elisa Bertino is partially supported by the US National Science Foundation under Grant No. 0430274 and by the sponsors of CERIAS
10. REFERENCES [1] XAMCL and OASIS Security Services Technical Committee, “eXtendible Access Control Markup Language (xacml) committee specification 2.0,” Feb 2005. [2] “U.s. government department of health and human services. health insurance portability and accountability act (hipaa). 1996.” [3] “European union. directive on data privacy,” 1998. [4] A. Anderson, “A comparison of two privacy policy languages: Epal and xacml,” September 2005. [5] HP, “Hp virtualized infrastructure solutions for mysap business suite.” http://h71028.www7.hp.com/enterprise/downloads/HPvirtualSAP Solution-Brief.pdf, 2005. [6] IBM, “Automate and integrate within and across it processes to support the continually changing needs of business processes.” IBM White paper, 2004.
226
APPENDIX The following are the policies used in our example specified using XACML: BILL 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=“Jane-Policy” RuleCombiningAlgId=“Permit-Overrides”> <SubjectAttributeDesignator AttributeId=“E-Mail” DataType =“#String”/> <Apply FunctionId=“function:string-bag”> .gov .edu <Apply FunctionId=“Time-one-and-only”> <SubjectAttributeDesignator AttributeId=“current-Time” DataType =”#Time”/> 08:00 12:00
JANE 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 be authorized to access. < Policy PolicyId=“Jane-Policy” RuleCombiningAlgId=“Permit-Overrides”> <SubjectAttributeDesignator AttributeId=“E-Mail” DataType =“#String”/> <Apply FunctionId=“function:string-bag”> .gov .edu <Apply FunctionId=“Time-one-and-only”> <SubjectAttributeDesignator AttributeId=“current-Time” DataType =”#Time”/> 10:00 14:00
JOHN 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=“John-Policy” RuleCombiningAlgId=“Deny-Overrides”> <Apply FunctionId=“String-one-and-only”> <SubjectAttributeDesignator AttributeId=“E-mail” DataType =“#String”/> .edu <Apply FunctionId=“Time-one-and-only”> <SubjectAttributeDesignator AttributeId=“current-Time” DataType =”#Time”/> 08:00 20:00 <Apply FunctionId=“String-one-and-only”> <SubjectAttributeDesignator AttributeId=“Affiliation” DataType =“#String”/> HP
227
