Preliminary review of WS-XACML

["Rich.Levinson" <rich.levinson@oracle.com>]

At the last XACML TC mtg, Jun 5, I agreed to raise my concerns
about WS-XACML to the TC list about pushing XACML policy
expressions to the periphery in the sense that they would appear
within WS-Policy assertions.

In the process, I have reviewed the spec again and have a number
of detailed comments to make about it, but have not yet had the
time to assemble everything together in a cohesive fashion, so in
the interest of keeping things moving, I will provide a summary of
my findings here.

As a result of this recent review, I have revised my thinking considerably
about this spec. In particular, I believe in my early reviews of the 
material
I had underestimated the scope of what the spec is trying either explicitly
or implicitly to accomplish. At one level, I can now see it as a serious
attempt at a "grand unification theory" of XACML and WS-Policy.

The first major factor that the spec addresses is an abstraction of 
WS-Policy,
itself. In particular, by representing assertions as combinations of 
Requirements
and Capabilities, the spec makes explicit the structure of WS-Policy 
which is
somewhat lost in the extremely abbreviated assertion representations found
in specs such as WS-SecurityPolicy. (Note: there are background refs, which
include a representation of WS-SP using the same constructs used in 
WS-XACML,
which I have not reviewed yet, but does promise to be interesting.)

The 2nd major factor the spec addresses is the notion of vocabularies, 
where
a vocabulary is associated with a policy domain, such as authorization,
privacy, or system-specific policy domains. In each vocabulary is a 
mechanism
for expressing constraints on the variables within the vocabulary. The 
constraints,
themselves, are abstracted so that basically any policy domain can be mapped
into a XACML policy domain, and theoretically the client and server can
determine dynamically whether their respective Requirements and Capabilities
are mutually acceptable. Generally, the client does the evaluation of 
its own
assertions vs the assertions it obtains from the server's wsdl.

A 3rd major factor that is only lightly touched on is the notion that 
the "advertised"
or "published" policy (i.e. that which appears as assertions in 
WS-Policy) MUST
be a subset of the "internal" or enterprise policy used by the policy 
publisher
for policy evaluation. There is a brief section (10) that talks about 
"managing"
policies and how segments of internal policy might be tagged for 
external publication.

A 4th significant factor is the list of supported constraint functions 
in Appendix A.
These are clearly a subset of the more general xacml function set. Some 
information
needs to be elaborated as to where the lines are drawn between 
core-xacml and
ws-xacml functions and any significance there is to that boundary.

It becomes quickly apparent that when we model the whole situation we have
possibly 4 or 5 familiar actors involved in the overall process:

    - the service, itself, with its advertised wsdl
    - the client, with its own internal capabilities represented as 
assertions
    - the PEP, that intercepts the client request and is responsible for 
constructing
       a XACML authorization request based on the request and other 
available
       context.
    - the PDP, that processes the authorization request against its set 
of policies.
    - an admin entity that specifies the policy that is used by the PDP 
and the
       advertised policy that is published by the service.

This is a broader model than that which is envisioned in the original 
xacml core
spec, particularly the domain of advertised policy which until now has been
pretty much the exclusive domain of WS-Policy.

My basic conclusion is that the spec appears to be quite sound in 
concept and
detail. However, the breadth of its scope is such that a significant 
amount of
additional analysis is needed to determine if the abstractions are 
optimal for the
overall problem space being addressed or whether they carry the inherent
complexity and capabilities of xacml out to a space where a less complex
expression mechanism would be more appropriate.

It seems appropriate to me that the TC might want to spend some cycles
addressing the high level problem space that WS-XACML is addressing
and determine if we think this spec is worth promoting for the broad
purposes that it appears capable of addressing.

    Thanks,
    Rich