OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Preliminary review of WS-XACML


Rich,

I still dont understand why there is an interesting use-case for 
combining WS-Policy and XACML.

Why would an entity advertise its authorization policies using 
WS-Policy? An example would probably help folks like me who have a 
superficial
understanding of XACML.

- prateek
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]