RE: NEW ISSUE: HTTP/HTTPS conflict resolution between policy assertion and WSDL

+1


Jong
BEA Systems. 

-----Original Message-----
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Sverdlov, Yakov
Sent: Saturday, July 29, 2006 9:39 AM
To: Asir Vedamuthu; Maryann Hondo; Yalcinalp, Umit
Cc: Christopher B Ferris; public-ws-policy@w3.org; Toufic Boubez
Subject: RE: NEW ISSUE: HTTP/HTTPS conflict resolution between policy assertion and WSDL


All,

I agree with Asir that 'Policy takes precedence' does not help in this particular SSL handshake example. However, we may add a reverse proxy between requester and web service, and this will make "HTTPS policy over HTTP endpoint" a meaningful conflict.  

I think that, as a higher level spec, WS-Policy (and its existing and future derivatives, such as WS-SecurityPolicy) should take precedence over lower level specs (HTTP, HTTPS, WSDL, SOAP) wherever possible. The Primer should provide some guidance in this direction.

Regards,

Yakov Sverdlov
CA

-----Original Message-----
From: Asir Vedamuthu [mailto:asirveda@microsoft.com]
Sent: Friday, July 28, 2006 7:45 PM
To: Maryann Hondo; Yalcinalp, Umit
Cc: Christopher B Ferris; public-ws-policy@w3.org; Toufic Boubez; Sverdlov, Yakov
Subject: RE: NEW ISSUE: HTTP/HTTPS conflict resolution between policy assertion and WSDL

Let's say a requestor initiates an SSL handshake with a non-SSL endpoint. What happens? The handshake will fail. 'Policy takes precedence' does not help.

Service metadata can describe different parts of a Web service. Some of these descriptions may contradict. Say, a WSDL binding description requires SOAP over HTTP and the endpoint address uses a non-HTTP/HTTPS scheme. Does the port or binding description take precedence? Regardless, precedence does not help.

In the specific case described below, the contradiction involves multiple specs (HTTP, HTTPS, WSDL, WS-Policy and WS-SecurityPolicy). A smart metadata tool may reason and flag this.

The primer is a good vehicle to highlight that some of these descriptions may contradict.

Regards,
 
Asir S Vedamuthu
Microsoft Corporation

________________________________________
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Maryann Hondo
Sent: Wednesday, July 26, 2006 2:11 AM
To: Yalcinalp, Umit
Cc: Christopher B Ferris; public-ws-policy@w3.org; public-ws-policy-request@w3.org; Toufic Boubez; Sverdlov, Yakov
Subject: RE: NEW ISSUE: HTTP/HTTPS conflict resolution between policy assertion and WSDL


All, 

I agree with Toufic that for the specific WSDL binding case with HTTP/HTTPS in WS-Policy attachment, we can state that policy takes precedence over the WSDL. 

 But  I also agree with Umit, that  this is also an area where the primer can offer guidance. 

Policy authors ( like RM) have to do the domain decomposition. In the case of RM, maybe the authors did not take into account transport agnostic, and transport specific capabilities. 

I believe the security domain did attempt to address this. So the primer can provdide guidance and examples of how domain authors can chose to express the capabilities of their particular domain. 

And if there are new models for attachment ( beyond WSDL) then the precedence can be stated normatively in the WS-PolicyAttachment document. 

Maryann 

"Yalcinalp, Umit" <umit.yalcinalp@sap.com> Sent by: public-ws-policy-request@w3.org
07/19/2006 08:57 PM
To
Christopher B Ferris/Waltham/IBM@IBMUS, "Sverdlov, Yakov" <Yakov.Sverdlov@ca.com> cc <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>, "Toufic Boubez" <tboubez@layer7tech.com> Subject
RE: NEW ISSUE: HTTP/HTTPS conflict resolution between policy assertion and  WSDL







Hi Chris, 
  
