Administrative Policies in XACML

1. Administrative Policies in XACML Erik Rissanen mirty@sics.se Swedish Institute of Computer Science

2. 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.

3. 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

4. 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

5. Administrative rights in XACML • Two sources of policies • Trusted root policies • Policies with an ”external” issuer • Two kinds of policies • Access rights • Administrative rights

6. Regular XACML Right <Policy> <Target> <Subject>Alice<Subject> <Resource>Printing</Resource> <Action>Access</Action> </Target> <Rule Effect=”Permit”> <Target><AnyTarget/></Target> </Rule> </Policy>

7. Request and response <Request> <Subject>Alice</Subject> <Resource>Printing</Resource> <Action>Access</Action> </Request> <Response> <Decision>Permit</Decision> </Response>

8. 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

9. 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> Empty delegation constraint indicates access permission Bob is the issuer

10. 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.”

11. 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

12. Example Administrative Right Non-empty delegation constraint indicates administrative right. (For Bob.) <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>

13. 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.”

14. 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

15. 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

16. 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.

17. 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.

18. 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.

19. 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

20. 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

21. 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.

22. Access control data in our application • Policy assertions • Attribute assertions • Attribute definition assertions • Revocations

23. 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

24. Architecture

25. 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.

26. The End • More information: • http://www.sics.se/isl/pbr/xacml.html