Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of glen.mazza@verizon.net
 designates 206.46.252.42 as permitted sender)
Date: Wed, 07 May 2008 11:24:26 -0400
From: Glen Mazza <glen.mazza@verizon.net>
Subject: Re: Why SAAJOutInterceptor not added to WSS4JOutInterceptor in	2.0.6?
In-reply-to: <A724EFBF-7872-46EE-833F-A4AA8B540059@dushin.net>
To: dev@cxf.apache.org
Message-id: <1210173866.10894.44.camel@gmazza-desktop>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7bit
References: <1210143452.11083.3.camel@gmazza-desktop>
	<A724EFBF-7872-46EE-833F-A4AA8B540059@dushin.net>

I'm not so certain about that, because I'd like to someday have the
option of having interceptors for Sun's XWSS product[1] as well, so the
user can explicitly choose the security library--WSS4J or XWSS--he
wants.  (Spring Web Services offers people XWSS[2] so that may also be a
good option for us to provide.  I have not looked much into the
feasibility of this for CXF though.)  To that end, having interceptors
that explicitly reference the security library being used would be a
good idea IMO.

[BTW, Fred, as I understand WSS4J is a WS-Security 1.0 implementation
and not a WSS 1.1 implementation.  In terms of supporting SAML Token
Profiles (whether 1.0, 1.1, or even 2.0), however, I *believe* WSS4J can
handle all three types providing the client and service can handle those
profile versions--i.e., WS-Security just provides the framework for
sending SAML tokens regardless of the token's format, and both
WS-Security 1.0 and WS-Security 1.1 will work regardless of version of
tokens you are using.  Am I correct here?  If so, I would update your
web site to state that--to remove some FUD about using WSS4J--it just
says it supports SAML Tokens without specifying the SAML Token version.

I mention this because we are having concerns at work that XWSS is a
WS-1.1 implementation while WSS4J is "just" an 1.0 implementation,
although I suspect, at least in terms of supporting the various Token
Profiles, they are 98% if not 100% the same.]

Regards,
Glen  

[1] https://xwss.dev.java.net/ 
[2]
http://static.springframework.org/spring-ws/site/reference/html/security.html


2008-05-07 Fred Dushin wrote:
> +1
> 
> Ideally, we also need some custom spring beans and/or an API to hide  
> all the WSS4J-isms in client code, because (IMO) it's really  
> inappropriate to expose WSS4J, as a WS-Security provider at this  
> level.  (And I say this as a WSS4J committer).  WS-SecurityPolicy  
> would be an appropriate choice for an API, as we've discussed before.
> 
> -Fred
> 
> On May 7, 2008, at 2:57 AM, Glen Mazza wrote:
> 
> > Anyone know why WSSJOutInterceptor doesn't have the SAAJOutInterceptor
> > automatically added in 2.0.6 like it is already in 2.1?  I would  
> > like to
> > remove the instruction in our WS-Security guide which says it must
> > manually be added[1], since that is no longer the case at least with
> > 2.1.
> >
> > Thanks,
> > Glen
> >
> > [1]
> > http://cwiki.apache.org/confluence/display/CXF20DOC/WS-Security#WS-Security-ConfiguringtheWSS4JInterceptors
> >
> >
> > WSS4J Out Interceptor (2.0.6):
> > http://tinyurl.com/557una
> > --line 54 nothing.
> >
> > WSS4J In Interceptor (2.0.6):
> > http://tinyurl.com/6msczq
> > --line 75 SAAJInInterceptor is added
> >
> > WSS4J Out Interceptor (2.1):
> > http://tinyurl.com/6borcw
> > --line 61 SAAJOutInterceptor added
> >
> > WSS4JInInterceptor (2.1):
> > http://tinyurl.com/5klnud
> > --line 76 SAAJInInterceptor added.
> >
> >
> >
>