Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Date: Sat, 21 Jul 2007 20:54:27 -0400
From: Fred Dushin <fred@dushin.net>
Subject: Re: WSS4J implementation in CXF
In-reply-to: <7b774c950707210909i7ad5d712qb5048e2c1f7456b5@mail.gmail.com>
To: cxf-user@incubator.apache.org, cxf-dev@incubator.apache.org
Message-id: <D30B93F0-016C-4B7A-B930-587AC6669CFA@dushin.net>
MIME-version: 1.0 (Apple Message framework v752.3)
Content-type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Content-transfer-encoding: quoted-printable
References: <11715464.post@talk.nabble.com>
 <79E4E200-87C3-449D-9549-C1630E9978A9@rbxglobal.com>
 <46A1AC41.90702@oclcpica.org>
 <7b774c950707210909i7ad5d712qb5048e2c1f7456b5@mail.gmail.com>

Thanks, Dan.

There's an issue with the WSS4J interceptor, which I encountered when =20=

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) =20=

may not be fixed in general, so we may need to modify the WSS4J =20
interceptor, itself.

The problem boils down to the fact that the CXF runtime is copying =20
headers that are sent from the client, and processed in the server on =20=

the inbound side, onto the outbound response context.  As a =20
consequence, the client gets back headers it sent to the server.  =20
Some of these headers have things like key references (which in =20
general the client can't resolve), or they reference protected parts =20
which can't be resolved, because the wsu:id refers to elements in the =20=

input, not in the output.

The solution should probably be to remove any security headers from =20
the message on the inbound side, after they have been processed, =20
though this will have consequences for entities "downstream" from the =20=

WSS4J interceptor; this "in" interceptor is typically fairly close to =20=

the wire, so anyone who previously may have had an interest in these =20
headers will be sunk.  (I know of no such entities, but I don't know =20
all deployments.)  It's also sometimes difficult to figure out which =20
headers to remove, since the return values from WSS4J may not be =20
sufficiently informative.

There are some other issues with the checkReceiverResults operation, =20
which our WSS4J in-interceptor inherits from WSHandler -- it's =20
particularly sensitive to the ordering of elements, in cases where it =20=

probably doesn't need to be, and which introduces issues when trying =20
to service requests from multiple toolkits, which all have their own =20
peculiar ordering characteristics.  Something we're looking at, in =20
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 =20
> (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 =20
>> 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 =20=

>> that
>> > needs to be address beffore you can use a password callback by =20
>> reference
>> >
>> > <jaxws:endpoint id=3D"metadataService" address=3D"/MetadataService"
>> > implementor=3D"#metadataServiceImpl">
>> >         <jaxws:inInterceptors>
>> >             <bean
>> > class=3D"org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
>> >             <bean
>> > class=3D"org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
>> >                 <property name=3D"properties">
>> >                     <map>
>> >                         <entry key=3D"action" =
value=3D"UsernameToken"/>
>> >                         <entry key=3D"passwordType" =20
>> value=3D"PasswordText"/>
>> >                         <entry key=3D"passwordCallbackRef"
>> > value-ref=3D"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 =20=

>> user
>> >> authentication with WSS4JInHandler.  I would like to know =20
>> whether it is
>> >> supported in CXF.  Appreciate if someone could help me out on =20
>> this.  My
>> >> current configuration is as follows:
>> >>
>> >> <property name=3D"inHandlers">
>> >>             <list>
>> >>                 <bean
>> >> class=3D"org.codehaus.xfire.util.dom.DOMInHandler" />
>> >>                 <bean
>> >>
>> >> class=3D"org.codehaus.xfire.security.wss4j.WSS4JInHandler">
>> >>                     <property name=3D"properties">
>> >>                         <map>
>> >>                             <entry key=3D"passwordCallbackRef">
>> >>                                 <bean
>> >>
>> >> class=3D"com.mydomain.security.PasswordHandler">
>> >>                                 </bean>
>> >>                             </entry>
>> >>                             <entry key=3D"action" =20
>> value=3D"UsernameToken"
>> />
>> >>                         </map>
>> >>                     </property>
>> >>
>> >>                 </bean>
>> >>                 <bean
>> >>
>> >> class=3D"com.mydomain.security.ValidateUserTokenHandler" />
>> >>             </list>
>> >> </property>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/WSS4J-implementation-in-CXF-=20
>> tf4119426.html#a11715464
>> >>
>> >> Sent from the cxf-user mailing list archive at Nabble.com.
>> >>
>> >
>> >
>> >
>> >
>> > Julio Arias
>> > Java Developer
>> > Roundbox Global : enterprise : technology : genius
>> > =20
>> ---------------------------------------------------------------------
>> > Avenida 11 y Calle 7-9, Barrio Am=F3n, San Jose, Costa Rica
>> > tel: 404.567.5000 ext. 2001 | cell: 11.506.849.5981
>> > email: julio.arias@rbxglobal.com | www.rbxglobal.com
>> > =20
>> ---------------------------------------------------------------------
>> >
>> >
>>
>>
>
>
> --=20
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog