cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ulhas Bhole(IONA)" <ulhas.bh...@iona.com>
Subject Re: WSS4J implementation in CXF
Date Tue, 24 Jul 2007 10:51:54 GMT
Hi Fred,

I was involved in Header support stuff so I am looking into CXF--790.

One alternative I am trying to see if it can be fixed in general with
some kind of marking for application specific headers and CXF headers
and filtering them while copying into JAX-WS responseContext  or
WebServiceContext so that only application specific headers can be sent
to application layer and it won't contain any internal CXF headers.

Regards,

Ulhas Bhole

Fred Dushin wrote:
> 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

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
View raw message