I am not sure which "spec" you are referring to. If I am following this thread correctly, the intent here is to provide some guidelines to deal with this situation and if we decide to deal with it in a non-normative manner, I see this as a potential item to be included into the primer. I see no harm pointing out the pitfalls to users. 
  
Thanks, 
  
--umit 
  
________________________________________
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher B Ferris
Sent: Tuesday, Jul 18, 2006 7:56 AM
To: Sverdlov, Yakov
Cc: public-ws-policy@w3.org; public-ws-policy-request@w3.org; Toufic Boubez
Subject: RE: NEW ISSUE: HTTP/HTTPS conflict resolution between policy assertion and WSDL


I agree that this is out of scope. There are plenty of work-arounds for situations such as that cited (e.g. use HTTP redirect to the secure URI). 

IMO, this is a profiling issue, not something that the spec need be concerned with. 

Cheers, 

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295 

public-ws-policy-request@w3.org wrote on 07/18/2006 10:46:49 AM:

> I agree that the policy assertion takes precedence. My understanding 
> is that the same "canned" policy, which requires HTTPS, may 
> potentially be attached to different WSDLs at the management stage, 
> and if WSDL port for a particular WS uses HTTP, the policy will be 
> appropriately enforced at runtime i.e. rejecting the request.
>   
> I think this is a legitimate conflict, and it has to do with the 
> policy management and enforcement which is out of scope. May be the 
> Attachment Primer should provide some guidance in regard to possible 
> policy attachment outcomes during the enforcement phase for two 
> categories 'conflict' and 'ambiguity':
>   
> 1. Conflict between the policy assertion and WSDL (not limited to the 
> transport) 2. Ambiguity as described by Ashok for the MQ transport 
> scenario, which the Primer should recommend to avoid
>   
> Regards,
> Yakov Sverdlov
> CA
>   
>   
> 
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy- 
> request@w3.org] On Behalf Of Toufic Boubez
> Sent: Tuesday, July 18, 2006 10:27 AM
> To: Toufic Boubez; public-ws-policy@w3.org
> Subject: RE: NEW ISSUE: HTTP/HTTPS conflict resolution between policy 
> assertion and WSDL
>   
> More information: 
>   
> Justification - This issue was raised by the WS-Policy interop in 
> April 2006 in Germany.
>   
> Reference - 
> http://www.w3.org/2006/07/13-ws-policy-minutes.html#action32
>   
> Toufic Boubez, Ph.D.
> Chief Technology Officer
>  
> LAYER 7 TECHNOLOGIES / Advancing the application network.
> 604.681.9377 x310 (w)   604.288.7970 (m) tboubez@layer7tech.com (e)  
> www.layer7tech.com (w)
>   
> 
> From: public-ws-policy-request@w3.org on behalf of Toufic Boubez
> Sent: Mon 7/17/2006 10:02 PM
> To: public-ws-policy@w3.org
> Subject: NEW ISSUE: HTTP/HTTPS conflict resolution between policy 
> assertion and WSDL Title - HTTP/HTTPS conflict resolution between 
> policy assertion and WSDL
>   
> Description - If the security policy assertion requires the use of 
> HTTPS transport level security and WSDL port address uses HTTP scheme, 
> what is the best practice guidance for requestors?
>   
> Target - WS-Policy Attachment 1.5? Primer? 
>   
> Proposal - Not sure if I have an absolute proposal, but I'll get the 
> ball rolling: I propose that if there is a conflict, that since 
> presumably the policy authors are a better authority as to what 
> policies should exist for a service, whereas the WSDL might have been 
> automatically generated by a tool or a developer, the policy assertion 
> takes precedence.
>   
> Toufic Boubez, Ph.D.
> Chief Technology Officer
>  
> LAYER 7 TECHNOLOGIES / Advancing the application network.
> 604.681.9377 x310 (w)   604.288.7970 (m) tboubez@layer7tech.com (e)  
> www.layer7tech.com (w)


_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Received on Monday, 31 July 2006 08:06:58 UTC