You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Al Le <al...@gmx.de> on 2013/08/10 21:56:31 UTC
Implementation of STSClient
Hello.
Why is the class STSClient (org.apache.cxf.ws.security.trust.STSClient)
and its companion class AbstractSTSClient implemented "by hand" and not
e.g. using JAX-WS? The WSDL of the web service in question is available
(it's part of WS-Trust spec). So why create the request and read the
response "by hand" instead of using a typed interface to it?
AL
Re: Implementation of STSClient
Posted by Colm O hEigeartaigh <co...@apache.org>.
The creation of the STSClient code was before my time at CXF and so I can
only guess at the reasons. The main reason I suspect that it was
implemented the way it was, is that the WS-Trust spec imposes almost no
restrictions on the structure of the requests, and hence working from types
generated from a WSDL would largely be meaningless. For example, a
"request" is defined as:
<xs:complexType name='AbstractRequestSecurityTokenType' >
<xs:sequence>
<xs:any namespace='##any' processContents='lax' minOccurs='0'
maxOccurs='unbounded' />
</xs:sequence>
<xs:attribute name='Context' type='xs:anyURI' use='optional' />
<xs:anyAttribute namespace='##other' processContents='lax' />
</xs:complexType>
A secondary reason might have been to support the WS-MEX protocol.
Colm.
On Tue, Aug 13, 2013 at 9:15 AM, Christian Schneider <
chris@die-schneider.net> wrote:
> Good question. I also wondered about this when I saw the code the first
> time.
>
> Christian
>
> Am 10.08.2013 21:56, schrieb Al Le:
>
> Hello.
>>
>> Why is the class STSClient (org.apache.cxf.ws.security.**trust.STSClient)
>> and its companion class AbstractSTSClient implemented "by hand" and not
>> e.g. using JAX-WS? The WSDL of the web service in question is available
>> (it's part of WS-Trust spec). So why create the request and read the
>> response "by hand" instead of using a typed interface to it?
>>
>> AL
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Implementation of STSClient
Posted by Christian Schneider <ch...@die-schneider.net>.
Good question. I also wondered about this when I saw the code the first
time.
Christian
Am 10.08.2013 21:56, schrieb Al Le:
> Hello.
>
> Why is the class STSClient
> (org.apache.cxf.ws.security.trust.STSClient) and its companion class
> AbstractSTSClient implemented "by hand" and not e.g. using JAX-WS? The
> WSDL of the web service in question is available (it's part of
> WS-Trust spec). So why create the request and read the response "by
> hand" instead of using a typed interface to it?
>
> AL
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Implementation of STSClient
Posted by Al Le <al...@gmx.de>.
Hello Colm and Dan.
Thank you for the explanations! That sound reasonable indeed.
AL
Re: Implementation of STSClient
Posted by Daniel Kulp <dk...@apache.org>.
There were several reasons:
1) When the STSClient was first developed, we wanted it to work on Java5 with just the simple frontend. AKA: JAX-WS isn't available.
2) Supporting different namespaces - we need to support both WS-Trust 1.0 ("http://schemas.xmlsoap.org/ws/2005/02/trust") and WS-Trust 1.3 ("http://docs.oasis-open.org/ws-sx/ws-trust/200512"). I didn't want to have separate generated STSClients and objects and such for each. We likely COULD use the transformation feature now to map from one to the other, but that wasn't available at the time.
3) As Colm mentioned, the WSDL/Schema pretty much sucks with a lot of xsd:any things. Thus, you would end up with a bunch of "instanceof" and casts and such anyway.
4) We NEED to make sure the various security tokens remain as a DOM with ALL the elements and text and attributes intact. JAXB parsing has a tendency to discard things like white spaces and moves namespace declarations around and such. Things like Signed SAML tokens would have their signatures broken if that happened. I've logged some issues with JAXB around some of this and SOME of those have been fixed, but I don't think all of them have.
Number 4 and number 2 were really the main drivers though.
Dan
On Aug 10, 2013, at 3:56 PM, Al Le <al...@gmx.de> wrote:
> Hello.
>
> Why is the class STSClient (org.apache.cxf.ws.security.trust.STSClient) and its companion class AbstractSTSClient implemented "by hand" and not e.g. using JAX-WS? The WSDL of the web service in question is available (it's part of WS-Trust spec). So why create the request and read the response "by hand" instead of using a typed interface to it?
>
> AL
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com