MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: xacml 2.0 wish list
Please find attached a summary of our requirements in the
same format as Anne used for her 2.0 work item list.
-Frank.
-------------------------------
1. Policy Authority Delegation
The ability to associate an authorization authority with a particular target
domain. A policy decision has to be evaluated whether a certain subject is
authorized by the PEP's higher level policy to provide authorization decisions
for a target domain.
Arguably, the current XACML spec has the implicit assumption that whoever we
send the authorization decision request to, is authorized to provide that
decision. By making this explicit, the boottrapping of what authorities to trust
is enabled through configuration, and it allows for the dynamic delgation of
rights in the form of true xacml policy.
This implies that there would be always (at least) two authorization decisions:
is the authority allowed to provide a decision for that target AND is the
requester allowed to invoke the operation.
There could be multiple of these authorization decisions for more complex
delegation scenarios.
Status: ???
2. Passing of explicit policy-set/policy/rule to the Authorization Decision
Query (Anne's item# 17 ?)
If a third party is empowered to decide on the authorization policy for a target
domain, it would allow for a push-mode of operation, where the requester would
present the PEP with an authorization assertion that would consist of xacml
policy statements.
The associated model is identical to the "Policy Authority Delegation", except
that the policy statements are presented in the authorization decision request.
This is probably the same as Anne's item# 17, but I was missing the reference to
policy delegation.
Status: ???
3. Attribute Issuer as Subject
The current attribute issuer type is a string. This restriction doesn't allow
one to easily point at an issuer as Subject, and it doesn't allow for any path
validation that goes more than one level deep. By allowing an attribute issuer
of type subject, one could cater for more complex use-cases that involve policy
delegation.
Status: ???
4. Standardize naming to specify policy rules for the requestor's authorization
policy
The current 1.0 spec seems to be somewhat silent on the requestor's side
authorization decision to see whether the requestor's policy allows the service
provider to service the request.
There are subject categories defined for access-subject, recipient-subject, and
intermediary-subject. I guess we could use the recipient-subject for the service
provider's subject, although I have the feeling that that was not its intension.
Maybe we should define/standardize a "provider-subject" to more clearly
distinguish the context where the access control decision is made.
Status: ???
5) XACML wsdl/porttype definition for <Request>/<Response> exchange
If we would use a centralized "authorization" service, it seems most natural to
abstract the decision request and response messages between the context handler
and the PDP into a wsdl/porttype definition.
Status:???
6) porttype/operations to ask for required attributes
This allows a requester to query the resource's authorization policy for the
required attributes for a Target such that it "knows" which one are missing and
would have to be retrieved and presented with any request.
If I'm not mistaken, Rebekah (@nasa) has implemented something like this in her
prototype.
Status: ???
7) Standardize primitives to express policy to reveal missing attributes
Quoting from the spec:
<quote>
"urn:oasis:names:tc:xacml:1.0:status:missing-attribute 2805
A PDP MAY choose not to return any <StatusDetail> information or MAY choose to
return a 2806 <StatusDetail> element containing one or more
xacml-context:Attribute> elements. If 2807 the PDP includes <AttributeValue>
elements in the <Attribute> element, then this indicates 2808
the acceptable values for that attribute. If no <AttributeValue> elements are
included, then 2809 this indicates the names of attributes that the PDP failed
to resolve during its evaluation. The list 2810 of attributes may be partial or
complete. There is no guarantee by the PDP that supplying the 2811
missing values or attributes will be sufficient to satisfy the policy.
</quote>
As mentioned, the returning of the missing attribute info is sensitive
information and should itself be subject to policy.
Status: Anne gave a possible solution of how to express this, but it would
require the standardization of names/operations for interoperability.
--
Frank Siebenlist franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]