[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Delegation, Policy Administration, and Trust in XACML
Hi Anne, I'm having a problem to follow the exact trust chains and processing sequence in your write-up, and my somewhat unfamiliarity still with the xacml inner-workings doesn't help me... please bear with me... I do believe, though, that solving this "policy administration, delegation and trust" is the most important item we have on our list for the F2F... if we would just be able to make good progress on that in the coming week, I would consider our meeting a great success. Let me try to give you my follow-on perspective which is on a slightly higher level than yours: * clearly separate the access control admin policy from access control policy First of all, I think we should use a different definition of delegation when it concerns policy administration. I find it easier to differentiate "being allowed to do something" and "being allowed to administer the rights to do that something", if we treat them as completely separate, unrelated statements. One reason is that you could have subjects that are allowed to administer the right to do something for others, while they themselves are not allowed to do that same thing. Chadwick gave the example of the assignment of planes to pilots where you probably don't want to allow the admin to fly the plane themselves. Hopefully, that separation also makes it easier to reason about it. * every policy statement has an issuing admin The second observation is that we should be able to associate an issuer with every policy statement. I use the word policy statement to indicate an administrative unit of policy, which probably is a PolicySet or Policy, but probably not a Rule. This issuer information should identify a subject. The subject information should be similar/identical to the subject passed into the Request context: a collection of (validated) attribute assignments. I will use the term issuing-admin to indicate the subject information of the issuer of the policy statement. * access-policy statements are different from admin-policy statements As mentioned before, I would like to clearly distinguish access-policy statements from admin-policy statements. Not only from a conceptual point of view, but also because they seem to have different aspects. An access-policy statement would be equivalent to the once we deal with now in xacml 1.0. An admin-policy statement is different: it states certain Admins are allowed to administer the policy for certain Subjects, Resources, Actions under certain conditions. The "Admins" in this context are equivalent to the Subjects,Resources and Actions, because its purpose is for matching. * access-target and admin-target For that reason, I'd like to group Admins with Subjects,Resources and Actions into an AdminTarget. One could name the Target that we currently use in our access-policy statements an AccessTarget to make the distinction more clear. So access-policy statements have an access-target, while admin-policy statements have an admin-target. Either one of these policy statements includes an issuing-admin. To reiterate, the issuing-admin is different from the admins in the admin-target, because it represents a single subject while those in the admin-target are used for matching. For example, an admin-policy statement could express that any admin with a group membership of ACME-ADMINS is allowed to administer action=read on resource=abc for any subject. This admin-policy statement would permit an access-policy statement issued by an issuing-admin with name=john and group=ACME-ADMINS that states that subject=mary is allowed to action=read on resource=abc. * levels of delegated admin rights I also would like to use levels of delegated admin rights. The zero-level is the implicitly trusted admin, the "self", the bootstrap level, the one where the trust in the PDP is managed outside of the xacml world. If I understand it well, then this is the only one that we support in the current xacml model. The zero-level of delegation of admin rights would have admin-policy statements that identify combinations of Targets and Admins, where the admin-policy statement is asserted/issued by the issuing-admin "self". In other words, a zero-level admin-policy statement would say that the issuing-admin "self" allows certain Admins to administer the access-policy for certain Subjects and certain Resources and certain Actions when certain conditions evaluate to Permit. A first level of delegation of admin rights would have an admin-policy statement where a zero-level empowered admin would allow an other certain Admins to administer the access-policy for certain Subjects and certain Resources and certain Actions when certain conditions evaluate to Permit. * Use case example I tried to explain the detailed processing of a use case in a separate email... * implementation There are all kinds of good reasons to try to fit any working model as much as possible in the current xacml 1.0 framework as long as it doesn't skew the model too much. For a admin-policy decision query, i.e. a query to find out whether a certain admin is allowed to administer the access rights of certain Subjects/Resources/Actions, the admin-subject information could be represented by a Request/Subject with a specific attribute value of SubjectCategory=policy-admin. The Admins of the admin-target could be incorporated in the Target/Subjects/Subject with an SubjectCategory=policy-admin. This would allow one to match the admin-subject attribute info in the Request context with the Target/Admins matching conditions. One could implicitly infer from the presence of a Target/Subjects/Subject with SubjectCategory==issuing-admin, that this is an admin-policy statement and not an access-policy statement. We still need to add the (optional) issuing-admin info to a PolicySet or Policy. Maybe we should have an additional PolicyStatement element that could include either a single PolicySet or Policy with an issuing-admin and validity-time constraints. Even though I can see how we could potentially use the Request/Subject and Target/Subjects with SubjectCategory=issuing-admin, it very much feels like a kludge, because the admin is conceptually truly different from the subject... * Issues, questions, concerns ** incorporated time-validity of policy statements in standard processing Especially when policy-statements are asynchronously pushed with the request, the time-validity has to be considered. Should we just incorporate an optional valid-from/valid-until fields in every PolicySet and Policy? Maybe the PolicySet and Policy should always be embedded in an unsigned SAML-assertion-like body: PolicyStatement ** How to deal with a policyset that includes other policysets/policies that have a different issuing-admin either directly or by reference? The ambiguity and complexity are difficult to comprehend...can we exclude that? Can we define to have only one issuing admin on the outer PolicySet or single Policy, or the outer PolicyStatement? ---- Enough for now ... I'm confident that we will have some interesting discussions next week! Regards, Frank. ------------------------------------------------------------------------------- Anne Anderson wrote: > 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 -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]