administrative policies in xacml
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
![Page 2: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/2.jpg)
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.
![Page 3: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/3.jpg)
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
![Page 4: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/4.jpg)
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
![Page 5: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/5.jpg)
Administrative rights in XACML
• Two sources of policies– Trusted root policies– Policies with an ”external” issuer
• Two kinds of policies– Access rights– Administrative rights
![Page 6: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/6.jpg)
Regular XACML Right
<Policy>
<Target>
<Subject>Alice<Subject>
<Resource>Printing</Resource>
<Action>Access</Action>
</Target>
<Rule Effect=”Permit”>
<Target><AnyTarget/></Target>
</Rule>
</Policy>
![Page 7: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/7.jpg)
Request and response<Request> <Subject>Alice</Subject> <Resource>Printing</Resource> <Action>Access</Action></Request>
<Response> <Decision>Permit</Decision></Response>
![Page 8: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/8.jpg)
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
![Page 9: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/9.jpg)
Delegated access right<Policy> <Target> <Subject>Alice<Subject> <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
Empty delegation constraint indicates
access permission
![Page 10: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/10.jpg)
Request and response<Request> <Subject>Alice</Subject> <Resource>Printing</Resource> <Action>Access</Action> <Environment> <Attribute AttributeId="delegationChain"> <AttributeValue/> </Attribute> </Environment></Request>
<Response> <Decision>Permit</Decision> <Obligation ObligationId="authorize-issuer"> <AttributeAssignment AttributeId="subject-id“ >Bob</AttributeAssignment> </Obligation></Response>
Empty delegation chain indicates
access request
”The decision is not valid unless
the authority of Bob is verified.”
![Page 11: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/11.jpg)
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
![Page 12: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/12.jpg)
Example Administrative Right<Policy>
<Target>
<Subject>Employee<Subject>
<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>
Non-empty delegation constraint
indicates administrative right.
(For Bob.)
![Page 13: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/13.jpg)
Administrative Request<Request> <Subject>Alice</Subject> <Resource>Printing</Resource> <Action>Access</Action> <Environment> <Attribute AttributeId="delegationChain"> <AttributeValue> <Step>Bob<Step> <AttributeValue> </Attribute> </Environment></Request>
<Response> <Decision>Permit</Decision></Response>
Non-empty delegation chain
indicates an administrative request.
”Verify the authority of Bob to grant
this access.”
![Page 14: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/14.jpg)
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
![Page 15: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/15.jpg)
General Administrative Rights
Root: S1 S2 S3 S4 AP1
Issuer1: S5 S6 S7 AP2
Issuer2: S8 S9 AP3
Issuer3: S10 AP4
Issuer4: AP5
Access request: AR
![Page 16: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/16.jpg)
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.
![Page 17: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/17.jpg)
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.
![Page 18: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/18.jpg)
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.
![Page 19: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/19.jpg)
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
![Page 20: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/20.jpg)
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
![Page 21: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/21.jpg)
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.
![Page 22: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/22.jpg)
Access control data in our application
• Policy assertions
• Attribute assertions
• Attribute definition assertions
• Revocations
![Page 23: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/23.jpg)
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
![Page 24: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/24.jpg)
Architecture
Network
DKS-node
DKS-node
PDPResource/
PEP
Policy
Attribute assertion
Revocation
Access control data
PAP
![Page 25: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/25.jpg)
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.
![Page 26: Administrative Policies in XACML](https://reader036.vdocuments.us/reader036/viewer/2022070400/5681352a550346895d9c932c/html5/thumbnails/26.jpg)
The End
• More information:– http://www.sics.se/isl/pbr/xacml.html