[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Delegation, Policy Administration, and Trust in XACML
Here is a perspective on delegation and how it fits into XACML. I think this helps clarify the requirements for handling policies about policies (policy administration policies), as well as what it takes to support delegation (one subject who is allowed to do something can delegate to another subject the permission to do that something). 1) The XACML PDP currently is completely independent of the authentication layer used to establish trust in policies and attributes. A PDP is assumed to be configured with some set of trusted authorities, and only attributes and policies from those authorities are trusted. It is possible and appropriate to have the authentication layer use its own XACML policy to control its own actions. For example, an XACML policy used by the authentication layer might say: Subjects X, Y, and Z can issue Attributes for AttributeIds A, B, and C. Subjects L and M can issue Policies. In these policies, the "action" is "issue", and the resource is an AttributeId (or "any Attribute") or a Policy[Set]Id (or "any policy"). 2) There is no way currently for an XACML Request Context to affect the policies used by the PDP. We support "intermediary-subject" as a Subject Category, so policies can place conditions on who the intermediaries are, but there is no way for a subject who is currently identified as an "access subject" in a policy to make a request to the PDP that will add a new "access subject" where the original subject is now an "intermediary subject". The important point is that, currently, there is no way for information in a Request Context to affect the actions of the PDP or its authentication layer directly. A PDP does not "understand" any action or resource attributes, so does not "understand" that permission to, for example, "issue" X means the PDP's authentication layer should accept X. We need to decide whether there will be some distinguished set of Request Context actions that an XACML PDP will "understand" and act on. We might define a "issue" action as follows: Request Context: Subject: S Resource: Subject: S' Resource: R Policy: P [optional] Action: "issue" where "R" is a set of PolicyIds, PolicySetIds, AttributeIds, "anyPolicy", or "anyAttribute". When the PDP encounters the "issue" action in a Request Context, it performs the following actions: 1) Verify that the authentication layer already allows S to issue anything in the set R. If not, return "Deny". 2) Instruct the authentication layer to add S' as trusted to issue anything in the set R [subject to the XACML policy P, if supplied]. Return "permit". Another "PDP-understood" action might be "delegate", but I think this is harder to define. The following is a possible approach. When the Action in a Request Context is "delegate", then the Resource in the Request Context would specifies a delegatee subject, a delegated resource, a delegated action, and an optional Condition on the delegation. The PDP would first verify that the requester is allowed to perform the delegated action on the delegated resource. It would then verify that the delegatee subject is not explicitly denied performing the delegated action on the delegated resource. If either of these tests fails, the PDP returns "deny". If none of the tests fails, the PDP would augment (using deny-overrides) its current top-level PolicySet with a new Policy having: with one "permit" Rule Target Subject is the delegatee subject Target Resource is the delegated Resource Target Action is the delegated Action Condition is the delegation condition, if any. Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]