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
