Administrative Policies in
XACML
Erik Rissanen
[email protected]
Swedish Institute of Computer Science
Delegation
• Delegation is a mechanism for
administration
• With delegation we mean the granting of
rights for the purpose of administering
access control.
• We do not mean proxy delegation
between tiers in an application stack.
The need of administrative rights
• XACML has no way to specify who may change
policy
– Application writers need to reinvent the wheel
• Models for administrative rights are needed in
large systems
– Many administrators are needed
• Centralized administration can be a bottle neck
• Centralized administration can be a security risk
– Missunderstandings or too much power
Our approach
• We have made a simple implementation of
administrative rights in XACML.
• We did not modify the core of XACML
– Easier implementation and less intrusive
– But, some things are not as elegant as they could be.
• We participate in the ”real” work in the XACML
TC
• Note that the examples here are simplified!
– Important technical details are left out
Administrative rights in XACML
• Two sources of policies
– Trusted root policies
– Policies with an ”external” issuer
• Two kinds of policies
– Access rights
– Administrative rights
Regular XACML Right
<Policy>
<Target>
<Subject>Alice<Subject>
<Resource>Printing</Resource>
<Action>Access</Action>
</Target>
<Rule Effect=”Permit”>
<Target><AnyTarget/></Target>
</Rule>
</Policy>
Request and response
<Request>
<Subject>Alice</Subject>
<Resource>Printing</Resource>
<Action>Access</Action>
</Request>
<Response>
<Decision>Permit</Decision>
</Response>
Delegated access right
• Looks like a regular XACML access right
– Except it contains a condition that matches
only access requests (in contrast to
administrative requests)
• Is in some way associated with an issuer
– A digital signature for instance
• Is rewritten to contain an obligation to
verify the right to issue the policy
Delegated access right
<Policy>
Empty delegation constraint
<Target>
<Subject>Alice<Subject>
access permission
<Resource>Printing</Resource>
<Action>Access</Action>
</Target>
<Rule Effect=”Permit”>
<Target><AnyTarget/></Target>
<Condition FunctionId="delegationMatch">
<AttributeValue DataType="delegationConstraint"/>
<EnvironmentAttributeDesignator
AttributeId="delegationChain"/>
</Condition>
</Rule>
<Obligation ObligationId="authorize-issuer” FulfillOn="Permit">
<AttributeAssignment AttributeId="subject-id”
>bob</AttributeAssignment>
</Obligation>
</Policy>
Bob is the issuer
indicates
Request and response
<Request>
<Subject>Alice</Subject>
<Resource>Printing</Resource>
<Action>Access</Action>
<Environment>
<Attribute AttributeId="delegationChain">
<AttributeValue/>
</Attribute>
Empty delegation
</Environment>
</Request>
access request
<Response>
<Decision>Permit</Decision>
<Obligation ObligationId="authorize-issuer">
<AttributeAssignment AttributeId="subject-id“
>Bob</AttributeAssignment>
</Obligation>
</Response>
”The decision
chain indicates
is not valid unless
the authority of Bob is verified.”
Simple Administrative Right
• The right to create access rights
• Two parts
– Access permission
• The scope of the access rights that are allowed in
the end
– Administrative subject
• This is the person/people who may create policies
• In the form of a condition that will match an
administrative access request
Example Administrative Right
<Policy>
Non-empty delegation constraint
<Target>
indicates administrative right.
<Subject>Employee<Subject>
(For Bob.)
<Resource>Printing</Resource>
<Action>Access</Action>
</Target>
<Rule Effect=”Permit”>
<Target><AnyTarget/></Target>
<Condition FunctionId="delegationMatch">
<AttributeValue DataType="delegationConstraint">
<Step>Bob</Step>
</AttributeValue>
<EnvironmentAttributeDesignator AttributeId="delegationChain"/>
</Condition>
</Rule>
</Policy>
Administrative Request
<Request>
<Subject>Alice</Subject>
<Resource>Printing</Resource>
<Action>Access</Action>
<Environment>
<Attribute AttributeId="delegationChain">
<AttributeValue>
<Step>Bob<Step>
<AttributeValue>
</Attribute>
</Environment>
Non-empty
</Request>
<Response>
<Decision>Permit</Decision>
</Response>
delegation chain
indicates an administrative request.
”Verify the authority of Bob to grant
this access.”
General Administrative Right
• The right to create policies
• Two parts
– Access permission
• The scope of the access permissions that are
allowed in the end
– Delegation constraint
• Specifies all permitted chains of delegation in the
form of a pattern that is compared with the chain of
delegation in an administrative request
• Depending on the condition, it may allow the
creation of other administrative rights
General Administrative Rights
Root: S1 S2 S3
Issuer1: S5 S6
Issuer2:
S8
Issuer3:
Issuer4:
Access request:
S4
S7
S9
S10
AP1
AP2
AP3
AP4
AP5
AR
Policy processing
• The PDP owner can insert any policy into the
PDP
– These root policies specify which other policies may
be created and by whom
• External policies are rewritten to contain the
verify issuer obligation
• The rewritten policies are collected into the PDP
– We use a single policy set in our application.
• The PDP owner needs to define the policy
combining algorithm
– We use permit-overrides.
Request processing
• Starts with an almost regular XACML access request:
– Except an extra environment condition with an empty delegation
chain
• Is evaluated against the policies
– Special combining algorithm collects all the obligations of
delegated access permissions
• The context handler has to repeat the request for each
obligation until a permit is received
– The issuer is added to the environment delegation chain. This
indicates an administrative request.
– For repeated requests the chain grows longer with each new
issuer.
Optimization of evaluation
• The current approach requires repeated access
requests to verify administrative authority
• If rights would be directly comparable, the
verification could be done ahead of the access.
– No need for repeated requests.
– But also not possible to combine rights from multiple
sources into a single policy.
– Also would probably limit the form of policies
significantly.
Combining algorithms
• Any combining algorithm can be used
within a delegated policy
• When policies from multiple sources are
collected, the ”PDP owner” must specify
which policy combining algorithm to use
Policy Sets
• Delegated policies could be Policy sets
– Rewritten in the same way
– However, Policies are enough for us
• I haven’t thought about policy references
yet
Deny
• We do not use deny effects in our
application
• Deny should work
• However,
– Some policy combining algorithms may not
make sense in a delegated setting.
• For instance: The order of policies that are
externally issued and collected into a policy set
may be unpredictable.
Access control data in our
application
•
•
•
•
Policy assertions
Attribute assertions
Attribute definition assertions
Revocations
Distribution of data
• Data is distributed in a P2P-network, DKS
• A PDP subscribes to all access control
data it needs.
• The PDP starts from a resource id
– Fetches the resource attributes
– Fetches the policies on those attributes
– Fetches the issuer attributes
• End user attributes are fetched from the
network or uploaded by the user
Architecture
Network
Access control data
DKS-node
DKS-node
Policy
Attribute assertion
Revocation
PAP
PDP
Resource/
PEP
Main open issues
• Difficult for people to understand dependencies?
– Descriptive text in policies?
– Limit policies to a comparable form?
– Perhaps application semantics are enough?
• Replacement of administrators
– When an administrative right is removed from an administrator,
other policies fall as well. This may not be desirable.
– Issue instants of policies are perhaps not trusted.
– History of issuer attributes would be needed.
• Implementation with obligations is not elegant
– Work in progress at the XACML TC
• I haven’t thought about all features of XACML yet.
The End
• More information:
– http://www.sics.se/isl/pbr/xacml.html