Thanks, Ulhas.
I'll work to implement some system tests, then, in CXF, which will
exercise the WSS4J interceptor in such a way that it reproduces the
bug. I'll add the tests as a patch to the ticket, so that when we
fix the issue, the tests will pass.
-Fred
On Jul 24, 2007, at 6:51 AM, Ulhas Bhole(IONA) wrote:
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] | 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
