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

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

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]