Prateek, All,
Wasn't this issue opened up precisely because users had asked Hal that
it should be brought up to a higher level towards a standard because
they were using it? Correct me if I am wrong.
I cannot vouch for how many would want to use it since I am no expert on
WS-Policy, but if users are asking for it, I am in favour of making it
more than just a working draft.
There is one technical issue which needs to resolved: the recent changes
to xpaths in 3.0 means that it needs to be updated.
And, I don't understand one issue: when a service posts a privacy
requirement, how does the client become bound to the requirement? I sent
an email to Anne asking for clarification. It might be just that I have
misunderstood the proposal, or there is a mode of policy exchange which
I am not aware of.
Regards,
Erik
Prateek Mishra wrote:
> This seems an incredible amount of effort to reach some very modest
> goals...
>
> As Ramana points out, there are existing SecurityPolicy extensions and
> extension points that could support the required functionality
>
> I dont see the use-case where fine-grained Az needs to be advertised
> across enterprise or other boundaries; again, this seems an
> interesting project but I dont see a lot of folks asking for this...
>
> - prateek
>> Prateek,
>>
>> The use case is for advertising and matching more fine grained access
>> control and privacy policy requirements than provided by
>> WS-SecurityPolicy.
>>
>> For example, WS-SP can say "Use a SAML Assertion". With WS-XACML you
>> can say "access subject must have a Group attribute with the value of
>> Administrator".
>>
>> WS-XACML also provides a more fine grained matching mechanism which
>> is still syntactic in nature and does not require understanding of
>> the semantics of the individual elements of the policy.
>>
>> WS-XACML uses syntax from XACML as well as P3P to meet these
>> requirements. The use of XACML is not a goal, simply an
>> implementation choice.
>>
>> Hal
>>
>>
>>>
Original Message-----
>>> From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
>>> Sent: Thursday, June 19, 2008 9:26 AM
>>> To: Rich.Levinson
>>> Cc: xacml
>>> 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
>>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
> ---------------------------------------------------------------------
> 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