MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Delegation, Policy Administration, and Trust in XACML
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
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]