xacml 2.0 wish list

[Frank Siebenlist <franks@mcs.anl.gov>]

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