Hi Dan,
> -----Original Message-----
> From: Daniel Kulp [mailto:dk...@apache.org]
> Sent: Freitag, 15. November 2013 18:31
> To: dev@cxf.apache.org
> Subject: Re: Checking of SOAP action in SoapActionInInterceptor: regression
> in proxy services
>
>
> On Nov 15, 2013, at 12:04 PM, Andrei Shakirin <ashaki...@talend.com>
> wrote:
>
> > Hi Dan,
> >
> > Thanks for your analyse.
> >
> > 1. You are right, regarding WS-I Basic profile 1.2, additionally to R2744
> > the
> R2745 mandates empty value in SOAPAction if WSA-action is not using and
> action attribute in WSDL is empty or not present. Samples also confirm your
> statement.
> >
> > Anyway, seems that WS-I Basic profile 2.0 relax SOAPAction requirement:
> >
> > R2744 If the action parameter on the HTTP Content-Type header is present
> in a MESSAGE, its value MUST be equal to the value of the soapAction
> attribute of the corresponding wsoap12:operation in the WSDL description, if
> this attribute is present and not empty.
>
> Interesting. That would change the processing a bit.
>
>
> > Unlike SOAP 1.1, SOAP 1.2 HTTP binding does not use the SOAPAction HTTP
> header in the HTTP Request messages. Relying on the presence of
> SOAPAction HTTP header or the value of SOAPAction HTTP header may result
> in interoperability problems.
> >
> > R2760 A RECEIVER MUST NOT rely on the presence of SOAPAction HTTP
> > header to correctly process the message. HTTP-TRANSPORT
> NOT_TESTABLE
> > R2761 A SENDER SHOULD NOT include the SOAPAction HTTP header.
> > HTTP-TRANSPORT TESTABLE BP1761
> >
> > Does that means that we should validate that differently for SOAP 1.1 and
> SOAP 1.2?
>
> Kind of yes, kind of no. With 1.2, there should not be a SOAPAction header,
> but there should be an action attribute on the Content-Type header that
> should be validated the same.
Exactly, currently action attribute of Content-Type header is used for Soap 1.2
(see SoapActionInInterceptor.getSoapAction()).
But my interpretation of WS-I Basic Profile 2.0 R2744 is that the message
action must be equal to WSDL action attribute ONLY if attribute present and is
not empty. This seems to be a bit different in regards to WS-I Basic Profile
1.2.
This statement sounds also quite relax:
"Although the WSDL 1.1 Binding Extension for SOAP 1.2 describes how the action
parameter of the Content-Type header field is set by the wsoap12:soapAction
attribute of the wsoap12:operation element, there are implementations that
include the action parameter in request messages even in cases where the
wsoap12:soapAction attribute does not appear in the wsoap12:operation that
describes these requests. Note that, in some of these cases, the action
parameter might have an empty string ("") value."
>From my interpretation, service having no action attribute in WSDL or having
>it with empty value should not response with fault on Soap 1.2 requests
>containing non-empty action attribute in Content-Type.
Do you interpret these statements in other way?
>
> > 2.
> >> For the Java first non-provider case, if the action isn't specified,
> >> it defaults to "" which then outputs in the wsdl as soapAction="" and
> >> thus it would be required to be that on the wire.
> >
> > But this prevents the using of proxy or gateway services processing
> requests from different clients and redirecting them to target services.
> > The clients produce correct SOAPAction for target service, but gateway
> service has no chance even to receive the request because of SOAPAction
> mismatch.
> > Do you see any solution for that?
>
> Kind of depends. Does the gateway have the actual WSDL that the client
> should be using? If it's matching the incoming request to a wsdl operation,
> I'm guessing it does. In that case, it should match what the wsdl provides.
>
> If the gateway does NOT have a proper wsdl, then the incoming message
> should be mapped onto the synthetic "invoke" operation. In that case, we
> should be bypassing any soapAction checks entirely.
>
>
The second case - gateway has generic "invoke" operation and uses Dispatch
interface to contact with the target service. Gateway is transparent for the
client. Client "think" that he is communicating with target service, but
request will be proceed by gateway/proxy at first. That looks as
man-in-the-middle attack, is used in some use cases anyway.
>
> > 3.
> >> So you would need to check the WSDL that CXF is trying to use and that
> SOAP UI is using.
> > The WSDL is generated by CXF. By default SoapUI sends correct empty
> SOAPAction. Error occurs only if I activate default WS-A action in SoapUI and
> it also inserts the same value into SOAPAction.
>
> Yea, per spec the SOAPAction and WSA:Action have to be equal. However,
> per Basic Profile, in that case, the WSDL should reflect that via the
> wasm:Action. It sounds like you're enabling addressing without the service
> side having knowledge of the addressing.
>
That is correct, but this service is used as gateway and it cannot satisfy
addressing of all possible clients.
My proposal:
1. Introduce special property to relax the checking of SOAPAction, lake Aki
proposed (like "allowNonMatchingToDefaultAction") and apply it only in case if
WSDL contract has no action attribute or has empty one. Property must be
commented as breaking WS-I Basic Profile 1.2 compatibility.
2. Change validation of Soap 1.2 action, if my interpretation of WS-Basic
Profile 2.0 is correct. Than Soap 1.2 messages do not need
allowNonMatchingActionToDefault property.
If that is OK, I will implement the changes in context of
https://issues.apache.org/jira/browse/CXF-5387 .
Regards,
Andrei.
>
> Dan
>
>
> >
> > Regards,
> > Andrei.
> >
> >> -----Original Message-----
> >> From: Daniel Kulp [mailto:dk...@apache.org]
> >> Sent: Freitag, 15. November 2013 16:32
> >> To: dev@cxf.apache.org; Andrei Shakirin
> >> Subject: Re: Checking of SOAP action in SoapActionInInterceptor:
> >> regression in proxy services
> >>
> >>
> >> On Nov 14, 2013, at 5:38 PM, Andrei Shakirin <ashaki...@talend.com>
> wrote:
> >>
> >>> Hi Aki,
> >>>
> >>> Sure, I can introduce the new option here.
> >>> However the question is still valid: does it make sense to force
> >>> ONLY empty
> >> SOAPAction in requests by default, if interface method hasn't action
> >> attribute in @WebMethod annotation (OperationInfo contains empty
> >> action in the map)?
> >>> If user doesn't care about soap action in interfaces at all (it
> >>> could be the case of using the Provider<> API for example) is it
> >>> correct to prohibit
> >> all requests with non-empty soap actions?
> >>> Currently it looks a bit strange in case of using proxy implementing
> >> Provider<> API: even if SOAP action has reasonable value created by
> >> SoapUI (wsdl target namespace/operation name), CXF responses with
> >> error "The given SOAPAction XXX does not match an operation", because
> >> OperationInfo has empty action value, that doesn't match to request soap
> action.
> >>> The same request works fine with CXF 2.5.x and 2.6.x ... I find
> >>> that not
> >> intuitive.
> >>
> >> Well, if the WSDL that is being used by the Provider based service
> >> (providing a WSDL is used) has something like:
> >>
> >> <soap:operation soapAction="" ...>
> >>
> >> then it definitely should throw a fault if the operation comes in
> >> with anything other than "". The WSDL contract says it should be the
> >> empty string, not something else.
> >>
> >> For the Java first non-provider case, if the action isn't specified,
> >> it defaults to "" which then outputs in the wsdl as soapAction="" and
> >> thus it would be required to be that on the wire.
> >>
> >> Note that the WS-I Basic Profile states:
> >>
> >> R2745 When the wsa:Action header is absent from an ENVELOPE, an HTTP
> >> Request MESSAGE MUST contain a SOAPAction HTTP header field with a
> >> quoted empty string value if, in the corresponding WSDL description,
> >> the soapAction attribute of the wsoap11:operation is either not
> >> present, or present with an empty string as its value.
> >>
> >> So you would need to check the WSDL that CXF is trying to use and
> >> that SOAP UI is using.
> >>
> >>
> >> THAT said, if WS-Addressing is used, things change a little bit. The
> >> WSA action SOAP header SHOULD match the SOAPAction HTTP header.
> >> However, the profile does allow for the SOAPAction to be "" while the
> >> action header is a the full URI (in case the Action header is encrypted,
> >> that
> info won't leak to
> >> the protocol layer). Thus, if there is a wsam:Action attribute for the
> input, it
> >> SHOULD exactly match the soapAction attribute on the operation.
> >> (Rule
> >> R2901 or WSI-BP)
> >>
> >>
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >>>
> >>> WDYT?
> >>>
> >>> Regards,
> >>> Andrei.
> >>>
> >>>> -----Original Message-----
> >>>> From: Aki Yoshida [mailto:elak...@gmail.com]
> >>>> Sent: Donnerstag, 14. November 2013 15:12
> >>>> To: dev@cxf.apache.org
> >>>> Subject: Re: Checking of SOAP action in SoapActionInInterceptor:
> >>>> regression in proxy services
> >>>>
> >>>> i think introducing an explicit option like "allowWrongAction" (or
> >>>> something that sound better :-) to turn off this action
> >>>> equality-check is better than using an empty string to
> >>>> automatically turn off the check. Or we can define a special
> >>>> matchAny kind of action
> >> that can be used in opinfo?
> >>>>
> >>>> 2013/11/13 Andrei Shakirin <ashaki...@talend.com>:
> >>>>> Hi,
> >>>>>
> >>>>> I have a bit regression under 2.7.7 because of changes in
> >>>>> SoapActionInInterceptor
> >>>>> (https://fisheye6.atlassian.com/changelog/cxf?cs=1368559 )
> >>>>>
> >>>>> SoapActionInInterceptor requires that the SOAPAction exactly
> >>>>> matches to
> >>>> the service operation.
> >>>>> The problem is that there are some scenarios where the proxies
> >>>>> using
> >>>> Provider<> API process requests from different clients with any
> >> SOAPAction.
> >>>>>
> >>>>> If you don't see security issue in that, I would ignore the check
> >>>>> if
> >>>> SoapOperationInfo action has default SOAP action (configured as
> >>>> empty in
> >>>> SoapBindingConfiguration):
> >>>>>
> >>>>> Instead:
> >>>>> SoapOperationInfo soi = boi.getExtensor(SoapOperationInfo.class);
> >>>>> if (soi == null || action.equals(soi.getAction())) {
> >>>>> return;
> >>>>> }
> >>>>>
> >>>>> Will be:
> >>>>>
> >>>>> SoapOperationInfo soi = boi.getExtensor(SoapOperationInfo.class);
> >>>>> if ((soi == null) ||
> >>>>> StringUtils.isEmpty(soi.getAction())
> >>>>> ||
> >>>> action.equals(soi.getAction())) {
> >>>>> return;
> >>>>> }
> >>>>>
> >>>>> WDYT?
> >>>>>
> >>>>> Regards,
> >>>>> Andrei.
> >>>>>
> >>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org - http://dankulp.com/blog Talend Community Coder -
> >> http://coders.talend.com
> >
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com
