[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Delegation, Policy Administration, and Trust in XACML
Some additional comments on the ideas presented in the previous email: * implementation I now believe that we should not overload the Subjects with that SubjectCategory=policy-admin to indicate that we're dealing with a admin-subject. Note that we would use it to find those policyset/policy/rule that match the particular admin-subject that we have in the request context that is allowed to administer the Subjects/Resources/Actions target. The issue is that "The <Subjects> element SHALL contains a disjunctive sequence of <Subject> elements." This would imply that we can not add the matching on the admin-subject as just another "Subject"... which feels counterintuitive. If there is no match on the admin-subject, then there is no match for the target: it should be part of a conjunctive sequence, and therefor on the same level as Subjects/Resources/Actions If we would define a Target/Admins element, then we could us a default value for when it is not present, in analogy to the anySubject. Except that an "anyAdmin" would not be correct: it should be more like a "noAdmin" or "nonApplicableAdmin". This would allow us to use the equivalent formats as we have now: if there is no Target/Admins component, it will be a access-policy statement, while if it is present, it will be a admin-policy statement. Even the issuing-admin could be added to the Target by transforming the assignment into a trivial matching as Tim's wspl has taught us. So an issuing-admin with "name=john" would be transformed in a Target/IssungAdmin element which includes a match on "Request/IssuingAdmin/name==john. We could again define a default value for the case where there is no Target/IssuingAdmin element present, and again, a analogous value of "anyIssuingAdmin" would not work: the default should be "self". Any policy statement without an explicit issuing-admin would have been issued by self, which is pretty much how it works now. Regards, Frank. Frank Siebenlist wrote: > 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]