Designing Fast and Scalable XACML Policy Evaluation Engines

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 1Designing Fast and ScalableXACML Policy Evaluation Engines 1Alex X. Liu Fei Chen JeeHyun Hwang Tao XieAbstract—Most prior research on policies has focused oncorrectness. While correctness is an important issue, the adoptionof policy-based computing may be limited if the resulting systemsare not implemented efficiently and thus perform poorly. To increasethe effectiveness and adoption of policy-based computing,in this paper, we propose fast policy evaluation algorithms thatcan be adapted to support various policy languages. In this paper,we focus on XACML policy evaluation because XACML has becomethe de facto standard for specifying access control policies,has been widely used on web servers, and is most complex amongexisting policy languages. We implemented our algorithms ina policy evaluation system called XEngine and conducted sideby-sidecomparison with Sun Policy Decision Point (PDP), theindustrial standard for XACML policy evaluation. The resultsshow that XEngine is orders of magnitude faster than SunPDP. The performance difference grows almost linearly with thenumber of rules in an XACML policy. To our best knowledge,there is no prior work on improving XACML policy evaluationperformance. This paper represents the first step in exploringthis unknown space.Index Terms—Web servers, XACML, Policy evaluation, policybasedcomputing, access control, policy decision point.I. INTRODUCTIONA. MotivationThe management complexity of large-scale informationsystems has been increasing rapidly due to the continuous evolutionof systems [32]. Policy-based computing is a softwaremodel that simplifies and automates the administration of computingsystems by incorporating decision-making technologiesinto its management components. Policy-based computing hasemerged as an effective approach to combat system complexitybecause it separates policies from system implementation andenables dynamic adaptability of system behavior by changingpolicy configurations without reprogramming the systems.Policies are configurable rules governing the behavior of asystem. For example, access control policies specify whichprincipal can access which resources in what manner in mostsystems.Policy evaluation, the process of checking whether a requestsatisfies a policy, is often the performance bottleneck ofpolicy-based computing systems. For example, consider aweb server application whose access control is enforced byan XACML (eXtensible Access Control Markup Language)[9] policy. A subject (e.g., a college professor) wants toperform an action (e.g., change) on a protected resource (e.g.,Alex X. Liu and Fei Chen are with the Department of Computer Scienceand Engineering, Michigan State University, East Lansing, Michigan, 48824.E-mail: {alexliu, feichen}@cse.msu.eduJeeHyun Hwang and Tao Xie are with the Department of Computer Science,North Carolina State University, Raleigh, North Carolina, 27695.E-mail: jhwang4@ncsu.edu, xie@csc.ncsu.eduManuscript received July 06, 2009.1 The preliminary version of this paper titled “XEngine: A Fast and ScalableXACML Policy Evaluation Engine” was published in SIGMETRICS 2008 [24].This work is supported in part by NSF grants CNS-0845513, CNS-0716407,and CNS-0716579.student grades). The subject submits this request to the policyevaluation engine and then this engine checks the requestagainst the policy to decide whether the request should begranted. Every user request needs to be checked throughthis procedure. For large applications with many users andresources, XACML policies are typically large and complexand the number of simultaneous requests is huge. A realaccess control system may manage the accesses of thousandsof subjects to millions of resources [17]. The XACML policyspecified for such systems may easily have tens of thousandsof rules. However, commercial implementation of XACMLpolicy evaluation engines such as Sun XACML PDP [2],which performs brute force searching by comparing a requestwith all the rules in an XACML policy, still represents thestate-of-the-art. Therefore, fast policy evaluation is a crucial,but under-investigate problem.B. Summary and Limitations of Prior WorkDespite its importance, high performance policy evaluationhas received little attention. Most prior work on policiesfocuses on correctness issues (i.e., specification, design, andanalysis) (e.g., [7], [8], [10], [28]). While correctness issuesare important, the adoption of policy-based computing may belimited if the resulting systems are not implemented efficientlyand thus perform poorly. Due to the lack of fast policyevaluation schemes, it has been the system administrator’sobligation to specify policies that satisfy both correctnessand performance goals. However, mixing the two aspectstogether violates the well-known principle of separation ofconcerns (SoC) [6] and contributes to policy errors. As policiesdetermine the behavior of policy-based systems, an error in apolicy may lead to irreparable consequences.C. Our Approach and Technical ChallengesTo promote the separation of correctness and performanceissues for policies, we propose two techniques for fast policyevaluation: policy normalization and canonical representation.The idea of policy normalization is to convert a policy with acomplex logical structure to an equivalent policy with a simplelogical structure. The idea of canonical representation is toconvert a policy to a reduced multi-valued decision diagram.The key intuition behind XEngine is that policy normalizationand canonical representation allow us to make a decisionfor a request without examining every rule in the policy.Furthermore, they open many new opportunities for buildingefficient data structures for fast request processing. In thispaper, we present two schemes for fast processing of requests:the decision diagram scheme and the forwarding table scheme.In summary, our approach to fast policy evaluation consists ofthree steps. First, we perform normalization on the given policy.Second, we convert the normalized policy to its canonicalrepresentation. Third, we build efficient data structures fromthe canonical representation for fast policy evaluation.

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 2To have a concrete instantiation of our approaches, in thispaper, we take XACML as the policy language for threereasons. First, XACML has become the de facto standardfor specifying access control policies. It has been widelysupported by main platform vendors and extensively usedon today’s web servers for a variety of applications. Second,fast XACML policy evaluation is critical. As the number ofresources and users managed by web servers grows rapidly,XACML policies grow correspondingly in size and complexity.To process simultaneous requests of large quantities inreal time, especially in face of a burst volume of requests,a fast XACML policy evaluation engine is essential. Third,XACML is most complex among existing policy languagessuch as XACL [15], SPL [27], REI [19], [20], and EPAL [18].Our methods for the fast evaluation of XACML policies canbe adapted to other rule-based policy languages. For example,we have been able to do so for the EPAL policy language [25].Making XACML policy evaluation fast is challenging.First, XACML policies have complex structures. For example,XACML policies can be specified recursively. An XACMLpolicy consists of a policy set and a policy set consists of asequence of policies or policy sets. Second, an XACML policyoften has conflicting policies or rules, which are resolvedby four different mechanisms: First-Applicable, Only-One-Applicable, Permit-Overrides, and Deny-Overrides. Third, inXACML, the predicates that a request needs to be checkedupon are scattered. Each policy set, policy, or rule has its ownpredicate. Fourth, in XACML, a request could be multi-valued.For example, the subject of a request could be a principal whois both a professor and a student. Last but not the least, inXACML policies, a rule may be multi-valued. For example, arule in an XACML policy may specify that the subject must beboth a professor and a student. These complexities of XACMLpolicies make brute force searching, which is prior art, appearto be the natural way of processing requests.In this paper, we present the details of XEngine, a fast andscalable XACML policy evaluation engine, which incarnatesour ideas of policy normalization and canonical representation.For policy normalization, XEngine converts an XACML policywith a hierarchical structure and multiple complex conflictresolution mechanisms into an equivalent policy with a flatstructure and only one conflict resolution mechanism, whichis First-Applicable. For canonical representation, XEngineconverts a normalized policy to a special decision diagram.Deploying XEngine in real systems is simple: it onlyrequires the replacement of the policy evaluation algorithmin existing XACML PDPs. Other components of the XACMLinfrastructure can remain unchanged.To our best knowledge, there is no prior work on improvingXACML policy evaluation performance. This paper representsthe first step in exploring this unknown space. We hopeto attract attention from the research community on thisimportant, yet challenging, problem.D. Experimental Results Summary and ValidationThe researchers have implemented XEngine using Java 1.6.3and open-sourced our code in SourceForge [1]. To evaluateXEngine performance, we compare it with the standard SunPDP implementation. We choose Sun PDP in our comparisonfor two reasons. First, it is the first and the most widelydeployed XACML evaluation engine and has become theindustrial practice. Second, Sun PDP is open source. Toeliminate the performance factor of programming languages,we implemented XEngine in Java because Sun PDP is writtenin Java. We conducted extensive experiments on real-lifeXACML policies collected from various sources as well assynthetic policies of large sizes. The experimental results showthat XEngine is orders of magnitude faster than Sun PDP andthe performance difference between XEngine and Sun PDPgrows almost linearly with the number of rules in an XACMLpolicy. For small policies with hundreds of rules, XEngineis one to two orders of magnitude faster. For large policieswith thousands of rules, XEngine is three to four ordersof magnitude faster. XEngine significantly outperforms thestandard XACML policy evaluation engine Sun PDP primarilybecause XEngine finds the correct decision for a requestwithout going through the whole policy as Sun PDP does.We formally prove that our XEngine algorithms make thecorrect decision for every request based on the complexXACML 2.0 specification [9]. Furthermore, we empiricallyvalidate the correctness of XEngine in our experiments. Wefirst randomly generate 100K single-valued requests and 100Kmulti-valued requests; we then feed each request to XEngineand Sun PDP and compare their decisions. The results confirmedthat XEngine and Sun PDP are functionally equivalent.II. BACKGROUNDXACML is an XML-based language standardized by theOrganization for the Advancement of Structured InformationStandards (OASIS). It was designed to replace applicationspecificand proprietary access-control policy languages. Priorto XACML, every application vendor had to create its ownproprietary method for specifying access control policies, andthese applications could not understand each other’s language.Typical XACML based access control works as follows. Asubject (e.g., a professor) wants to perform an action (e.g.,modify) on a protected resource (e.g., grades). The subjectsubmits this request to the Policy Enforcement Point (PEP)that manages the protected resource. The PEP formulates sucha request using the XACML request language. Then, the PEPsends the XACML request down to the Policy Decision Point(PDP), which stores a user specified access control policywritten in the XACML policy language. The PDP checks therequest with its XACML policy and determines whether theXACML request should be permitted or denied. Finally, thePDP formulates the decision in XACML response languageand sends it to the PEP, which enforces the decision.An XACML policy consists of a policy set and a policycombining algorithm. A policy set consists of a sequence ofpolicies or policy sets, and a target. A policy consists of atarget, a rule set, and a rule combining algorithm. A target is apredicate over the subject (e.g., professor), the resource (e.g.,grades), and the action (e.g., assign) of requests, specifyingthe type of requests to which the policy or policy set can beapplied. If a request satisfies the target of a policy, then therequest is further checked against the rule set of the policy;otherwise, the policy is skipped without further examiningits rules. The target of a policy set has similar semantics. Arule set is a sequence of rules. A rule consists of a target, acondition, and an effect. Similar to the target of a policy ora policy set, the target of a rule specifies whether the rule isapplicable to a request by setting constraints on the subject,

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 3the resource, and the action of requests. The condition in arule is a boolean expression that refines the applicability ofthe rule beyond the predicates specified by its target, and isoptional. Given a request, if it matches both the target andcondition of a rule, then the rule is applicable to the requestand the rule’s effect (i.e., permit or deny) is returned as thedecision; otherwise, NotApplicable is returned.In an XACML policy, rules or policies may conflict, i.e.,two rules or policies may define different decisions for thesame request. XACML resolves these conflicts by employingfour rule (or policy) combing algorithms: First-Applicable,Only-One-Applicable, Deny-Overrides, and Permit-Overrides.For a First-Applicable policy (or policy set), the decision ofthe first applicable rule (or policy) is returned. For an Only-One-Applicable policy (or policy set), the decision of the onlyapplicable rule (or policy) is returned; indeterminate (whichindicates an error) is returned if there are more than one applicablerule (or policy). For a Deny-Overrides policy (or policyset), deny is returned if any rule (or policy) evaluation returnsdeny; permit is returned if all rule (or policy) evaluations returnpermit. For a Permit-Overrides policy (or policy set), permit isreturned if any rule (or policy) evaluation returns permit; denyis returned if all rule (or policy) evaluations return deny. Forall of these combining algorithms, NotApplicable is returnedif no rule (or policy) is applicable.12 3 4 5 14 15 Professor 16 Lecturer 17 Secretary 18 Grades 19 Records 20 Change 21 Read 22 23 24 25 26 27

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 < ··· < b g (g ≥ 1)*/6 if V.algorithm = First-Applicable then return R b1 ’s effect;7 else if V.algorithm = Only-One-Applicable then8 if |S| > 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;

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 6Note that in processing a policy whose rule combiningalgorithm is First-Applicable, for a single-valued request decomposedfrom a multi-valued request, we do not need tocompute all the original XACML rules that the single-valuedrequest matches; instead, we only need to compute the firstoriginal XACML rule that the single-valued request matches.The reason is as follows. Let X = 〈X 1 ,···, X n 〉 be a policywhose combining algorithm is First-Applicable. Let O(Q i ) bethe set of all the original XACML rules that Q i matches, andF(Q i ) be the first original XACML rules that Q i matches.Because the XACML rule with the smallest sequence numberin ∪ k i=1 O(Q i) is the same as the XACML rule with thesmallest sequence number in {F(Q 1 ),···,F(Q k )}, this ruleis essentially the XACML rule that determines the decisionfor Q. Therefore, for each Q i , we only need to compute thefirst original XACML rule that Q i matches.[1,4]Permit-OverridesV 1V 3V 2[1,2][3,4]First-ApplicableFirst-ApplicableR 1 : Professordeny R 2 : Studentpermit R 3 : Studentdeny R 4 : ProfessorpermitFig. 5: An example structure treeExample: Suppose a multi-valued request Q is “a person,who is both a professor and a student, wants to access asystem”, and the structure tree of the given XACML policy isin Fig. 5. We first decompose this multi-valued request intotwo single-valued requests, Q 1 : “a professor wants to accessthe system”, and Q 2 : “a student wants to access the system”.Second, we compute the set of all the original rules that Q 1or Q 2 matches, which is O = {R 1 ,R 2 ,R 3 ,R 4 }. Next, we usethis set and the structure tree in Fig. 5 to find the final decisionfor request Q. Because the rule combining algorithm at nodeV 2 is First-Applicable, and the decision of R 1 is deny and thedecision of R 2 is permit, the decision resolved at node V 2 isdeny. Similarly, the decision resolved at V 3 is deny. Becausethe policy combining algorithm at nodeV 1 is Permit-Overridesand the decisions resolved at node V 2 and V 3 are deny, thedecision resolved at node V 1 is deny. Thus, Q’s decision isdeny.F. All-match to First-match ConversionProblem: For each single-valued request decomposed from amulti-valued request, we may need to compute all the originalXACML rules that the single-valued request matches. To avoidscanning the entire rule list, our idea is to convert a rulesequence following the all-match semantics to an equivalentsequence of rules following the first-match semantics. Moreformally, given a policy (or policy set) X = 〈X 1 ,···,X n 〉where eachX i has been normalized to X i ′ , andX’s combiningalgorithm A is either Permit-Overrides or Deny-Overrides,we want to convert 〈X 1 ′ |···|X′ n 〉, which is denoted as〈R 1 ,···,R g 〉 following the all-match semantics, to a sequenceof range rules Y = 〈Y 1 ,···,Y m 〉 following the first-matchsemantics such that for each single-valued request Q, thedecision of the first matching rule in Y should contain twocomponents. First, it should contain the indexes of all the rulesthat Q matches in 〈R 1 ,···,R g 〉. Such information is neededwhen we process multi-valued requests. Second, it shouldcontain the decision that X makes for Q. Such information isneeded when we process single-valued requests. This problemis particularly challenging because of the multi-dimensionalityof XACML rules. That is, each rule has multiple attributes.Solution: We design the effect of each first-match rule usinga new data structure called an origin block (OB). The originblock ϕ dec of a rule consists of two components ϕ and dec,where ϕ is either one original XACML rule or a set of originblocks, and dec is the winning decision of ϕ. The winningdecision of a rule’s origin block is the decision that the rulemakes for any single-valued request that matches the rule.Thus, for a single-valued request not decomposed from amulti-valued request, the winning decision is used to computethe final decision for the request; for a single-valued requestdecomposed from a multi-valued request, the original XACMLrules are used to compute the final decision for the multivaluedrequest. An example OB is [[R 5 ] p ,[R 8 ] d ] p , where ddenotes deny and p denotes permit.To convert all-match rules to first-match rules, we use policydecision diagrams as the core data structure. Let 〈X 1 ,···,X n 〉be a policy (or policy set). For each i, let X i ′ be the normalizationresult of X i . Let 〈R 1 ,···,R g 〉 denote 〈X 1 ′ |···|X′ n 〉.We first convert the all-match rule set 〈R 1 ,···,R g 〉 to anequivalent partial PDD. A partial PDD has all the propertiesof a PDD except the completeness property. An all-match ruleset 〈R 1 ,···,R g 〉 and a partial PDD are equivalent if and onlyif the following two conditions hold. First, for eachR i denotedas (F 1 ∈ S 1 )∧···∧(F z ∈ S z ) → OB and each decision pathP denoted as (F 1 ∈ S 1)∧···∧(F ′ z ∈ S z) ′ → OB ′ , either R iand P are non-overlapping (i.e., ∃(1 ≤ j ≤ z), S j ∩S ′ j = ∅)′or P is a subset of R i (i.e., ∀(1 ≤ j ≤ z), S j ⊆ S j ); inthe second case, R i ’s origin block is included in P’s terminalnode. InP’s terminal node, we define the source ofR i ’s originblock to be h i if R i ∈ X hi . Second, using P (or R i ) to denotethe set of requests that match P (or R i ), the union of all therules in 〈R 1 ,···,R g 〉 is equal to the union of all the paths inthe partial PDD.After a partial PDD is constructed, we generate a rulefrom each decision path. As the generated rules are nonoverlapping,the order of the generated rules is immaterial.For each generated rule, let OB denote its origin block, wefirst classify the origin blocks in OB based on their sources;second, we combine all the origin blocks in the same groupinto one origin block whose winning decision is the decision ofthe block with the smallest source because the rules in eachX i ′ follow the first-match semantics; third, we compute thewinning decision for OB based on the combining algorithmof 〈X 1 ,···,X n 〉. Finally, the resulting sequence of generatedrules is the sequence of first-match rules. The pseudocodeof the all-match to first-match conversion algorithm is inAlgorithm 2. Note that in this paper we use e.t to denotethe node that e points to.Example: Fig. 6 shows the partial PDD converted fromthe all-match rule sequence 〈R 1 ,R 2 〉 in Fig. 3(b), and Fig.7 shows the first-match rules generated from Fig. 6.G. Unifying Rule/Policy Combining AlgorithmsProblem: In sequential range rule representation, thereis only one rule combining algorithm, which is First-Applicable. However, XACML supports four rule (or policy)combining algorithms: First-Applicable, Only-One-Applicable,Deny-Overrides, and Permit-Overrides. The key challenge in

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 < ··· < b g (g ≥ 1)*/6 if V.algorithm = First-Applicable then return R b1 ’s evaluation result;7 else if V.algorithm = Only-One-Applicable then8 if |S| > 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

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 10any R i that Q ∈ R i , R i ∩P ≠ ∅, which means R i ’s OB ∈P’s OB. By induction, P’s OB contains all the rules that Qmatch in X.Lemma 4.2: Given an XACML policy (or policy set) Xwith combining algorithm A, where A ∈ {Permit-Overrides,Deny-Overrides}, for any single-valued request Q, usingOB(Q) to denote the origin block of the first rule that Qmatches in AllMatch2First-Match(X,A), the winning decisionof OB(Q) is the same decision that X makes for Q.Proof: We first prove Lemma 4.2 for the base case, whereeach X i is an XACML rule. Let 〈R 1 ,···,R n 〉 denote X,where each R i is a rule. According to Lemma 4.1, OB(Q)consists of all the rules that Q matches in X. According tothe AllMatch2FirstMatch algorithm, the winning decision ofOB(Q) is determined by the combining algorithm A. Thus,the winning decision for OB(Q) is the same that X makesfor Q.We next prove Lemma 4.2 for the case where each X iis a policy or policy set and X i ′ is the equivalent sequenceof the first-match rules. In other words, for each X i , weassume that for any request Q, the origin block of the firstrule that Q matches in X i ′ consists of all the rules that Qmatches in X i . Let 〈y 1 ,···,y m 〉 be the generated rules fromthe partial PDD, which is constructed from 〈X 1,···,X ′ n〉. ′ Forany request Q, there exists at most one y i in 〈y 1 ,···,y m 〉 thatQ matches. Suppose Q matches y i , then OB(Q) is the originblock of y i . According to the AllMatch2FirstMatch algorithm,we classify OB(Q)’s origin blocks based on their sourcesand combine the OB(Q)’s origin blocks with the smallestsources in each group, because each X i ′ follows the firstmatchsemantics. After grouping, for each X i ′ , there is atmost one origin block in OB(Q) whose source is i. Thus,the winning decision of OB(Q), which is computed based onX’s combining algorithm, is the same decision that X makesfor Q.Theorem 4.3: Given an XACML policy X and its normalizedversion Y , for any single-valued request Q, X and Yhave the same decision for Q.Proof: Let A be X’s combining algorithm. If A isFirst-Applicable or Only-One-Applicable, the correctness ofTheorem 4.3 follows directly from the first-match semantics.If A is Permit-Overrides or Deny-Overrides, the correctnessof Theorem 4.3 follows from Lemma 4.2.Theorem 4.4: Given an XACML policy X and its normalizedversion Y , for any multi-valued requestQ, X and Y havethe same decision for Q.Proof: Let Q 1 ,···,Q k be the resulting single-valuedrequests decomposed from Q. If X’s combining algorithmis Only-One-Applicable, Permit-Overrides or Deny-Overrides,according to Lemma 4.1, the OB of the first rule that Q imatches in Y consists of all the rules that Q i matches inX. Thus, ∪ k i=1 O(Q i) consists of all the rules in X that Qmatches. Therefore, the decision resolved by the structure treeof X for all the rules that Q matches in X is the decisionthat X makes for Q. If X’s combining algorithm is First-Applicable, the XACML policy normalization algorithm onlycomputes the first rule that each Q i matches in X. This isequivalent to compute all the rules that Q i matches in X.V. THE POLICY EVALUATION ENGINEAfter converting an XACML policy to a semantically equivalentsequence of range rules, we need an efficient scheme tosearch the decision for a given request using the sequenceof range rules. In this section, we describe two schemesfor efficiently processing single-valued requests, namely thedecision diagram scheme, and the forwarding table scheme.We further discuss methods for choosing the appropriatescheme in real applications.A. The Decision Diagram SchemeThe decision diagram scheme uses the policy decisiondiagram converted from a sequence of range rules to improvethe efficiency of the decision searching operation. Constructinga PDD from a sequence of first-match rules is similar tothe algorithm for constructing a PDD from a sequence ofall-match rules. Fig. 9 shows the PDD constructed from〈r 1 ,r 2 ,r 3 ,r 4 ,r 5 ,r 6 ,r 7 〉 in Fig. 8.[0, 0]AR[0, 0] [1, 1]S[0, 0] [2, 3][1, 1][1, 1] [0, 0]A[0, 1][0, 0]AR[1, 1]AR[0, 1]A[1, 1] [0, 1][0, 1][R 1 ] d [R -1 ] na [R 3 ] p [[R 1 ] d , [R 2 ] p ] d [R 2 ] p [R 2 ] p [R 2 ] pFig. 9: The PDD constructed from the range rules in Fig. 8The algorithm for processing a single-valued request Qconsists of two steps. First, we numericalize the request usingthe same numericalization table in converting the XACMLpolicy to range rules. For example, a request (Professor, Grade,Change) will be numericalized as a tuple of three integers (2,0, 0). Second, we search for the decision of the numericalizedrequest on the constructed PDD. Note that every terminal nodein a PDD is labeled with an origin block.To speed up decision searching, for each nonterminal nodev with k outgoing edges e 1 ,···,e k , we sort the ranges inI(e 1 ) ∪ ··· ∪ I(e g ), i.e., all the ranges that appear on theoutgoing edges of v, in an increasing (or decreasing) order. Inthe sorted list, each range I, assuming I ∈ I(e j ), is associatedwith a pointer that points to the target node that e j points to.This allows us to perform a binary search at each nonterminalnode. 1) Complexity Analysis: Space Complexity: Suppose thesequence of range rules generated from an XACML policyis 〈r 1 ,r 2 ,···,r n 〉, where each rule r i is represented asF 1 ∈ S1 i ∧ F 2 ∈ S2 i ∧ ··· ∧ F z ∈ Sz i → 〈dec〉. For eachfield F j (1 ≤ j ≤ z) , Sj i has two end points, namelythe minimum and maximum value of the range Sj i. Thus,there are at most 2n points in the domain of F i . The totalnumber of intervals separated by the 2n points is thereforeat most 2n − 1, which means that the number of outgoingedges of a node labeled F i is at most 2n − 1. Note thatthe number of outgoing edges of a node labeled F i cannotexceed|D(F i )|. Thus, the number of outgoing edges of a nodelabeled F i is at most min(|D(F i )|,2n−1). Therefore, theworst case space complexity of the decision diagram schemeis O( ∏ zi=1 min(|D(F i)|,2n−1)).Time Complexity: As we discussed above, the total numberof intervals on the outgoing edges of a node labeled F i isat most min(|D(F i )|,2n−1). Hereby, the time complexityfor processing a single-valued request based on the PDD isO( ∑ zi=1 log(min(2n−1,|D(F i)|))).

()IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 11B. The Forwarding Table SchemeThe forwarding table scheme is based on the PDD that wasconstructed in the decision diagram scheme. The basic idea ofthe forwarding table scheme is to convert a PDD to z tables,which we call forwarding tables, such that we can searchthe decision for each single-valued request by traversing theforwarding tables in z steps.1) Constructing Forwarding Tables: For ease of presentation,we assume that each decision path in the constructedPDD contains z nodes that are labeled in the order ofF 1 ,···,F z from the root to the terminal node. Given a PDD,we construct forwarding tables as follows. First, for eachnonterminal node v, suppose v is labeled F i and v has koutgoing edges e 1 ,···,e k , we create a one-dimensional arrayT of size |D(F i )|. Considering an arbitrary value m in D(F i ),suppose m ∈ I(e j ). If the target node pointed by e j is anonterminal node, say v ′ , then T[m] is the pointer of the tablecorresponding to v ′ . If the target node pointed by e j is aterminal node, then T[m] is the label of the terminal node,which includes the origin block of the path containing theterminal node. Second, for each attribute F i , we compose allthe tables of the nodes with label F i into one two-dimensionalarray named T i . If we use M i to denote the total number ofF i nodes in the PDD, then the array T i is a |D(F i )| × M itwo dimensional array. Note that every element in T i is avalue in the range [0,M i+1 − 1], which is the pointer to acolumn in the next forwarding table T i+1 . The pseudocode ofthe algorithm for constructing forwarding tables from a PDDis in Algorithm 5. The forwarding tablesT 1 ,T 2 ,T 3 constructedfrom the example PDD in Fig. 9 are in Fig. 10. Note that e g .tdenotes the target node that edge e g points to, and F(e g .t)denotes the label of e g .t.Algorithm 5: Construct Forwarding TablesInput: A PDD.Output: Forwarding tables T 1,···,T z.1 put the root into queue Q;2 while Q ≠ ∅ do3 sum := 0;4 for j := 0 to sizeof(Q) − 1 do5remove node v from Q;6/*Suppose F(v) is F h and v has k outgoing edgese 0,e 1,···,e k−1 .*/7if F h ≠ F z then8for i := 0 to |D(F i)| − 1 do9if i ∈ I(e g) then T h [i,j] := sum + g;10111213141516sum := sum + k;for g := 0 to k − 1 do put e g.t in Q;elsefor i := 0 to |D(F i)| − 1 dofor g := 0 to k − 1 doif i ∈ I(e g) then T z[i,j] := F(e g.t);return T 1,···,T z;2) Processing Single-valued Requests: Given a singlevaluedrequest Q = (m 1 ,···, m z ), we can find the originblock for this request in z steps. First, we use m 1to find the value T 1 [m 1 ]. Second, we use m 2 to find thevalue T 2 [m 2 ,T 1 [m 1 ]]. Third, we use m 3 to find the valueT 3 [m 3 ,T 2 [m 2 ,T 1 [m 1 ]]]. This process continues until we findthe value in T z , which contains the origin block for thegiven request. The pseudocode of the algorithm for processingsingle-valued requests is in Algorithm 6.Taking the example forwarding tables in Fig. 10, supposewe have a request (1,1,0). We first use 1 to find the valueT 1 [1] = 1. Second, we use 1 to find the value T 2 [1,1] = 3.Third, we use 0 to find the decision T 3 [0,3] = [R 2 ] p for therequest, which means the origin isR 2 and the winning decisionis permit. The searching operation for request (1,1,0) is inFig. 10.3) Complexity Analysis: Space Complexity: Giventhe PDD constructed from a sequence of n rangerules,∏the number of F i nodes in the PDD is ati−1mostj=1 min(2n−1,|D(F j)|). Thus, the size ofarray T i is |D(F i )| ∏ i−1j=1min(2n−1,|D(F j )|). Thespace complexity of the forwarding table scheme isO( ∑ zi=1 (|D(F i)| ∏ i−1j=1 min(2n−1,|D(F j)|))).Algorithm 6: Process Requests With Forwarding TablesInput: (1) A single-valued request (m 1,···,m z).(2) Forwarding tables T 1,···,T z.Output: The origin block for the single-valued request.1 j := 0;2 for i := 1 to z do3 if i = z then return T z[m z,j];4 else if i = 1 then j := T 1[m 1];5 else j := T i[m i,j];T 2A request T 1 0 01 1 11 2 20 1 203 20 0 2 41 1 3 4T 30 1 2 3 40 [R 1 ] d [R 3 ] p [ [R 1 ] d , [R 2 ] p ] d [R 2 ] p [R 2 ] p1 [R -1 ] na [R 3 ] p [R 2 ] p [R 2 ] p [R 2 ] pFig. 10: Forwarding tables for PDD in Fig. 9Time Complexity: The time complexity for processing asingle-valued request using forwarding tables is O(z).C. Comparing the Two SchemesComparing the two schemes in terms of memory space andrequest processing time, the decision diagram scheme requiresa smaller amount of memory and a larger amount of processingtime; the forwarding table scheme requires a larger amount ofmemory and a smaller amount of processing time.Choosing which scheme to use depends on the propertradeoff between memory space and processing time. In areal application, we can pre-compute the exact memory spacerequired by each scheme, and then choose the more efficientscheme that satisfies the memory requirement of the application.VI. EXPERIMENTAL RESULTSWe implemented XEngine using Java 1.6.3. Our experimentswere carried out on a desktop PC running WindowsXP SP2 with 3.5G memory and dual 3.4GHz Intel Pentiumprocessors. We evaluated the efficiency and effectiveness ofXEngine on both real-life and synthetic XACML policies.In terms of efficiency, we measured the request processingtime of XEngine in comparison with that of Sun PDP [2].For XEngine, the processing time for a request includes thetime for numericalizing the request and the time for findingthe decision for the numericalized request. For Sun PDP,the processing time for a request is the time for finding the

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 12# ofRulesSize(KB)Preprocessing Time(ms)Memory Size(KB)PolicyPDD Table PDD Table1 (codeA) 2 5.0 15 16 0.35 0.352 (codeB) 3 7.8 16 16 0.41 0.423 (codeC) 4 8.8 15 20 0.48 0.494 (codeD) 5 11.0 22 25 0.58 0.615 (continue-a) 298 418 271 285 32.9 61.36 (continue-b) 306 424 205 217 34.3 63.97 (pluto) 21 107 47 51 8.26 9.17Fig. 11: Experimental results on real-life XACML policiesPre−processing Time(s)7654321PDDTable0400 800 1200 1600 2000 2400 2800 3200 3600 4000Number of RulesFig. 14: Preprocessing time on syntheticXACML policiesMemory Size(KB)12010080604020Total Processing Time(ms)10 6 Sun PDPPDDTable10 410 210 01 2 3 4 5 6 7PolicyFig. 12: Total processing time for100,000 single-valued requests onreal-life XACML policiesPDDTabledecision. The experimental results showed that XEngine isorders of magnitude more efficient than Sun PDP, and theperformance difference between XEngine and Sun PDP growsalmost linearly with the number of rules in XACML policies.For real-life XACML policies (of small sizes with hundreds ofrules), the experimental results showed that XEngine is twoorders of magnitude faster than Sun PDP for single-valuedrequests and one order of magnitude faster than Sun PDP formulti-valued requests. For synthetic XACML policies (of largesizes with thousands of rules), the experimental results showedthat XEngine is three to four orders of magnitude faster thanSun PDP for both single-valued and multi-valued requests.We measured the preprocessing time of XACML policiesfor XEngine. The preprocessing time of an XACML policyincludes the time for normalizing the policy and the time forbuilding the internal data structure (of a PDD or forwardingtable). For a real-life XACML policy (of small sizes withhundreds of rules), the preprocessing takes less than a second.For synthetic XACML policies (of large sizes with thousandsof rules), the preprocessing takes a few seconds. For example,normalizing an XACML policy of 4000 rules takes about 6seconds.We also measured the memory size of XEngine on XACMLpolicies. Specifically, for each XACML policy, we measure thememory size of the PDD and the forwarding table convertedfrom the policy.In terms of effectiveness, we compared the decisions madeby XEngine and Sun PDP for each request. In our experiments,we first generated 100,000 random single-valued requests and100,000 random multi-valued requests; and then fed eachrequest to both XEngine and Sun PDP and compared theirdecisions. The experimental results showed that XEngine andSun PDP have the same decision for every request.A. Performance on Real-life policiesWe used seven real-life XACML policies collected fromthree different sources. Among these policies, codeA, codeB,codeC, codeD, continue-a, and continue-b are XACML policiesused in [11]; continue-a and continue-b are designed for areal-world web application that supports Conf. management;0400 800 1200 1600 2000 2400 2800 3200 3600 4000Number of RulesFig. 15: Memory size of XEngine onsynthetic XACML policiesProcessing time diff. (ms)Total Processing Time(ms)10 6 Sun PDPPDDTable10 410 210 01 2 3 4 5 6 7PolicyFig. 13: Total processing time for100,000 multi-valued requests onreal-life XACML policies14 x 105 Sun PDP−PDD12 Sun PDP−Table108642Number of Rules0400 800 1200 1600 2000 2400 2800 3200 3600 4000Fig. 16: Processing time difference betweenSun PDP and XEnginepluto is used in the ARCHON system (http://archon.cs.odu.edu/). We used the request-generation technique in [26] togenerate random requests. For each policy, we conducted twoexperiments to evaluate the processing time of single-valuedrequests and that of multi-valued requests respectively. In eachexperiment, we generated 100,000 random single-valued ormulti-valued requests to simulate a large volume of requests.For each multi-valued request, we assign two distinct valuesto the subject, two distinct values to the object, and one valueto the action.For each of the seven XACML policies, Fig. 11 shows thepreprocessing time of the policy, the memory size of XEngine,and the total processing time for the 100,000 single-valued ormulti-valued requests. Note that we use “PDD” to denote theXEngine using the decision diagram scheme, and “Table” todenote the XEngine using the forwarding table scheme. Forthe seven real-life XACML policies, on average, the memorysize of the PDD and the the forwarding table is about 14and 12 times less than the memory for storing the textualXACML policies, respectively. Fig. 12 and 13 show the totalprocessing time of 100,000 single-valued requests and thatof multi-valued requests respectively for both XEngine andSun PDP. Note that the vertical axes of Fig. 12 and 13 arein logarithmic scales. These experimental results show thatfor XACML policies of small sizes (with hundreds of rules),XEngine is one or two orders of magnitude faster than SunPDP. For single-valued requests, on average, the forwardingtable scheme and the PDD scheme are 116 and 76 timesfaster than Sun PDP. For multi-valued requests, on average,the forwarding table scheme and the PDD scheme are 25 and18 times faster than Sun PDP.From Fig. 11, 12 and 13, we observe that the forwardingtable scheme is faster than the PDD scheme, which isconsistent with our analysis in Section V. On average, theforwarding table scheme is 50% faster than the PDD schemefor single-valued requests; and the forwarding table scheme is36% faster than the PDD scheme for multi-valued requests.We also observe that XEngine’s processing time for multivaluedrequests is approximately four times more than that

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 13for single-valued requests. The reason is that for a multivaluedrequest, XEngine evaluates each decomposed singlevaluedrequest individually, and resolving decisions for thesingle-valued requests costs additional time. Recall that in ourexperiments, each multi-valued request corresponds to foursingle-valued requests according to our methods for generatingmulti-valued requests. Therefore, in XEngine, there is analmost linear correlation between the processing time of amulti-valued request and the number of single-valued requestsdecomposed from the multi-valued request. Furthermore, weobserve that the performance of Sun PDP for multi-valuedrequests is not highly dependent on the number of singlevaluedrequests decomposed from the multi-valued requests.This is not surprising, because Sun PDP compares each requestwith all the rules in the policy.B. Performance on Synthetic policiesIt is difficult to get a large number of real-life XACMLpolicies, as access control policies are often deemed confidentialfor security reasons. To further evaluate the performanceand scalability of XEngine, we generated random syntheticXACML policies of large sizes. We generate multi-layeredpolicies in a hierarchical fashion. A multi-layered policy hasa root policy set that includes multiple layers of policy setsand policies. Each policy has a sequence of rules. Each policyelement has a randomly selected combining algorithm. Eachrule holds randomly selected attribute id-value pairs from ourpredefined domain that linearly increases with the number ofrules. Single-valued requests and multi-valued requests aregenerated randomly in the same way as for real-life XACMLpolicies. In our experiments, we evaluated the impact of thepolicy size in terms of the number of rules and the impactof the policy structure in terms of the number of layers. Allsynthetic policies used in our experiments can be downloadedfrom the XEngine open source repository [1].Fig. 14 shows the preprocessing time versus the number ofrules in a three-layered policy for XEngine. We observe thatthere is an almost linear correlation between the preprocessingtime of XEngine and the number of rules, which demonstratesthat XEngine is scalable in the preprocessing phrase. Fig.15 shows the memory size of XEngine versus the numberof rules in a three-layered policy for XEngine. Similar asthe preprocessing time of XEngine, there is an almost linearcorrelation between the memory size of XEngine and thenumber of rules.Fig. 16 shows the difference between Sun PDP and XEnginefor the total processing time of 100,000 randomly generatedsingle-valued requests. Note that two lines in Fig. 16 are veryclose to each other. This figure shows that XEngine is orders ofmagnitude faster than Sun PDP and the performance differencegrows almost linearly with the number of rules in XACMLpolicies.Fig. 17 and 18 show the experimental results as a functionof the number of rules in a three-layered policy for processingsingle-valued requests and multi-valued requests, respectively.Fig. 19 and 21 show the experimental results as a functionof the number of layers for processing single-valued requestsin two three-layered policies, which consist of 1000 and 3000rules respectively. Fig. 20 and 22 show the evaluation resultsas a function of the number of layers for processing multivaluedrequests in two three-layered policies, which consist ofTotal Processing Time(ms)Sun PDP10 8PDDTable10 610 410 2Number of Rules400 800 1200 1600 2000 2400 2800 3200 3600 4000Fig. 17: Effect of number ofrules for single-valued requestsTotal Processing Time(ms)10 10 Sun PDPPDD10 8Table10 610 410 2Number of Layers1 2 3 4 5 6 7 8 9 10Fig. 19: Effect of numberof layers for single-valued requestsunder 1000 rulesTotal Processing Time(ms)10 10 Sun PDPPDD10 8Table10 610 410 2Number of Layers1 2 3 4 5 6 7 8 9 10Fig. 21: Effect of numberof layers for single-valued requestsunder 3000 rulesTotal Processing Time(ms)Sun PDP10 8PDDTable10 610 410 2Number of Rules400 800 1200 1600 2000 2400 2800 3200 3600 4000Fig. 18: Effect of number ofrules for multi-valued requestsTotal Processing Time(ms)10 10 Sun PDPPDD10 8Table10 610 410 2Number of Layers1 2 3 4 5 6 7 8 9 10Fig. 20: Effect of number oflayers for multi-valued requestsunder 1000 rulesTotal Processing Time(ms)10 10 Sun PDPPDD10 8Table10 610 410 2Number of Layers1 2 3 4 5 6 7 8 9 10Fig. 22: Effect of number oflayers for multi-valued requestsunder 3000 rules1000 and 3000 rules respectively. Note that the vertical axesof these six figures are in logarithmic scales.These figures demonstrate that XEngine is highly scalableand efficient in comparison with Sun PDP. For single-valuedrequests, under different numbers of rules, say 400, 2000,and 4000 rules in a three-layered policy, the forwarding tablescheme is 1381, 6910, 11894 times faster than Sun PDPrespectively, and the PDD scheme is 896, 4210, 7944 timesfaster than Sun PDP respectively. For multi-valued requests,under different numbers of rules, say 400, 2000, and 4000rules in a three-layered policy, the forwarding table schemeis 832, 4380, 7704 times faster than Sun PDP respectively,and the PDD scheme is 419, 2088, 3777 times faster thanSun PDP respectively. Our experimental results also show thatthe impact of the structure of XACML policies in terms ofthe number of layers on the performance of XACML policyevaluation is not remarkable. For XACML policies with 1000rules but with various number of layers, for single-valuedrequests, the forwarding table scheme is constantly about 4000times faster than Sun PDP, and the PDD scheme is constantlyabout 2500 times faster than Sun PDP. For XACML policieswith 1000 rules but with various number of layers, for multivaluedrequests, the forwarding table scheme is constantlyabout 2000 times faster than Sun PDP, and the PDD scheme isconstantly about 1000 times faster than Sun PDP. For XACMLpolicies with 3000 rules but with various number of layers,for single-valued requests, the forwarding table scheme isconstantly about 11000 times faster than Sun PDP, and thePDD scheme is constantly about 7000 times faster than Sun

