MHonArc v2.5.0b2 -->
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]