Designing Fast and Scalable XACML Policy Evaluation Engines

More documents

Recommendations

Info

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 8sequence following the first-match semantics. After we addthe last rule true → NotApplicable denoted as R −1 , the finalsequence of range rules, which is equivalent to the exampleXACML policy in Fig. 1, is shown in Fig. 8. We use na todenote NotApplicable.r 1 : S ∈ [0,0] ∧ R ∈ [0,0] ∧ A ∈ [0,0] → [R 1] dr 2 : S ∈ [1,1] ∧ R ∈ [0,0] ∧ A ∈ [0,0] → [ [R 1] d ,[R 2] p ] dr 3 : S ∈ [1,1] ∧ R ∈ [0,0] ∧ A ∈ [1,1] → [R 2] pr 4 : S ∈ [1,1] ∧ R ∈ [1,1] ∧ A ∈ [0,1] → [R 2] pr 5 : S ∈ [2,3] ∧ R ∈ [0,1] ∧ A ∈ [0,1] → [R 2] pr 6 : S ∈ [0,0] ∧ R ∈ [1,1] ∧ A ∈ [0,1] → [R 3] pr 7 : S ∈ [0,3] ∧ R ∈ [0,1] ∧ A ∈ [0,1] → [R −1] naFig. 8: The final sequence of range rules converted from the XACMLpolicy in Fig. 1H. Complex XACML FunctionsProblem: In sequential range rule representation, the predicateof each rule is uniformly specified as the conjunctionof member of a finite set predicates. However, in XACMLpolicies, the condition of a rule could be a complex booleanfunction that operates on the results of other functions, literalvalues, and attributes from requests. There are no side effectsto function calls and the final result is a boolean valueindicating whether or not the rule applies to the request. Anexample condition of a rule in an XACML policy could be“salary > 5000 or date > January 1, 1900”. How to modelcomplex functions of XACML policies in the sequential rangerule representation is a challenging issue.Solution: For a rule that has a condition specified usingXACML functions, we treat such a condition as part of thedecision of the rule. More formally, for a rule P ∧ f() →permit, we convert it to rule P → (if f() then permit). Indealing with rules, we treat the decision (if f() then permit)as a distinct decision. In dealing with rule/policy combiningalgorithms, we treat the decision (if f() then permit) as aspecial type of a permit decision. Our idea applies similarlyto deny rules.Example: Suppose R 1 in Fig. 3(b) has a function f(), thatis, the predicate of R 1 is S ∈ [0,1]∧R ∈ [0,0]∧A ∈ [0,0]∧f() → d. If so, we treat R 1 as S ∈ [0,1]∧R ∈ [0,0]∧A ∈[0,0] → (if f() then deny).I. Indeterminate EvaluationProblem: In evaluating a request against a rule (or policy,or policy set), there are three types of errors that may occur:networking errors, syntax errors, and incomplete requests.(1) Networking Errors: An XACML policy set may containa policy (or policy set) that resides on a remote machine.Evaluating the XACML policy set requires retrieving theremote policy (or policy set) over a network. Networkingerrors may occur in the retrieving process. (2) Syntax Errors:In evaluating a request against a rule (or policy, or policy set),the request and the rule (or policy, or policy set) may containsyntax errors. (3) Incomplete Requests: In evaluating a requestagainst a rule (or policy, or policy set), the request may notcontain the values of some attributes that are used in specifyingthe target (or condition) of the rule (or policy, or policy set).In this case, we say the request is incomplete for the rule (orpolicy, or policy set). For example, for a rule whose conditionis specified as age>30, a request that does not contain the ageof the subject is considered as an incomplete request for thisrule.XACML handles above errors using indeterminate decisions.In evaluating a request against a rule, if any error occurs,the evaluation result of the request on the rule is indeterminate.In evaluating a request against a policy (or a policy set), if anyerror occurs in evaluating the target of the policy (or policyset), the evaluation result of the request on the policy (or policyset) is indeterminate, regardless of the evaluation result of therequest on the rules contained by the policy (or the policiescontained by the policy set). In evaluating a request against apolicy (or a policy set), if no error occurs in evaluating thetarget of the policy (or policy set), but the evaluation resultsof the request on some rules contained by the policy (or onsome policies contained by the policy set) are indeterminate,the evaluation result of the request on the policy (or policyset) is determined as follows based on the rule (or policy)combining algorithm:First-Applicable or Only-One-Applicable: In this case, theevaluation result of the request on the policy (or policy set)is the evaluation result of the request on the first (or the onlyone) rule (or policy) whose evaluation result is permit, deny,or indeterminate.Permit-Overrides: The evaluation of a request against a policyset whose policy combining algorithm is Permit-Overridesis done according to the following pseudocode: if the policyset contains a policy whose evaluation result is permit, then theevaluation result of the policy set is permit; else if the policyset contains a policy whose evaluation result is deny, then theevaluation result of the policy set is deny; else if the policyset contains a policy whose evaluation result is indeterminate,then the evaluation result of the policy set is indeterminate;else the evaluation result of the policy set is NotApplicable.The evaluation of a request against a policy whose rulecombining algorithm is Permit-Overrides is done accordingto the following pseudocode: if the policy contains a rulewhose evaluation result is permit, then the evaluation result ofthe policy is permit; else if the policy contains a rule whoseevaluation result is indeterminate and whose effect is permit,then the evaluation result of the policy is indeterminate; else ifthe policy contains a rule whose evaluation result is deny, thenthe evaluation result of the policy is deny; else if the policycontains a rule whose evaluation result is indeterminate, thenthe evaluation result of the policy is indeterminate; else theevaluation result of the policy is NotApplicable.Deny-Overrides: The evaluation of a request against a policyset whose policy combining algorithm is Deny-Overrides isdone according to the following pseudocode: if the policyset contains a policy whose evaluation result is deny orindeterminate, then the evaluation result of the policy set isdeny; else if the policy set contains a policy whose evaluationresult is permit, then the evaluation result of the policyset is permit; else the evaluation result of the policy set isNotApplicable. The evaluation of a request against a policywhose rule combining algorithm is Deny-Overrides is doneaccording to the following pseudocode: if the policy contains arule whose evaluation result is deny, then the evaluation resultof the policy is deny; else if the policy contains a rule whoseevaluation result is indeterminate and whose effect is deny,then the evaluation result of the policy is indeterminate; elseif the policy contains a rule whose evaluation result is permit,then the evaluation result of the policy is permit; else if thepolicy contains a rule whose evaluation result is indeterminate,then the evaluation result of the policy is indeterminate; else
IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 9the evaluation result is NotApplicable.Solution: XEngine prevents errors as follows. To preventnetworking errors, as a preprocessing step, we first obtainall remote XACML policies. To prevent syntax errors, wepreprocess XACML policies and requests and make surethat they are syntactically correct. To deal with incompleterequests, given a request and an XACML policy, we firstfind all the rules that the request matches and all the ruleswhere the evaluation of the request is indeterminate; then usethe structure tree of the XACML policy to make the finaldecision based on the above policy/rule combining algorithmsin Algorithm 4, which considers indeterminate decisions.Algorithm 4: ResolveByStructureTree2(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 evaluation result;10 else if V.algorithm = Permit-Overrides then11 if V ’s children are nonterminal nodes then12if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is permit then returnpermit;13else if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is deny then returndeny;14else if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is indeterminatethen15return indeterminate;1617181920elseif ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is permit then returnpermit;else if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is indeterminateand R bi ’s effect is permit then return indeterminate;else if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is deny then returndeny;else if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is indeterminateand R bi ’s effect is deny then return indeterminate;21 else if V.algorithm = Deny-Overrides then22 if V ’s children are nonterminal nodes then23if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is deny orindeterminate then return deny;24else if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is permit thenreturn permit;2526272829elseif ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is deny then returndeny;else if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is indeterminateand R bi ’s effect is deny then return indeterminate;else if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is permit thenreturn permit;else if ∃i,1 ≤ i ≤ g, R bi ’s evaluation result is indeterminateand R bi ’s effect is permit then return indeterminate;XEngine handles incomplete requests slightly different,and arguably better, than XACML specification 2.0 [9]. InXEngine, if an incomplete request has no hope of satisfyingthe target of a policy or matching a rule regardless of themissing values, then the evaluation of the policy or the rule isNotApplicable. However, according to XACML specification2.0, as long as a request has missing values needed to evaluatea policy target or a rule, the evaluation of the request on thepolicy or the rule is indeterminate. For example, consideringa rule saying “a professor can change grades” and a requestin which the subject is a student and the resource is gradesbut the value of the action is not provided, XEngine evaluatesthis request on the rule as NotApplicable because no matterwhat the value for the action is, this request by no meanscan match the rule as their values of the subject attribute donot match. However, XACML specification 2.0 evaluates thisrequest on the rule as indeterminate simply because of themissing value for the action attribute. We argue that XEnginehandles incomplete requests in a more precise (thereforebetter) manner than XACML specification 2.0 does.Further note that the way that XEngine handles incompleterequests is consistent with the way that XEngine handlesmulti-valued requests. Given a multi-valued request Q anda rule (or policy, or policy set), either all the single-valuedrequests decomposed from Q are complete for the rule (orpolicy, or policy set) or all the single-valued requests decomposedfrom Q are incomplete for the rule (or policy, or policyset). This is because all the single-valued requests decomposedfrom Q have values for the same set of attributes.Example: Considering the policy in Fig. 4(a), whose structuretree is in Fig. 4(b). Suppose we are given a multi-valuedrequest Q, which can be decomposed into two single-valuedrequest Q 1 and Q 2 . Suppose the evaluation of Q 1 on R 3 isindeterminate and that on any other rule is NotApplicable, andthe evaluation of Q 2 on R 5 is permit and that on any otherrule is NotApplicable. Based on Algorithm 4, the evaluationresult of request Q on node V 4 is indeterminate and that onnode V 5 is permit. Similarly, the evaluation result of Q onnode V 3 is permit and that on node V 1 is permit.J. Correctness of XACML NormalizationThe correctness of XACML policy numericalization is obvious.The correctness of XACML policy normalization followsfrom Lemmas 4.1 and 4.2, Theorems 4.3 and 4.4.Lemma 4.1: Given an XACML policy (or policy set) Xwith combining algorithm A, where A ∈ {Permit-Overrides,Deny-Overrides}, for any request Q, the origin block ofthe first rule that Q matches in AllMatch2FirstMatch(X, A)consists of all the rules that Q matches in X.Proof: Let X be 〈X 1 ,···,X n 〉, where each X i is a rule,policy or policy set.We first prove Lemma 4.1 for the base case where each X iis an XACML rule. Let 〈R 1 ,···,R n 〉 denote X, where eachR i is a rule. According to the AllMatch2FirstMatch algorithm,we build a partial PDD such that for any decision pathP in thePDD and any R i , using P (or R i ) to denote the set of requeststhat match P (or R i ), if P ∩R i ≠ ∅, then P ⊆ R i and R i ’sOB ∈ P’s origin block. For any request Q, there exists atmost one decision path in the partial PDD that Q matches.Suppose there exists a decision path P that Q matches. Thus,for any R i that Q ∈ R i , R i ∩P ≠ ∅, which means R i ’s OB∈ P’s OB.We next prove Lemma 4.1 for the case where each X i isa policy or policy set and X i ′ is the equivalent sequence ofthe first-match rules. That is, for each X i , we assume thatfor any request Q, the origin block of the first rule that Qmatches in X i ′ consists of all the rules that Q matches in X i.Let 〈R 1 ,···,R g 〉 be 〈X 1|···|X ′ n〉. ′ Similar to the reason forthe base case, for any request Q, if Q matches a decision pathP of the constructed partial PDD for 〈R 1 ,···,R g 〉, then for
Page 1 and 2: IEEE TRANSACTIONS ON COMPUTERS, MAN
Page 14: IEEE TRANSACTIONS ON COMPUTERS, MAN

Designing Fast and Scalable XACML Policy Evaluation Engines

Create successful ePaper yourself

Delete template?

Save as template?