[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary review of WS-XACML
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]