IEEE TRANSACTIONS ON COMPUTERS, MANUSCRIPT ID XXXX 14PDP. For XACML policies with 3000 rules but with variousnumber of layers, for multi-valued requests, the forwardingtable scheme is constantly about 6000 times faster than SunPDP, and the PDD scheme is constantly about 3000 timesfaster than Sun PDP.VII. CONCLUSIONS AND KEY CONTRIBUTIONSThis paper addresses the significant need in policy-basedcomputing for fast policy evaluation. We make three keycontributions. First, we propose two fundamental approachesto fast policy evaluation, policy normalization and canonicalrepresentation, which promote and support the separation ofcorrectness and performance concerns for policy designers.Second, we present detailed algorithms for realizing ourapproaches for XACML polices. Third, we implemented ouralgorithms in XEngine and performed extensive comparisonwith Sun PDP. Our experimental results show that XEngineis orders of magnitude faster than Sun PDP and the performancedifference grows almost linearly with the number ofrules in an XACML policy. Although the majority of thispaper is devoted to XACML policy evaluation, our policynormalization and canonical representation approaches can beapplied to other policy languages and our XEngine algorithmsare helpful to design fast evaluation algorithms for otherrule-based policy languages as well. For example, we haveextended our XEngine algorithms to the Enterprise PrivacyAuthorization Language (EPAL) [25].REFERENCES[1] XEngine souce code. http://xacmlpdp.sourceforge.net/.[2] Sun PDP. http://sunxacml.sourceforge.net/, 2005.[3] IBM. Enterprise Privacy Authorization Language (EPAL). http://www.w3.org/Submission/2003/SUBM-EPAL-20031110/, 2003.[4] K. Borders, X. Zhao, and A. Prakash. CPOL: high-performance policy evaluation.In Proc. CCS, pages 147-157, 2005.[5] J. Crampton, W. Leung, and K. Beznosov. The secondary and approximateauthorization model and its application to bell-lapadula policies. In Proc. SACMAT,2006.[6] E. W. Dijkstra. Selected writings on Computing: A Personal Perspective. Springer-Verlag, 1982.[7] J. McLean. IEEE Symoposium on Security and Privacy, pages 2–7, 1988.[8] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman. Role-based accesscontrol models. IEEE Computer, 29(2):38–47, 1996[9] OASIS eXtensible Access Control Markup Language (XACML). http://www.oasisopen.org/committees/xacml/, 2007.[10] D. F. Ferraiolo, R. S. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli.Proposed NIST standard for role-based access control. ACM Transactions onInformation and System Security, 4(3):224–274, 2001.[11] K. Fisler, S. Krishnamurthi, L. Meyerovich, and M. Tschantz. Verification andchange impact analysis of access-control policies. In Proc. ICSE, pages 196–205,May 2005.[12] K. Frikken, M. Atallah, and J. Li. Attribute-based access control with hiddenpolicies and hidden credentials. IEEE Transactions on Computers, 55(10):1259–1270, 2006.[13] M. G. Gouda and A. X. Liu. Firewall design: consistency, completeness andcompactness. In Proc. ICDCS, pages 320–327, 2004.[14] M. G. Gouda and A. X. Liu. Structured firewall design. Computer NetworksJournal (Elsevier), 51(4):1106–1120, 2007.[15] S. Hada and M. Kudo. XML access control language: Provisional authorization forxml documents. http://www.trl.ibm.com/projects/xml/xacl/xacl-spec.html, 2000.[16] H. Hu and G. Ahn. Enabling verification and conformance testing for accesscontrol model. In Proc SACMAT, pages 195–204, 2008.[17] Karthick Jayaraman, Vijay Ganesh, Mahesh Tripunitara, Martin Rinard, and SteveChapin. Automatic Error Finding in Access-Control Policies. MIT Tech. Rep.MIT-CSAIL-TR-2010-022, 2010.[18] IBM. Enterprise privacy authorization language (EPAL). http://www.w3.org/Submission/2003/SUBM-EPAL-20031110/, 2003.[19] L. Kagal. Rei: A policy language for the me-centric project. Tech. Rep., HPLaboratories, 2002. http://www.hpl.hp.com/techreports/2002/HPL-2002-270.pdf.[20] L. Kagal, T. Finin, and A. Joshi. A policy language for a pervasive computingenvironment. In Proc. IEEE International Workshop on Policies for DistributedSystems and Networks, 2003.[21] V. Kolovski, J. Hendler, and B. Parsia. Analyzing web access control policies. InProc. WWW, pages 677–686, 2007.[22] N. Li and M. V. Tripunitara. Security analysis in role-based access control. ACMTransactions on Information and System Security, 9(4):391–420, 2006.[23] D. Lin, P. Rao, E. Bertino, N. Li, and J. Lobo. Policy decomposition forcollaborative access control. In Proc. SACMAT, pages 103–112, 2008.[24] A. X. Liu, F. Chen, J. Hwang, and T. Xie. XEngine: A fast and scalable xacmlpolicy evaluation engine. In Proc. SIGMETRICS, 2008.[25] Q. Wang, F. Chen, A. X. Liu, and Z. Qin. Towards high performance securitypolicy evaluation. Michigan State University, Tech. Rep. MSU-CSE-10-7, 2010.http://www.cse.msu.edu/ ∼ feichen/paper/EPAL tech.pdf.[26] E. Martin, T. Xie, and T. Yu. Defining and measuring policy coverage in testingaccess control policies. In Proc. ICICS, pages 139–158, 2006.[27] C. Ribeiro, A. Zquete, P. Ferreira, and P. Guedes. SPL: An acess control languagefor security policies with complex constraints. In NDSS, 2001.[28] R. S. Sandhu and P. Samarati. Access control: Principles and practice. IEEECommunications Magazine, 32(9):40–48, 1994.[29] S. D. Stoller, P. Yang, C. R. Ramakrishnan, and M. I. Gofman. Efficient policyanalysis for administrative role based access control. In Proc. CCS, pages 445 –455, 2007.[30] D. E. Taylor. Survey & taxonomy of packet classification techniques. ACMComputing Surveys, 37(3):238–275, 2005.[31] M. C. Tschantz and S. Krishnamurthi. Towards reasonability properties for accesscontrolpolicy languages. In Proc. SACMAT, 2006.[32] H. M. Vin. Navigating complexity through managed evolution. Sigmetrics (keynotespeech), 2008.[33] Q. Wei, J. Crampton, K. Beznosov, and M. Ripeanu. Authorization recycling inrbac systems. In Proc. SACMAT, 2008.[34] N. Zhang, M. Ryan, and D. P. Guelev. Synthesising verified access control systemsthrough model checking. Journal of Computer Security, 16(1), 2007.Alex X. Liu received his Ph.D. degree in computerscience from the University of Texas at Austin in2006. He is currently an assistant professor in theDepartment of Computer Science and Engineeringat Michigan State University. He received the IEEE& IFIP William C. Carter Award in 2004 and theNational Science Foundation CAREER Award in2009. His research interests focus on networking,security, and dependable systems.Fei Chen received the BS degree in Automationfrom Tsinghua University in 2005 and the MSdegree in Automation from Tsinghua Universityin 2007. He is currently a PhD student in theDepartment of Computer Science and Engineeringat Michigan State University. His research interestsinclude on networking, algorithms, and security.JeeHyun Hwang received the BS degree in computerscience from Korea University in Korea in2003 and the MS degree in computer science fromthe State University of New York in Stony Brook in2005. He is a PhD student in the department of computerscience at North Carolina State University. Heis a member of the Automated Software EngineeringResearch Group led by Dr. Tao Xie. His researchinterests include testing and verifying access controlpolicies.Tao Xie received the PhD degree from the Universityof Washington in 2005. He received the BSdegree from Fudan University in 1997 and the MSdegree from Peking University in 2000. He is anassistant professor in the Department of ComputerScience at North Carolina State University. Hisprimary research interest is software engineering,with an emphasis on automated software testing andmining software engineering data. He is a memberof the IEEE.