Approaches to generalization of XACML
New challenges for access control
27th April 2005
Tim Moses
Overview
• Rule taxonomy
• Distributed authorship
• XACML v2.0 evaluation
• Limitations
• Sample application
• Proposed solution
© Copyright Entrust, Inc. 2005
2
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
© Copyright Entrust, Inc. 2005
3
Rule taxonomy
Rule: The combination of a premise and a conclusion
Conclusion
is an
action
Rules
Reaction rules
Authorization
rules
Action is
permit | deny
Transformation rules
Business
rules
Action is a
procedure
Derivation rules
Facts
Queries
Source: RuleML
© Copyright Entrust, Inc. 2005
4
XACML v2.0
Transforms attributes into a decision and obligations
PDP
Attributes
2
Decision request
(Premise)
rule
rule
rule
3
Decision response
(Conclusion)
1
Access request
4
Access request
Decision,
Obligations
PEP
PDP – Policy Decision Point
PEP – Policy Enforcement Point
© Copyright Entrust, Inc. 2005
5
PEP fulfills obligations
5
Distributed authorship and combining
algorithms
• 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
© Copyright Entrust, Inc. 2005
6
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>
© Copyright Entrust, Inc. 2005
7
Transform attributes to decision
<Policy RuleCombiningAlgId = “deny-overrides”>
2
1
<Rule Effect=“Permit”>
… Attributes
</Rule>
<Rule Effect=“Permit”>
… Attributes
</Rule>
<Obligations>
<Obligation FulfillOn=“Permit”>
imperative
</Obligation>
<Obligation FulfillOn=“Deny”>
imperative
</Obligation>
</Obligations>
</Policy>
© Copyright Entrust, Inc. 2005
4
3
f
Decision
5
8
Transform attributes to obligations
<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>
f
6
Decision
7
f
8
© Copyright Entrust, Inc. 2005
Obligations
9
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
© Copyright Entrust, Inc. 2005
10
Sample application (message gateway)
PDP
Attributes
© Copyright Entrust, Inc. 2005
Imperatives
3
Response (Conclusion)
2
Request (Premise)
1
message
rule
rule
rule
4
Message
Gateway
(PEP)
proceed | reject |
delete | quarantine |
audit | reconsider |
scan & resubmit
11
Proposed solution
• 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
© Copyright Entrust, Inc. 2005
12
Solution
1
<Policy RuleCombiningAlgId = “prohibit-overrides”>
<Rule>
… Attributes
2
<Conclusions>
<TrueConclusion>
imperative
</TrueConclusion>
3
</Conclusions>
</Rule>
<Rule>
… Attributes
<Conclusions>
<FalseConclusion>
imperative
</FalseConclusion>
</Conclusions>
</Rule>
</Policy>
© Copyright Entrust, Inc. 2005
4
f
5
Conclusions
including
Decision
13
Example
<Conclusions>
Imperative
<TrueConclusion>
<Do uri=“SendOriginalToRFC822Name”>
<AttributeAssignment AttributeId = “Address”>
<AttributeValue DataType = “rfc822Name”>
[email protected]
</AttributeValue>
</AttributeAssignment>
Imperative
</Do>
<DoNot uri=“SendOriginalToSubjectCategory”>
<AttributeAssignment AttributeId = “SubjectCategory”>
<AttributeValue DataType = “string”>
recipient
</AttributeValue>
</AttributeAssignment>
</DoNot>
</TrueConclusion>
</Conclusions>
© Copyright Entrust, Inc. 2005
14
Combining algorithms
• 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
© Copyright Entrust, Inc. 2005
15
Conclusions
• 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
© Copyright Entrust, Inc. 2005
16