Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of ashakirin@talend.com
 designates 64.95.72.244 as permitted sender)
From: Andrei Shakirin <ashakirin@talend.com>
To: "dev@cxf.apache.org" <dev@cxf.apache.org>
CC: "dkulp@apache.org" <dkulp@apache.org>
Subject: RE: Checking of SOAP action in SoapActionInInterceptor: regression
 in proxy services
Thread-Topic: Checking of SOAP action in SoapActionInInterceptor: regression
 in proxy services
Thread-Index: 
 Ac7ghUKYISkLcV7qSBCYSohHugLauAA6BNaAAAIZhiAAMwMxgAAIZVmQ///eHoD//rinIA==
Date: Sat, 16 Nov 2013 18:21:20 +0000
Message-ID: <D225CD69196F3F4A9F4174B2FCA06F8811DB5DA6@S10BE002.SH10.lan>
References: <D225CD69196F3F4A9F4174B2FCA06F8811CEDC5D@S10BE002.SH10.lan>
 <CAF8t5XuYbKzZSy_Zd-X1F5nnVZxEGLrnD7cGByJV=r4-ZZtpsQ@mail.gmail.com>
 <D225CD69196F3F4A9F4174B2FCA06F8811CEE99A@S10BE002.SH10.lan>
 <AA5FB65F-F83B-45FD-9539-D0FC1960F651@apache.org>
 <D225CD69196F3F4A9F4174B2FCA06F8811CEEB27@S10BE002.SH10.lan>
 <893C4386-6991-44D2-AA01-856AAA62A697@apache.org>
In-Reply-To: <893C4386-6991-44D2-AA01-856AAA62A697@apache.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Dan,

> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Freitag, 15. November 2013 18:31
> To: dev@cxf.apache.org
> Subject: Re: Checking of SOAP action in SoapActionInInterceptor: regressi=
on
> in proxy services
>=20
>=20
> On Nov 15, 2013, at 12:04 PM, Andrei Shakirin <ashakirin@talend.com>
> wrote:
>=20
> > Hi Dan,
> >
> > Thanks for your analyse.
> >
> > 1. You are right, regarding WS-I Basic profile 1.2, additionally to R27=
44 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 yo=
ur
> 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 presen=
t
> 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.
>=20
> Interesting.   That would change the processing a bit.
>=20
>=20
> > 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 a=
nd
> SOAP 1.2?
>=20
> Kind of yes, kind of no.   With 1.2, there should not be a SOAPAction hea=
der,
> 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 Pr=
ofile 1.2.
This statement sounds also quite relax:
"Although the WSDL 1.1 Binding Extension for SOAP 1.2 describes how the act=
ion parameter of the Content-Type header field is set by the wsoap12:soapAc=
tion attribute of the wsoap12:operation element, there are implementations =
that include the action parameter in request messages even in cases where t=
he wsoap12:soapAction attribute does not appear in the wsoap12:operation th=
at 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 havin=
g it with empty value should not response with fault on Soap 1.2 requests c=
ontaining non-empty action attribute in Content-Type.
Do you interpret these statements in other way?

>=20
> > 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=3D"" an=
d
> >> 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?
>=20
> 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 operat=
ion,
> I'm guessing it does.   In that case, it should match what the wsdl provi=
des.
>=20
> If the gateway does NOT have a proper wsdl, then the incoming message
> should be mapped onto the synthetic "invoke" operation.   In that case, w=
e
> should be bypassing any soapAction checks entirely.
>=20
>=20

The second case - gateway has generic "invoke" operation and uses Dispatch =
interface to contact with the target service. Gateway is transparent for th=
e 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.

>=20
> > 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.
>=20
> 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 ser=
vice
> side having knowledge of the addressing.
>=20

That is correct, but this service is used as gateway and it cannot satisfy =
addressing of all possible clients.=20

My proposal:
1. Introduce special property to relax the checking of SOAPAction, lake Aki=
 proposed (like "allowNonMatchingToDefaultAction") and apply it only in cas=
e 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 P=
rofile 2.0 is correct. Than Soap 1.2 messages do not need allowNonMatchingA=
ctionToDefault  property.

If that is OK, I will implement the changes in context of https://issues.ap=
ache.org/jira/browse/CXF-5387 .

Regards,
Andrei.

>=20
> Dan
>=20
>=20
> >
> > Regards,
> > Andrei.
> >
> >> -----Original Message-----
> >> From: Daniel Kulp [mailto:dkulp@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 <ashakirin@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 so=
ap
> 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=3D""  ...>
> >>
> >> 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=3D"" an=
d
> >> 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 encrypte=
d, that
> info won't leak to
> >> the protocol layer).   Thus, if there is a wsam:Action attribute for t=
he
> 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:elakito@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 <ashakirin@talend.com>:
> >>>>> Hi,
> >>>>>
> >>>>> I have a bit regression under 2.7.7 because of changes in
> >>>>> SoapActionInInterceptor
> >>>>> (https://fisheye6.atlassian.com/changelog/cxf?cs=3D1368559 )
> >>>>>
> >>>>> 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 =3D boi.getExtensor(SoapOperationInfo.class);
> >>>>>           if (soi =3D=3D null || action.equals(soi.getAction())) {
> >>>>>               return;
> >>>>>           }
> >>>>>
> >>>>> Will be:
> >>>>>
> >>>>> SoapOperationInfo soi =3D boi.getExtensor(SoapOperationInfo.class);
> >>>>>           if ((soi =3D=3D null) ||
> >>>>> StringUtils.isEmpty(soi.getAction())
> >>>>> ||
> >>>> action.equals(soi.getAction())) {
> >>>>>               return;
> >>>>>           }
> >>>>>
> >>>>> WDYT?
> >>>>>
> >>>>> Regards,
> >>>>> Andrei.
> >>>>>
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> >> http://coders.talend.com
> >
>=20
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com