OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]