cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: Security token processing without SAAJ dependency
Date Fri, 08 Oct 2010 11:23:55 GMT
On Tue, Sep 28, 2010 at 22:58, Daniel Kulp <> wrote:
> On Tuesday 28 September 2010 3:00:27 pm Oliver Wulff wrote:
>> Hi all
>> CXF delegates all the incoming security token processing down to WSS4J
>> which requires the SAAJ interceptor due to the requirement of a dom tree.
>> If you don't use a SAML token as a signing or encryption token
>> (holder-of-key) you can validate the soap header and its signature without
>> creating a dom tree or only for the saml token itself.
>> If you use a username token you don't have to pass it down to WSS4J.
>> Further, the STS client could be used to validate the UsernameToken
>> against an STS.
>> If you use a binary security token which is not used as a signing or
>> encryption token (x509) then you can process this in a steaming manner.
>> What are your thoughts and ideas on that?
> Colm and I have tossed some ideas around this a bit in regards to WSS4J, just
> never had time to really dig in.
> First, to clarify, CXF always parses the headers into a DOM.  Thus, any stuff
> that does processing on the headers can feel free to use the DOM.   Passing
> the UsernameToken into WSS4J is really a non-issue for this.   We do have
> optimizations in place for the UsernameToken ws-secpol stuff that does bypass
> the SAAJ stuff for UsernameToken, but it processes it by calling the WSS4J
> handler directly.  We definitely could do this for other cases as well.
> HOWEVER, the better option, IMO is to get a better callback and element lookup
> mechanism in place in WSS4J.   We can pass the "header only" DOM that we have
> to WSS4J and if it NEEDS the body, it can call back to us where we can build
> the rest of the SAAJ/DOM model.  (actually, longer term, going some sort of
> stax route could be cool as well)    That would simplify much of the "special
> cases that don't need to load the body" to basically being automatic.  We
> wouldn't need to write code around any of the special cases.   This would take
> care of the INCOMING message.
> Thus, the work around the special cases and such is for the outbound chain,
> but that's not nearly as much work.  An interceptor can add custom things to
> the security header via our normal List<Header> stuff and the security things
> can augment it later if they get triggered.
> --
> Daniel Kulp

The other alternative is to leave WSS4J unchanged and to let the SAAJ
implementation materialize the different parts of the object model on
demand. I have a working PoC that does this. It currently implements
an alternative SAAJInInterceptor that provides the following features:

* It always puts a SOAPMessage into the Message object, but the
SOAPPart (including the SOAP headers) is only instantiated on demand
when the SOAPMessage is accessed.
* The content of the SOAPBody is only materialized when is it actually
accessed. In addition, deferred parsing and building of the nodes is
supported for this part of the message. This means that WSS4J can
start processing the body of the message before it has been received
* If the body has not been accessed, the StAX events are passed
through unchanged (e.g. to the interceptor that does the databinding
stuff). If the body has been accessed through the SAAJ API, then a
W3CDOMStreamReader is used to regenerate the StAX events.

All this is completely transparent for the interceptors further down the chain.

Of course, this is impossible to achieve using a standard SAAJ
implementation. Therefore the interceptor uses an alternative SAAJ
implementation which I have written as part of a larger project called
DDOM [1]. The implementation is still incomplete, but to give you an
idea about its current status:

* The underlying DOM implementation successfully passes the W3C DOM1
and DOM2 test suites, except for features not relevant to SOAP
processing (such as DTD information, entity references, etc.). It also
successfully passes the most important parts of the DOM3 test suite.
* When configured as SAAJ implementation in the CXF build (without the
custom SAAJInInterceptor), it passes all unit tests up to the systests
(It seems that this is primarily due to the fact that some of the
systests use SAAJ to compose test messages).
* When configured as DOM implementation in the WSS4J build, it passes
all unit tests except some of the tests related to SAML (because
OpenSAML expects to get schema support from the DOM implementation
available though JAXP).
* I tested the implementation successfully with the scenarios
developed by Dennis Sosnoski [2] (both by simply configuring DDOM as
SAAJ implementation as well as using my alternative

The code for the custom SAAJInInterceptor is available here:

Note that besides the limitations mentioned above, there are currently
some features missing in this SAAJInInterceptor implementation that
needs to be mentioned, namely processing of SOAP faults and the
ability to access attachments through the SAAJ API.

Some preconfigured CXF (2.3.0) clients and services (containing code
from Dennis' article) are available here:

Note that for the moment, they still use Sun's SAAJ implementation for
outgoing messages. Therefore the interesting things happen in the
response processing on the client side.

I did some initial performance tests with the scenarios developed by
Dennis and the results suggest that my SAAJ implementation performs
slightly better than the one from Sun, resulting in a few percent
points improvement in the "sign" and "signencr" scenarios. Note that
the features of the custom SAAJInInterceptor are not relevant here
because the body is accessed anyway in these scenarios. I think that
the improvement primarily results from a reduced memory footprint.
Maybe Dennis could volunteer as an "independent" performance tester to
confirm this?

BTW, while doing some profiling, I noticed that in the "signencr"
scenario, CXF suffers from a flaw in Santuario's code, namely,
which does some highly inefficient stuff. I think that by doing that
part of the processing in a smarter way, it may be possible to perform
better than Metro in the small-response case and to increase the gap
with respect to Metro in the large-response case.


PS: As noted between the lines by Daniel, optimizing the security
processing for outgoing messages is much more difficult, at least in
CXF. In principle, the Axis2 architecture would allow to achieve this
more easily, but before this can be leveraged, there are some other
performance issues in Axis2/Rampart that need to be fixed...


View raw message