WSS4J implementation in CXF
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: -- 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.
Re: WSS4J implementation in CXF
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 implementor="#metadataServiceImpl"> ref="authenticationCallbackHandler"/> 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: -- 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 -
Re: WSS4J implementation in CXF
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 only a Map 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 implementor="#metadataServiceImpl"> class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/> class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"> value-ref="authenticationCallbackHandler"/> 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: class="org.codehaus.xfire.util.dom.DOMInHandler" /> class="org.codehaus.xfire.security.wss4j.WSS4JInHandler"> class="com.mydomain.security.PasswordHandler"> class="com.mydomain.security.ValidateUserTokenHandler" /> -- 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 -
Re: WSS4J implementation in CXF
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 only a Map 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 > > implementor="#metadataServiceImpl"> > > class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/> > class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"> > > > > > value-ref="authenticationCallbackHandler"/> > > > > > > > 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: >> >> >> >> > class="org.codehaus.xfire.util.dom.DOMInHandler" /> >> > >> class="org.codehaus.xfire.security.wss4j.WSS4JInHandler"> >> >> >> >> > >> class="com.mydomain.security.PasswordHandler"> >> >> >> >> >> >> >> >> > >> class="com.mydomain.security.ValidateUserTokenHandler" /> >> >> >> -- >> 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
Re: WSS4J implementation in CXF
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 only a Map 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 > > implementor="#metadataServiceImpl"> > > class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/> > class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"> > > > > value="PasswordText"/> > value-ref="authenticationCallbackHandler"/> > > > > > > > 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: >> >> >> >> > class="org.codehaus.xfire.util.dom.DOMInHandler" /> >> > >> class="org.codehaus.xfire.security.wss4j.WSS4JInHandler"> >> >> >> >> > >> class="com.mydomain.security.PasswordHandler"> >> >> >> value="UsernameToken" /> >> >> >> >> >> > >> class="com.mydomain.security.ValidateUserTokenHandler" /> >> >> >> -- >> 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
Re: WSS4J implementation in CXF
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 only a Map 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 >>> > >>> > >> > implementor="#metadataServiceImpl"> >>> > >>> > >> > class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/> >>> > >> > class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"> >>> > >>> > >>> > >>> > >> value="PasswordText"/> >>> > >> > value-ref="authenticationCallbackHandler"/> >>> > >>> > >>> > >>> > >>> > >>> > >>> > 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: >>> >> >>> >> &
Re: WSS4J implementation in CXF
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 only a Map 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 value="UsernameToken"/> value="PasswordText"/> 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: value="UsernameToken" /> -- 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 -