Designing Fast and Scalable XACML Policy Evaluation Engines

More documents

Recommendations

Info

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 4any application. The idea is similar to logical expressionnormalization. Policy normalization has two major benefits.First, we will choose a normal form that has a simple logicalstructure. This simplifies the task of developing efficient policyevaluation algorithms. Second, policy normalization enablesthe reuse of policy evaluation algorithms. That is, to apply ourpolicy evaluation algorithms to a policy from any language,we simply convert that policy to its corresponding normalizedform. The policy normal form that we propose is a sequence ofrange rules, which we call the sequential range rule representation.The format of a range rule is〈predicate〉 → 〈decision〉.A request has z attributes F 1 ,···,F z , where the domain ofeach attribute F i , denoted D(F i ), is a range of integers. The〈predicate〉 defines a set of requests over the attributes F 1through F z . The 〈decision〉 defines the action (permit ordeny) to take upon the requests that satisfy the predicate. Thepredicate of a rule is specified as F 1 ∈ S 1 ∧ ··· ∧ F z ∈ S zwhere each S i is a range of integers and S i is a subset of thedomain of F i . The semantics of a sequence of rules followsFirst-Applicable (i.e., first-match); that is, the decision for arequest is the decision of the first rule that the request matches.To serve as a security policy, a sequence of range rules mustbe complete (i.e., for any valid request there is at least onematching rule). Fig. 3(b) shows a sequence of range rules.To further facilitate the development of fast policy evaluationalgorithms, we propose to convert our normalized policiesto a canonical representation. Our canonical representation ofa policy is a reduced Policy Decision Diagram (similar toa firewall decision diagrams [13], [14]). A Policy DecisionDiagram (PDD) with a decision set DS and over attributesF 1 ,···,F z is an acyclic and directed graph that has thefollowing five properties: (1) There is exactly one node that hasno incoming edges. This node is called the root. The nodesthat have no outgoing edges are called terminal nodes. (2)Each node v has a label, denoted F(v). If v is a nonterminalnode, then F(v) ∈ {F 1 ,···,F z }. If v is a terminal node,then F(v) ∈ DS. (3) Each edge e:u → v is labeled witha nonempty set of integers, denoted I(e), where I(e) is asubset of the domain of u’s label (i.e., I(e) ⊆ D(F(u))). (4)A directed path from the root to a terminal node is called adecision path. No two nodes on a decision path have the samelabel. (5) The set of all outgoing edges of a node v, denotedE(v), satisfies the following two conditions: (a) consistency:I(e)∩I(e ′ ) = ∅ for any two distinct edgese ande ′ inE(v); (b)completeness: ⋃ e∈E(v)I(e)=D(F(v)). Fig. 9 shows a PDD.The first step in policy normalization is numericalization.The process of XACML policy numericalization is to convertthe strings in an XACML policy into integer values. Policy numericalizationenables our XACML policy evaluation engineto use efficient integer comparison, instead of inefficient stringmatching, in processing XACML requests. The process ofXACML policy normalization is to convert an XACML policywith a hierarchical structure into an equivalent policy with aflat structure and at the same time to convert an XACMLpolicy with four rule/policy combining algorithms into anequivalent policy with only one rule combining algorithm,which is First-Applicable. Policy normalization enables ourXACML policy evaluation engine to process an XACMLrequest without comparing the request against all the rulesin an XACML policy.There are many technical challenges in XACML policynormalization and canonical representation: non-integer values,recursive specification, scattered predicates, multi-valuedrules, multi-valued requests, all-match to first-match conversion,unifying rule/policy combining algorithms, complexXACML functions, and indeterminate evaluation. Next, foreach challenge, we formulate the problem, present our solution,and give an example. Fig. 2 shows the notations used inthe paper.S Subject R ResourceA Action p decision permitd decision deny na decision NotApplicableX an XACML policy or X ′ normalization result of Xpolicy set R i a rule in an XACML policyA X’s combining algorithm F i an attributer i a range rule v a node in a PDDD(F i) domain of attribute F i F(v) label of node ve an edge in a PDD e.t the node that edge eI(e) label of edge e points toP a decision path in a PDD V a node in a structure treeQ a request O(Q) the set of all XACMLF(Q) the first original XACML rules that Q matchesrules that Q matches OB an origin blockFig. 2: Summary of notationsA. XACML Policy NumericalizationProblem: In sequential range rules, the constraints on eachattribute are specified using integers. However, in XACMLrules, the constraints on each attribute are specified usingASCII strings.Solution: For each attribute (typically subject, resource, oraction), we first map each distinct value of the attribute thatappears in an XACML policy to a distinct integer, and all themapped integers of that attribute should form a range. Afternumericalizing every rule in an XACML policy, we add ruleR −1 : true → NotApplicable as the last rule to make thesequence of range rules complete. We denote this last rule asR −1 for distinguishing it from the original XACML rules.Example: Taking the policy in Fig. 1 as an example, wemap each distinct attribute value to a distinct integer as shownin Fig. 3(a). The converted rules after mapping are shown inFig. 3(b). Note that d denotes deny, p denotes permit, and nadenotes NotApplicable.Subject Resource ActionStudent: 0Secretary: 1Professor: 2Lecturer: 3Grades: 0Records: 1Change: 0Read: 1R 1 : S ∈ [0,1] ∧ R ∈ [0,0] ∧ A ∈ [0,0] → dR 2 : S ∈ [1,3] ∧ R ∈ [0,1] ∧ A ∈ [0,1] → pR 3 : S ∈ [0,0] ∧ R ∈ [1,1] ∧ A ∈ [0,1] → pR −1 : S ∈ [0,3] ∧ R ∈ [0,1] ∧ A ∈ [0,1] → naFig. 3: Numericalization table for the XACML policy in Fig. 1 andthe numericalized rulesB. Recursive SpecificationProblem: A policy of the sequential range rule representationhas a flat structure as a sequence of rules. However,an XACML policy is specified recursively and therefore hasa hierarchical structure. In XACML, a policy set contains asequence of policies or policy sets, which may further containpolicies or policy sets.Solution: We parse and model an XACML policy as atree, where each terminal node represents an individual rule,each nonterminal node whose children are all terminal nodesrepresents a policy, and each nonterminal node whose childrenare all nonterminal nodes represents a policy set. Because thistree represents the structure of the XACML policy, we call it(a)(b)
IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 5the structure tree of the policy. At each nonterminal node, westore the range of the sequence numbers of the rules that areincluded in the policy or the policy set corresponding to thenonterminal node. We also store the combining algorithm andthe target of the corresponding policy or policy set.Example: Fig. 4(a) shows an XACML policy with a hierarchicalstructure (with details elided), which has three layers.The first layer contains a policy and a policy set, and the policycombining algorithm is First-Applicable. In the second layer,the aforementioned policy contains two rules R 1 and R 2 , andthe rule combining algorithm is Deny-Overrides; the policyset contains two policies, and the policy combining algorithmis Permit-Overrides. The third layer contains two policies: onecontains two rules R 3 and R 4 with Deny-Overrides as itscombining algorithm; and the other contains two rules R 5 andR 6 with Only-One-Applicable as its combining algorithm.First-ApplicableDeny-OverridesV 2[3,6]V 4R 1permitR 2 [1,2]denyTarget t Target tPermit-OverridesDeny-OverridesR denyDeny-Overrides2Permit-Overrides33[3,4][5,6]R permit4 Deny-Overrides Only-One-ApplicableOnly-One-ApplicableTarget t 4 Target t 5R5 permitR 6denyR 3 R 4 R 5 R 6(a)(b)Fig. 4: An example XACML policy and its structure treeFig. 4(b) shows the structure tree of the three-layeredXACML policy in Fig. 4(a). In the root, range [1,6] indicatesthat the XACML policy consists of rules R 1 to R 6 , First-Applicable is the combining algorithm of the XACML policy,and t 1 is the target of the policy set.[1,6]First-ApplicableTarget t 1V 1V 3V 5C. Scattered PredicatesProblem: In the sequential range rule representation,whether a request matches a rule is determined solely bywhether the request satisfies the predicate of the rule. However,in XACML policies, checking whether a request matches arule requires checking whether the request satisfies a series ofpredicates. This is because a rule in an XACML policy maybe encapsulated in a policy, the policy may be further enclosedin multiple policy sets, and each policy or policy set has itsown applicability constraints (i.e., targets).Solution: In the structure tree of an XACML policy, eachnode may have a target that specifies some constraints on thesubject, resource, and action of requests. A request matches arule if and only if the request satisfies all the targets along thepath from the root to the terminal node that corresponds to therule. For each ruleR i , lett 1 ,···,t k denote all the targets alongthe path from the root to the terminal node that correspondsto R i and c denote the condition of R i , we replace the targetof R i by t 1 ∧···∧t k ∧c. Note that c is true if rule R i doesnot have a condition.Example: In normalizing the policy in Fig. 4(b), we replacethe target of R 6 by t 1 ∧t 3 ∧t 5 ∧t R6 ∧c R6 , where t R6 is thetarget of R 6 and c R6 is the condition of R 6 .D. Multi-valued RulesProblem: In the sequential range rule representation, rulesare specified under the assumption that each attribute in arequest has a singular value. However, in XACML policies,a rule may specify that some attributes must be multi-valued.For example, the constraints on the subject attribute may be“a person who is both a professor and a student”.Solution: We solve this problem by modeling the combinationsof distinct values that appear in multi-valued rules in anXACML policy as a new distinct value.Example: Suppose a rule requires the subject to be “a personwho is both a professor and a student”. We add one moredistinct value for the subject, that is, “professor&student”.E. Multi-valued RequestsProblem: In the sequential range rule representation, eachattribute in a request has a singular value. However, an attributein an XACML request may have multiple values. For example,the subject in an XACML request may be “a person who isboth a professor and a student”.Solution: We solve this problem by breaking a multi-valuedrequest into multiple single-valued requests. For example, if arequest is “a person, who is both a professor and a student,wants to assign grades”, we break it into two single-valuedrequests: “a professor wants to assign grades” and “a studentwants to assign grades”. Note that if we have a distinct value“professor&student” due to some multi-valued rules, we addone more single-valued request: “a professor&student wantsto assign grades”.To compute the final decision for the original multi-valuedrequest, for each decomposed single-valued request, we findall the original XACML rules that this single-valued requestmatches. Let Q be a multi-valued request and Q 1 ,···,Q k bethe resulting single-valued requests decomposed from Q. Foreach Q i , we use O(Q i ) to denote the set of all the originalXACML rules that Q i matches. Thus, ∪ k i=1 O(Q i) is the setof all the original XACML rules that the multi-valued requestQ matches. The discussion on the algorithm for finding all theoriginal XACML rules that a single-valued request matches isdeferred to Section IV-F. After we compute ∪ k i=1 O(Q i), weuse the structure tree of the given XACML policy to reachthe final decision for the multi-valued request Q in a bottomupfashion. The pseudocode of the resolution algorithm is inAlgorithm 1.Algorithm 1: ResolveByStructureTree(O,V )Input: (1) A set O of original XACML rules O = {R a1 ,···,R ah },where a 1 < ··· < a h (h ≥ 1).(2) A resolution tree rooted at node V and V has m childrenV 1,···,V m.Output: The resolved decision of the rules in O1 S = ∅;2 for i := 1 to m do3 O i := {R x|V i.left ≤ x ≤ V i.right};4 if O i ≠ ∅ then S := S∪ ResolveByStructureTree(O i,V i);5 /*Suppose S = {R b1 ,···,R bg }, where b 1 < ··· 1 then return error;9 else return R b1 ’s effect;10 else if V.algorithm = Permit-Overrides then11 if ∃i,1 ≤ i ≤ g, R bi ’s decision is permit then return permit;12 else return R b1 ’s effect;13 else if V.algorithm = Deny-Overrides then14 if ∃i,1 ≤ i ≤ g, R bi ’s decision is deny then return deny;15 else return R b1 ’s effect;
Page 1 and 2: IEEE TRANSACTIONS ON COMPUTERS, MAN
Page 3: IEEE TRANSACTIONS ON COMPUTERS, MAN
Page 14: IEEE TRANSACTIONS ON COMPUTERS, MAN

Designing Fast and Scalable XACML Policy Evaluation Engines

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?