cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Re: WSS4J implementation in CXF
Date Sun, 22 Jul 2007 00:54:27 GMT
Thanks, Dan.

There's an issue with the WSS4J interceptor, which I encountered when  
testing interop with WCF-3.0 WS-Sec 1.0 scenarios.

The issue resulted in my posting

http://issues.apache.org/jira/browse/CXF-790

but I'm told this behavior in CXF is by design, and hence (I suspect)  
may not be fixed in general, so we may need to modify the WSS4J  
interceptor, itself.

The problem boils down to the fact that the CXF runtime is copying  
headers that are sent from the client, and processed in the server on  
the inbound side, onto the outbound response context.  As a  
consequence, the client gets back headers it sent to the server.   
Some of these headers have things like key references (which in  
general the client can't resolve), or they reference protected parts  
which can't be resolved, because the wsu:id refers to elements in the  
input, not in the output.

The solution should probably be to remove any security headers from  
the message on the inbound side, after they have been processed,  
though this will have consequences for entities "downstream" from the  
WSS4J interceptor; this "in" interceptor is typically fairly close to  
the wire, so anyone who previously may have had an interest in these  
headers will be sunk.  (I know of no such entities, but I don't know  
all deployments.)  It's also sometimes difficult to figure out which  
headers to remove, since the return values from WSS4J may not be  
sufficiently informative.

There are some other issues with the checkReceiverResults operation,  
which our WSS4J in-interceptor inherits from WSHandler -- it's  
particularly sensitive to the ordering of elements, in cases where it  
probably doesn't need to be, and which introduces issues when trying  
to service requests from multiple toolkits, which all have their own  
peculiar ordering characteristics.  Something we're looking at, in  
WSS4J.

-Fred

On Jul 21, 2007, at 12:09 PM, Dan Diephouse wrote:

> Hiya,
> Thanks for reporting this. I've fixed this in SVN now. You can either
> compile from SVN or I can ping you once a new snapshot is uploaded  
> (probably
> monday).
>
> Cheers,
> - Dan
>
> On 7/21/07, Dale Peakall <d.peakall@oclcpica.org> wrote:
>>
>> No, this won't work.  I posted an e-mail on the dev list about this
>> yesterday.  The problem is the WSS4JInInterceptor doesn't accept a
>> Map<String, Object> only a Map<String, String> so there is no way  
>> to ref
>> an instantiated object.
>>
>> Julio Arias wrote:
>> > Hello -
>> >
>> > You could use something like this, but there is a bug in the
>> > WSS4JInInterceptor https://issues.apache.org/jira/browse/CXF-819  
>> that
>> > needs to be address beffore you can use a password callback by  
>> reference
>> >
>> > <jaxws:endpoint id="metadataService" address="/MetadataService"
>> > implementor="#metadataServiceImpl">
>> >         <jaxws:inInterceptors>
>> >             <bean
>> > class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
>> >             <bean
>> > class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
>> >                 <property name="properties">
>> >                     <map>
>> >                         <entry key="action" value="UsernameToken"/>
>> >                         <entry key="passwordType"  
>> value="PasswordText"/>
>> >                         <entry key="passwordCallbackRef"
>> > value-ref="authenticationCallbackHandler"/>
>> >                     </map>
>> >                 </property>
>> >             </bean>
>> >         </jaxws:inInterceptors>
>> >     </jaxws:endpoint>
>> >
>> > On Jul 20, 2007, at 2:32 PM, gdprao wrote:
>> >
>> >>
>> >> I have used spring and Xfire combination to configure WSS4J for  
>> user
>> >> authentication with WSS4JInHandler.  I would like to know  
>> whether it is
>> >> supported in CXF.  Appreciate if someone could help me out on  
>> this.  My
>> >> current configuration is as follows:
>> >>
>> >> <property name="inHandlers">
>> >>             <list>
>> >>                 <bean
>> >> class="org.codehaus.xfire.util.dom.DOMInHandler" />
>> >>                 <bean
>> >>
>> >> class="org.codehaus.xfire.security.wss4j.WSS4JInHandler">
>> >>                     <property name="properties">
>> >>                         <map>
>> >>                             <entry key="passwordCallbackRef">
>> >>                                 <bean
>> >>
>> >> class="com.mydomain.security.PasswordHandler">
>> >>                                 </bean>
>> >>                             </entry>
>> >>                             <entry key="action"  
>> value="UsernameToken"
>> />
>> >>                         </map>
>> >>                     </property>
>> >>
>> >>                 </bean>
>> >>                 <bean
>> >>
>> >> class="com.mydomain.security.ValidateUserTokenHandler" />
>> >>             </list>
>> >> </property>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/WSS4J-implementation-in-CXF- 
>> tf4119426.html#a11715464
>> >>
>> >> Sent from the cxf-user mailing list archive at Nabble.com.
>> >>
>> >
>> >
>> >
>> >
>> > Julio Arias
>> > Java Developer
>> > Roundbox Global : enterprise : technology : genius
>> >  
>> ---------------------------------------------------------------------
>> > Avenida 11 y Calle 7-9, Barrio Amón, San Jose, Costa Rica
>> > tel: 404.567.5000 ext. 2001 | cell: 11.506.849.5981
>> > email: julio.arias@rbxglobal.com | www.rbxglobal.com
>> >  
>> ---------------------------------------------------------------------
>> >
>> >
>>
>>
>
>
> -- 
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog


Mime
View raw message