Re: [xacml] Preliminary review of WS-XACML

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

Hi Prateek,

Briefly for the moment, but more later:

Use case:

    Administrator designs policy to protect resource that
    requires attributes: x,y,z

    x,y are available internally or from user authentication
    context/ldap etc, however, attr z must be obtained
    by user and accompanied by request.

    Therefore, admin wants to advertise "z" and include
    it somehow in ws-policy so user client can work w
    user to obtain z before submitting request.

That's all I can say in this short time.

    Thanks,
    Rich


Prateek Mishra wrote:
> 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