Approaches to generalization of XACML New challenges for access control 27 th April 2005 Tim Moses.

Approaches to generalization of XACMLNew challenges for access control27th April 2005Tim Moses

© Copyright Entrust, Inc. 2005 2

• Rule taxonomy

• Distributed authorship

• XACML v2.0 evaluation

• Limitations

• Sample application

• Proposed solution

Overview


Proposition

• Organizations have a variety of applications for a rule expression language

• There are advantages to using a common language

• XACML v2.0 was designed for expressing authorization rules

• Generalization would allow XACML to serve a broader range of applications


Rule taxonomy

Conclusion is an

action Rules

Reaction rules Transformation rules

Derivation rules

Facts Queries

Authorizationrules

Businessrules

Action is aprocedure

Action ispermit | deny

Rule: The combination of a premise and a conclusion

Source: RuleML


XACML v2.0

rulerule

PDP

PEP

Decision request(Premise)

Decision response(Conclusion)

32

Access request1

Access request

5

Attributes

Decision, Obligations

rule

Transforms attributes into a decision and obligations

PEP fulfills obligations

4

PDP – Policy Decision PointPEP – Policy Enforcement Point


• PDP may evaluate multiple rules

• Applicable rules may have conflicting conclusions

• PDP must return a single consistent conclusion

• Solution:-– Define an algorithm for combining conclusions

Distributed authorship and combining algorithms


Sample XACML v2.0<Policy RuleCombiningAlgId = “deny-overrides”> <Rule Effect=“Permit”> … Attributes </Rule> <Rule Effect=“Permit”> … Attributes </Rule> <Obligations> <Obligation FulfillOn=“Permit”> imperative </Obligation> <Obligation FulfillOn=“Deny”> imperative </Obligation> </Obligations></Policy>


Transform attributes to decision<Policy RuleCombiningAlgId = “deny-overrides”>

<Rule Effect=“Permit”>

… Attributes

</Rule>


… Attributes

</Rule>

<Obligations>

<Obligation FulfillOn=“Permit”>

imperative

</Obligation>

<Obligation FulfillOn=“Deny”>

imperative

</Obligation>

</Obligations>

</Policy>

Decision

f1

2

3

5

4


Transform attributes to obligations<Policy RuleCombiningAlgId = “deny-overrides”>


… Attributes

</Rule>


… Attributes

</Rule>

<Obligations>

<Obligation FulfillOn=“Permit”>

imperative

</Obligation>

<Obligation FulfillOn=“Deny”>

imperative

</Obligation>

</Obligations>

</Policy>

Decision

f

fObligations

6

7

8


Limitations

• XACML’s “Effect” is specific to a Boolean conclusion

• There is no way to resolve conflicts between obligations

• Obligation combining is not defined by the combining algorithm

• There is a need to express prohibitions, as well as imperatives

• There is a need to express sequences of imperatives

• Solutions are constrained by the need to combine conclusions, in order to support distributed authorship


• Eliminate the “Effect” attribute

• Add a <Conclusions> element to the <Rule>, <Policy> and <PolicySet> elements

• Define separate <…Conclusion> elements for the “True”, “False”, “Indeterminate” and “NotApplicable” results

• Treat “Decision” as an imperative

Proposed solution


Solution<Policy RuleCombiningAlgId = “prohibit-overrides”>

<Rule>

… Attributes

<Conclusions>

<TrueConclusion>

imperative

</TrueConclusion>

</Conclusions>

</Rule>

<Rule>

… Attributes

<Conclusions>

<FalseConclusion>

imperative

</FalseConclusion>

</Conclusions>

</Rule>

</Policy>

f

ConclusionsincludingDecision

1

3

5

4

2


Example<Conclusions>

<TrueConclusion> <Do uri=“SendOriginalToRFC822Name”> <AttributeAssignment AttributeId = “Address”> <AttributeValue DataType = “rfc822Name”> [email protected] </AttributeValue> </AttributeAssignment> </Do> <DoNot uri=“SendOriginalToSubjectCategory”> <AttributeAssignment AttributeId = “SubjectCategory”> <AttributeValue DataType = “string”> recipient </AttributeValue> </AttributeAssignment> </DoNot> </TrueConclusion> </Conclusions>

Imperative

Imperative


• Prohibit-overrides– If an action is prohibited by one conclusion, then it is prohibited, even if

another conclusion permits it– Duplicate instances of an imperative may be eliminated– If the PEP does nothing unless explicitly instructed, then prohibitions may be

eliminated

Combining algorithms


• Organizations need a common language for expressing their authorization rules AND their business rules

• XACML v2.0 attempts to provide support for “business rules” through its <Obligations> element

• This solution is inadequate

• An alternative is proposed

Conclusions

Approaches to generalization of XACML New challenges for access control 27 th April 2005 Tim Moses.

Documents

Transcript of Approaches to generalization of XACML New challenges for access control 27 th April 2005 Tim Moses.