cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Security token processing without SAAJ dependency
Date Tue, 28 Sep 2010 20:58:35 GMT
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

View raw message