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