MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: clarifications/questions for worklist items 26, 29 and 32
TC members,
I looked through the review and added some comments and clarifications.
Anne Anderson wrote:
> ...
> 26. Define policy reduction (partial evaluation) of a policy
>
> This was assigned to Frank as a Grid requirement, but at the
> SAML F2F, the working group determined there were existing ways
> to meet the Grid requirement.
>
> This is a candidate for closure unless someone wants to pick it
> up as useful for policy analysis, debugging, etc.
>
> Any takers? If not, this should not be on the agenda for the
> F2F.
>
> F2F: probably not.
The application that I see for this is that scheduler use case, where such a
scheduler has a need to combine and possibly reduce the requester and potential
service provider policies, and use that combined policy to determine if
potential scenarios are allowed. It is somewhat like wspl policy reduction, but
the scheduler may want to use a normal authorization query interface on the
combined policy to check for permission.
I can't really remember anymore what we decided at the SAML F2F about this...
> ...
> 29. Policy Authority Delegation
>
> We had a number of questions about this. It needs
> clarification. Issues:
>
> a. Define "domain". What does it correspond to?
> b. Could this be solved using a subject-domain or
> resource-domain attribute that the PEP should include in its
> Request, and that policies could match on?
>
> Wait for Frank to provide clarification before putting on F2F
> agenda.
>
> F2F: not until/unless Frank clarifies, but then possibly
I have the feeling that all the "delegation" related items will be solved when
we tackle the "right of a subject to administer policy for a certain target".
I reworded the description in item#29:
29. Policy Authority Delegation
The ability to express in a policy rule that a certain authorization
authority is allowed to administer access control policy for a certain target.
The evaluation for a certain target should probably yield "Indeterminate" or
"Not Applicable" (?) according to the local policy, it should yield "Permit" for
the right of an authorization authority to administer the policy for that
target, and either the authorization query to that authorization authority's PDP
should yield "Permit" or the evaluation of the pushed access control assertion
by that authorization authority should yield "Permit".
If the local policy yield either "Permit" or "Deny", the foreign authorization
authority doesn't have to be considered.(?)
TYPE: New functionality
STATUS: potential work item. Related item#1.
PROPOSAL: #1 in:
http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
CHAMPION: Frank Siebenlist
> ...
> 31. Attribute Issuer as Subject
>
> The attendees had a number of issues with this and feel the
> work item needs a more precise definition.
>
> a. Can this be solved using an XACML policy used by the PDP's
> context handler: Something like 'subject A is allowed to
> perform the "issue" certificate action on resource "subject
> B" or resources with attribute "name-domain" = B'
> b. Is this mainly an issue of aligning SAML and XACML syntax?
> c. Does an authentication chain really belong in the resource
> policy? Isn't it a separate policy?
>
> F2F: not unless clarified, then possibly
Need some more time to think about that one...
> 32. Standardize naming to specify rules for requestor's authz policy
>
> Again, clarification is needed.
>
> a. What entity is the "requestor"? The PEP? We don't usually
> think of a "requestor" having its own policy...
> b. Would this perhaps be a Grid Profile for Use of XACML?
> c. XACML already allows new SubjectCategory values to be
> defined simply by defining a new urn. Grid could define
> such a urn.
>
> F2F: not unless clarified, then possibly
This issue is not grid specific.
I understand the confusion around the naming.
Let me rewrite the item as follows:
32. Standardize naming to specify rules for requestor's authz policy
In a setting where a requester invokes certain operations of a service
provider, the convention for the target of the service provider's policy is
well defined: subject=requester, resource=service-provider, and action=operation.
However, when we consider the policy evaluation on the requester's side to check
whether an invocation on the service provider is allowed according to the
requester's policy, then is it less clear.
It is almost a mirror case, but if we take a convention where the "resource" is
the one protected by the policy, the we should equate subject=service-provider
and resource=requester with the same action=operation.
Unfortunately, if we also have to consider the possibility that the
service-provider can invoke an equivalent operation on the requester, then we
need an additional way to discriminate between these cases.
Maybe we can label the action with a category of "out-bound" (?).
TYPE: New functionality
STATUS: potential work item. Related item#1
PROPOSAL: #4 in
http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
CHAMPION: Frank Siebenlist
> ..
That's it for now.
-Frank.
--
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]