You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by Anand R <An...@ibsplc.com> on 2011/02/03 07:37:50 UTC

Problem with AbstractUsernameTokenInInterceptor

Hi,

My requirement is to perform a custom authentication on the username and 
password that I receive as part of the UsernameToken header in the 
incoming SOAP request. I discovered that cxf-2.3.2 provides an 
AbstractUsernameTokenInInterceptor to perform this. I extended this class 
and created my interceptor that overrides the createSubject method. When I 
configure my interceptor in my beans.xml as shown below, I am getting an 
exception.

This exception comes up when I use a password digest. The plain text 
password works fine. Is there any problem in the way I have configured my 
interceptor?


Entry in beans.xml

        <jaxws:endpoint id="echo" 
implementor="learn.wssecurity.echo.EchoServiceImpl"
                wsdlLocation="wsdl/echo/EchoService.wsdl" 
address="/EchoService"> 
                <jaxws:inInterceptors>
                          <bean 
class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
                </jaxws:inInterceptors>
                <jaxws:properties> 
                        <entry key="ws-security.callback-handler" 
value="learn.wssecurity.echo.ServerPasswordCallback" />
                        <entry key="ws-security.ut.no-callbacks" 
value="true" />
                </jaxws:properties>
        </jaxws:endpoint>


Exception

java.lang.SecurityException: Security Token is not available on the 
current message
        at 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
88)
        at 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
        at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
        at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
        at 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
        at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
        at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
        at 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
        at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
        at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
        at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
        at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
        at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
        at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
        at java.lang.Thread.run(Thread.java:595)

Thanks and regards,
Anand R 







DISCLAIMER: 

"The information in this e-mail and any attachment is intended only for 
the person to whom it is addressed and may contain confidential and/or 
privileged material. If you have received this e-mail in error, kindly 
contact the sender and destroy all copies of the original communication. 
IBS makes no warranty, express or implied, nor guarantees the accuracy, 
adequacy or completeness of the information contained in this email or any 
attachment and is not liable for any errors, defects, omissions, viruses 
or for resultant loss or damage, if any, direct or indirect."

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi Anand - great you made it working. This configuration probably means you
have PolicyBasedWSS4JInInterceptor & UsernameTokenInterceptor involved but
it works because a DOM-based SOAPMessage is used, just guessing. You'd not
need to explicitly register PolicyBasedWSS4JInInterceptor in 2.3.3...

cheers, Sergey




On Tue, Feb 8, 2011 at 12:06 PM, Anand R <An...@ibsplc.com> wrote:

> Thanks Sergey.
>
> Tentatively, I got it working with 2.3.2 by making my config as follows.
> The problem was that the PolicyBasedWSS4JInInterceptor had to be
> explicitly specified in the config.
> Unless specified, this wasn't getting included in the interceptor chain.
>
>        <jaxws:endpoint id="echo"
> implementor="learn.wssecurity.echo.EchoServiceImpl"
>                wsdlLocation="wsdl/echo/EchoService.wsdl"
> address="/EchoService">
>
>                <jaxws:inInterceptors>
>                         <bean
> class="learn.wssecurity.echo.MyUsernameTokenInterceptor">
>                         </bean>
>
>                         <bean
> class="org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor">
>                        </bean>
>                </jaxws:inInterceptors>
>
>                <jaxws:features>
>                        <bean
> class="org.apache.cxf.feature.LoggingFeature" />
>                </jaxws:features>
>
>                <jaxws:properties>
>                         <entry key="ws-security.ut.no-callbacks"
> value="true" />
>                </jaxws:properties>
>
>        </jaxws:endpoint>
> Thanks and regards,
> Anand R
>
>
> From:   Sergey Beryozkin <sb...@gmail.com>
> To:     users@cxf.apache.org
> Date:   08-02-11 05:22 PM
> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>
>
>
> I've fixed this issue for 2.3.3 & 2.4.
>
> Note that on 2.4-SNAPSHOT only this "ws-security.ut.no-callbacks" has been
> renamed to a better "ws-security.validate.token" name.
>
> Colm is doing some nice refactoring on his branch and the
> "ws-security.ut.no-callbacks=true" line in the configuration would really
> read a bit meaningless. The "ws-security.validate.token=false" would not
> convey precisely that we want to postpone the validation of the name &
> password in case of UT but it would be better anyway IMHO...
>
> We can update the 2.4 Migration guide...
>
> thanks, Sergey
>
> On Fri, Feb 4, 2011 at 12:22 PM, Sergey Beryozkin
> <sb...@gmail.com>wrote:
>
> > Actually, I may be understanding why it's not working for you.
> >
> > So if you have a policy embedded in WSDL and
> PolicyBasedWSS4JInInterceptor
> > usually does all the work. However, if it's only a UsernameToken policy
> that
> > is used then UsernameTokenInterceptor is used to do the actual
> processing,
> > as an optimization.
> >
> > So here is a summary :
> > 1. WSS4JInInterceptor is configured directly in java-first cases
> > 2. PolicyBasedWSS4JInInterceptor is used when the policy is embedded in
> > WSDL
> > 3. UsernameTokenInterceptor is used when the policy which is embedded in
> > WSDL contains only a UT assertion
> >
> > As it happens, the "ws-security.ut.no-callbacks" property is ignored in
> > case 3.
> > Can you add yet another breakpoint in UsernameTokenInterceptor ? If you
> > confirm UsernameTokenInterceptor is used then I'll let you know how to
> > intercept the flow with a UsernameTokenInterceptor subclass (hack
> really)
> > and will do a minor fix to ensure the "ws-security.ut.no-callbacks"
> works
> > for 3. as well
> >
> > Cheers, Sergey
> >
> >
> > On Fri, Feb 4, 2011 at 11:52 AM, Sergey Beryozkin
> <sb...@gmail.com>wrote:
> >
> >> Hi Anand
> >>
> >> On Fri, Feb 4, 2011 at 6:50 AM, Anand R <An...@ibsplc.com> wrote:
> >>
> >>> Hi Sergey,
> >>>
> >>> As you mentioned, I added a breakpoint within
> >>> WSS4JInInterceptor.handleMessage(). The web service invocation didn't
> >>>  hit the breakpoint.
> >>> WSS4JInInterceptor wasn't present in the chain of interceptors. I
> added
> >>> this interceptor explicitly in my beans.xml.
> >>>
> >>
> >>
> >> I think I know what is happening. Given a policy is contained in WSDL,
> >> PolicyBasedWSS4JInInterceptor is used, it extends WSS4JInInterceptor,
> CXF
> >> adds it itself. Can you give it another try please, remove the explicit
> >> WSS4JInInterceptor and add a breakpoint in
> >> PolicyBasedWSS4JInInterceptor.handleMessage ?
> >>
> >>
> >> Now I am getting the following exception.
> >>>
> >>> I also tried extending AbstractUsernameTokenAuthenticatingInterceptor.
> I
> >>> am getting the same exception(No security action was defined!).
> >>> I tried setting ws-security.ut.no-callbacks on and off. Both result in
> >>> the same exception.
> >>>
> >>> I didn't understand what action is being referred here. I am attaching
> my
> >>> wsdl for your reference. Is this problem anything to do with my policy
> >>> specification?
> >>>
> >>> The wsdl is fine. As I briefly mentioned, the older
> AbstractUsernameTokenAuthenticatingInterceptor
> >> does not work well with the wsdl first case. It is actually a
> WSS4JInInterceptor
> >> subclass and does all sort of hacks to hide the complexity from the
> user and
> >> provide an (unwrapped) UT to the concrete implementations. However
> >> PolicyBasedWSS4JInInterceptor is used instead when the actions are
> >> 'embedded' inside a given policy, so registering
> >> AbstractUsernameTokenAuthenticatingInterceptor duplicates
> PolicyBasedWSS4JInInterceptor
> >> (you still need to configure the actions even though
> >> PolicyBasedWSS4JInInterceptor knows them from WSDL). I updated it to
> >> continue working in the wsdl-first case (provided the no-callbacks
> property
> >> is set) just to minimize the side-effects for the users already doing
> >> concrete AbstractUsernameTokenAuthenticatingInterceptor impls.
> AbstractUsernameTokenAuthenticatingInterceptor
> >> is ok for java-first cases but the newer
> AbstractUsernameTokenInterceptor
> >> will work for all the cases.
> >>
> >> Check please PolicyBasedWSS4JInInterceptor.handleMessage
> >>
> >> thanks, Sergey
> >>
> >>
> >>>
> >>>
> >>> org.apache.cxf.binding.soap.SoapFault: No security action was defined!
> >>>         at
> >>>
>
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getAction(WSS4JInInterceptor.java:471)
> >>>         at
> >>>
>
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:196)
> >>>         at
> >>>
>
> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:96)
> >>>         at
> >>>
>
> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:67)
> >>>         at
> >>>
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> >>>         at
> >>>
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> >>>         at
> >>>
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> >>>         at
> >>>
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> >>>         at
> >>>
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> >>>         at
> >>>
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> >>>         at
> >>>
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> >>>         at
> >>>
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> >>>         at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> >>>         at
> >>>
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> >>>         at
> >>>
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> >>>         at
> >>>
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >>>         at
> >>>
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> >>>         at
> >>>
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> >>>         at
> >>>
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >>>         at
> >>>
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> >>>         at
> >>>
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> >>>         at
> >>>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> >>>         at
> >>>
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> >>>         at
> >>>
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> >>>         at
> >>>
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> >>>         at java.lang.Thread.run(Thread.java:595)
> >>>
> >>>
> >>> Thanks and regards,
> >>> Anand
> >>>
> >>>
> >>>
> >>> From:        Sergey Beryozkin <sb...@gmail.com>
> >>> To:        users@cxf.apache.org
> >>> Date:        03-02-11 07:28 PM
> >>> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> >>> ------------------------------
> >>>
> >>>
> >>>
> >>> Hi - I do not understand why it not works. I've checked the code and I
> >>> see
> >>> that no test involving a hashed password exists. Likewise I don't
> >>> understand
> >>> why it works at the same time with clear passwords and no callbacks.
> >>> I'm a bit busy right now, is there any chance that you could download
> the
> >>> source for CXF 2.3.2, remove the ServerCallback property and just add
> a
> >>> breakpoint in WSS4JInInterceptor.handleMessage() ?
> >>>
> >>> I think you're on the right track. I do not see other options for
> dealing
> >>> with *hashed passwords*, well, unless you;re prepared to do some hacks
> by
> >>> doing the container-managed authentication from the callback itself
> but
> >>> that
> >>> would not let you register the proper security context because the one
> >>> which
> >>> is created by the WSS4JInInterceptor has only a (WSS4J-created)
> Principal
> >>> registered, i.e, no info about roles is available.
> >>>
> >>> I'd definitely follow this route myself.
> >>> Note that AbstractUsernameTokenAuthenticatingInterceptor (in the
> >>> ws-security
> >>> module) is the other, legacy interceptor that you may also extend - as
> >>> far
> >>> as I know, a 3rd-party container has a test for a hashed UT involving
> >>> this
> >>> particular interceptor. No need to set the
> "ws-security.ut.no-callbacks",
> >>> unless you have a wsdl-first case. Concrete implementations need to
> >>> extend a
> >>> method with several UT-related parameters which is a bit brittle in
> that
> >>> adding more parameters to the
> >>> AbstractUsernameTokenAuthenticatingInterceptor
> >>> will break the users' interceptors.
> >>>
> >>> Thus extending AbstractUsernameTokenInterceptor (in
> rt/core/.../security)
> >>> is
> >>> recommended because we can easily update CXF UsernameToken bean with
> the
> >>> new
> >>> properties ((say the UT salt property, etc)) without the existing
> users
> >>> noticing.
> >>>
> >>> Debug it if you can - it would help
> >>>
> >>> Sergey
> >>>
> >>>
> >>>
> >>> On Thu, Feb 3, 2011 at 1:02 PM, Anand R <An...@ibsplc.com>
> wrote:
> >>>
> >>> > Hi Sergey,
> >>> >
> >>> > As you had mentioned earlier, the namespace is
> >>> >
> >>> >
> >>>
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>
> >>> >
> >>> > Please find the SOAP request message below.
> >>> >
> >>> > Actually, my requirement is to obtain the username and password from
> >>> the
> >>> > SOAP header to perform container authentication and then associate
> the
> >>> > Subject with the current thread of execution. Am I using the correct
> >>> > approach or do I just need to write a SOAPHeaderInterceptor and get
> the
> >>> > required headers.
> >>> >
> >>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/
> ">
> >>> >        <soap:Header>
> >>> >                <wsse:Security soap:mustUnderstand="1"
> >>> >                        xmlns:wsse="
> >>> >
> >>> >
> >>>
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>
> >>> > ">
> >>> >                         <wsse:UsernameToken xmlns:wsse="
> >>> >
> >>> >
> >>>
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>
> >>> > "
> >>> >                                 xmlns:wsu="
> >>> >
> >>> >
> >>>
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>
> >>> > "
> >>> >                                wsu:Id="UsernameToken-1">
> >>> > <wsse:Username>libuser</wsse:Username>
> >>> >                                <wsse:Password
> >>> >                                        Type="
> >>> >
> >>> >
> >>>
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest
>
> >>> > ">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password>
> >>> >                                <wsse:Nonce     EncodingType="
> >>> >
> >>> >
> >>>
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
>
> >>> > ">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce>
> >>> > <wsu:Created>2011-02-03T12:32:27.752Z</
> >>> > wsu:Created>
> >>> >                        </wsse:UsernameToken>
> >>> >                </wsse:Security>
> >>> >        </soap:Header>
> >>> >        <soap:Body>
> >>> >                <ns2:doEcho xmlns:ns2="
> >>> http://types.echo.wssecurity.learn/
> >>> > ">
> >>> >                        <arg0>
> >>> >                                <echoString>Hello
> >>> WS-Security</echoString>
> >>> >                        </arg0>
> >>> >                </ns2:doEcho>
> >>> >        </soap:Body>
> >>> > </soap:Envelope>
> >>> > Thanks and regards,
> >>> > Anand R
> >>> >
> >>> >
> >>> >
> >>> > From:   Sergey Beryozkin <sb...@gmail.com>
> >>> > To:     users@cxf.apache.org
> >>> > Date:   03-02-11 05:13 PM
> >>> > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> >>> >
> >>> >
> >>> >
> >>> > Hi
> >>> >
> >>> > WSS4JInInterceptor is already registering a custom UT processor if
> the
> >>> > "ws-security.ut.no-callbacks" is set to true.
> >>> > So the hashed UTs should be supported with your configuration,
> without
> >>> the
> >>> > need to register a callback.
> >>> > Can you give me a favor and check the actual WS-Security namespace
> that
> >>> is
> >>> > used to qualify the security header ? You can add a CXF logging
> feature
> >>> to
> >>> > the list of jaxws:features
> >>> >
> >>> > thanks, Sergey
> >>> >
> >>> > On Thu, Feb 3, 2011 at 11:33 AM, Anand R <An...@ibsplc.com>
> >>> wrote:
> >>> >
> >>> > > Thanks Sergy. I will try the custom UsernameTokenProcessor.
> >>> > > Thanks and regards,
> >>> > > Anand R
> >>> > >
> >>> > >
> >>> > >
> >>> > > From:   Sergey Beryozkin <sb...@gmail.com>
> >>> > > To:     users@cxf.apache.org
> >>> > > Date:   03-02-11 04:39 PM
> >>> > > Subject:        Re: Problem with
> AbstractUsernameTokenInInterceptor
> >>> > >
> >>> > >
> >>> > >
> >>> > > Hi
> >>> > >
> >>> > > What WS-Security namespace is being used in the request ?
> >>> > > If the "ws-security.ut.no-callbacks" is set to true then the
> >>> > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should
> not
> >>> be
> >>> > > invoked because it does currently require a callback for hashed
> UTs.
> >>> So
> >>> > if
> >>> > > the property is set then the WSS4JInInterceptor registers a custom
> >>> > > UsernameTokenProcessor for
> >>> > >
> >>> > > "
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>
> >>> >
> >>> > >
> >>> > > "
> >>> > > and
> >>> > > "
> http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd
> >>> ".
> >>> > >
> >>> > > Thanks, Sergey
> >>> > >
> >>> > > On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com>
> >>> wrote:
> >>> > >
> >>> > > > Hi Sergey,
> >>> > > >
> >>> > > > Thanks for your response. I used to get the following exception
> >>> when I
> >>> > > did
> >>> > > > not configure a callback handler. This exception does not come
> if
> >>> the
> >>> > > > password is plain text instead of a digest.
> >>> > > >
> >>> > > > org.apache.cxf.interceptor.Fault: General security error
> >>> > > > (WSSecurityEngine: No password callback supplied)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
> >>> > > >         at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> >>> > > >        at
> >>> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> >>> > > >        at
> >>> > > >
> >>> > >
> >>> >
> >>>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> >>> > > >        at
> >>> > > >
> >>> > >
> >>> >
> >>>
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> >>> > > >        at
> >>> > > >
> >>> >
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> >>> > > >        at java.lang.Thread.run(Thread.java:595)
> >>> > > > Caused by: org.apache.ws.security.WSSecurityException: General
> >>> > security
> >>> > > > error (WSSecurityEngine: No password callback supplied)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
> >>> > > >        at
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
> >>> > > >        ... 24 more
> >>> > > >
> >>> > > >
> >>> > > > Thanks and regards,
> >>> > > > Anand R
> >>> > > > System Architect
> >>> > > > IBS Software Services Private Limited
> >>> > > > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum
> -
> >>> > > 695581,
> >>> > > > Kerala, India
> >>> > > > Telephone - +91-471-6614291, Mobile - +91-9846324022
> >>> > > > E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > From:   Sergey Beryozkin <sb...@gmail.com>
> >>> > > > To:     users@cxf.apache.org
> >>> > > > Date:   03-02-11 04:08 PM
> >>> > > > Subject:        Re: Problem with
> AbstractUsernameTokenInInterceptor
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > Hi
> >>> > > >
> >>> > > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com>
> >>> > wrote:
> >>> > > >
> >>> > > > > Hi,
> >>> > > > >
> >>> > > > > My requirement is to perform a custom authentication on the
> >>> username
> >>> > > and
> >>> > > > > password that I receive as part of the UsernameToken header in
> >>> the
> >>> > > > > incoming SOAP request. I discovered that cxf-2.3.2 provides an
> >>> > > > > AbstractUsernameTokenInInterceptor to perform this. I extended
> >>> this
> >>> > > > class
> >>> > > > > and created my interceptor that overrides the createSubject
> >>> method.
> >>> > > When
> >>> > > > I
> >>> > > > > configure my interceptor in my beans.xml as shown below, I am
> >>> > getting
> >>> > > an
> >>> > > > > exception.
> >>> > > > >
> >>> > > > > This exception comes up when I use a password digest. The
> plain
> >>> text
> >>> > > > > password works fine. Is there any problem in the way I have
> >>> > configured
> >>> > > > my
> >>> > > > > interceptor?
> >>> > > > >
> >>> > > > >
> >>> > > > > Entry in beans.xml
> >>> > > > >
> >>> > > > >        <jaxws:endpoint id="echo"
> >>> > > > > implementor="learn.wssecurity.echo.EchoServiceImpl"
> >>> > > > >                wsdlLocation="wsdl/echo/EchoService.wsdl"
> >>> > > > > address="/EchoService">
> >>> > > > >                <jaxws:inInterceptors>
> >>> > > > >                          <bean
> >>> > > > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
> >>> > > > >                </jaxws:inInterceptors>
> >>> > > > >                <jaxws:properties>
> >>> > > > >                        <entry
> key="ws-security.callback-handler"
> >>> > > > > value="learn.wssecurity.echo.ServerPasswordCallback" />
> >>> > > > >                        <entry
> key="ws-security.ut.no-callbacks"
> >>> > > > > value="true" />
> >>> > > > >                </jaxws:properties>
> >>> > > > >        </jaxws:endpoint>
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > > What is the purpose of registering ServerPasswordCallback ? If
> you
> >>> set
> >>> > a
> >>> > > > "ws-security.ut.no-callbacks" property then you only need a
> >>> callback
> >>> > if
> >>> > > > you
> >>> > > > have an encrypted UT, so that the UT can be decrypted.
> >>> > > > So this callback that you're registering may be interfering in
> the
> >>> > case
> >>> > > > when
> >>> > > > you have a hashed UT token, can you remove it please and see
> what
> >>> > > happens
> >>> > > > ?
> >>> > > >
> >>> > > > Cheers, Sergey
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > >
> >>> > > > > Exception
> >>> > > > >
> >>> > > > > java.lang.SecurityException: Security Token is not available
> on
> >>> the
> >>> > > > > current message
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> >>> > > > > 88)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> >>> > > > >        at
> >>> > javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> >>> > > > >        at
> >>> > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> >>> > > > >        at
> >>> > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> >>> > > > >        at
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> >>> > > > >        at
> >>> > > > >
> >>> > >
> >>>
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> >>> > > > >        at java.lang.Thread.run(Thread.java:595)
> >>> > > > >
> >>> > > > > Thanks and regards,
> >>> > > > > Anand R
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > > DISCLAIMER:
> >>> > > > >
> >>> > > > > "The information in this e-mail and any attachment is intended
> >>> only
> >>> > > for
> >>> > > > > the person to whom it is addressed and may contain
> confidential
> >>> > and/or
> >>> > > > > privileged material. If you have received this e-mail in
> error,
> >>> > kindly
> >>> > > > > contact the sender and destroy all copies of the original
> >>> > > communication.
> >>> > > > > IBS makes no warranty, express or implied, nor guarantees the
> >>> > > accuracy,
> >>> > > > > adequacy or completeness of the information contained in this
> >>> email
> >>> > or
> >>> > > > any
> >>> > > > > attachment and is not liable for any errors, defects,
> omissions,
> >>> > > viruses
> >>> > > > > or for resultant loss or damage, if any, direct or indirect."
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > DISCLAIMER:
> >>> > > >
> >>> > > > "The information in this e-mail and any attachment is intended
> only
> >>> > for
> >>> > > > the person to whom it is addressed and may contain confidential
> >>> and/or
> >>> > > > privileged material. If you have received this e-mail in error,
> >>> kindly
> >>> > > > contact the sender and destroy all copies of the original
> >>> > communication.
> >>> > > > IBS makes no warranty, express or implied, nor guarantees the
> >>> > accuracy,
> >>> > > > adequacy or completeness of the information contained in this
> email
> >>> or
> >>> > > any
> >>> > > > attachment and is not liable for any errors, defects, omissions,
> >>> > viruses
> >>> > > > or for resultant loss or damage, if any, direct or indirect."
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > DISCLAIMER:
> >>> > >
> >>> > > "The information in this e-mail and any attachment is intended
> only
> >>> for
> >>> > > the person to whom it is addressed and may contain confidential
> >>> and/or
> >>> > > privileged material. If you have received this e-mail in error,
> >>> kindly
> >>> > > contact the sender and destroy all copies of the original
> >>> communication.
> >>> > > IBS makes no warranty, express or implied, nor guarantees the
> >>> accuracy,
> >>> > > adequacy or completeness of the information contained in this
> email
> >>> or
> >>> > any
> >>> > > attachment and is not liable for any errors, defects, omissions,
> >>> viruses
> >>> > > or for resultant loss or damage, if any, direct or indirect."
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > DISCLAIMER:
> >>> >
> >>> > "The information in this e-mail and any attachment is intended only
> for
> >>> > the person to whom it is addressed and may contain confidential
> and/or
> >>> > privileged material. If you have received this e-mail in error,
> kindly
> >>> > contact the sender and destroy all copies of the original
> >>> communication.
> >>> > IBS makes no warranty, express or implied, nor guarantees the
> accuracy,
> >>> > adequacy or completeness of the information contained in this email
> or
> >>> any
> >>> > attachment and is not liable for any errors, defects, omissions,
> >>> viruses
> >>> > or for resultant loss or damage, if any, direct or indirect."
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> DISCLAIMER:
> >>>
> >>> "The information in this e-mail and any attachment is intended only
> for
> >>> the person to whom it is addressed and may contain confidential and/or
> >>> privileged material. If you have received this e-mail in error, kindly
> >>> contact the sender and destroy all copies of the original
> communication. IBS
> >>> makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy
> >>> or completeness of the information contained in this email or any
> attachment
> >>> and is not liable for any errors, defects, omissions, viruses or for
> >>> resultant loss or damage, if any, direct or indirect."
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for
> the person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication.
> IBS makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy or completeness of the information contained in this email or any
> attachment and is not liable for any errors, defects, omissions, viruses
> or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Anand R <An...@ibsplc.com>.

Thanks Sergey. 

Tentatively, I got it working with 2.3.2 by making my config as follows. 
The problem was that the PolicyBasedWSS4JInInterceptor had to be 
explicitly specified in the config. 
Unless specified, this wasn't getting included in the interceptor chain.

        <jaxws:endpoint id="echo" 
implementor="learn.wssecurity.echo.EchoServiceImpl"
                wsdlLocation="wsdl/echo/EchoService.wsdl" 
address="/EchoService">
 
                <jaxws:inInterceptors> 
                         <bean 
class="learn.wssecurity.echo.MyUsernameTokenInterceptor">
                         </bean>
 
                         <bean 
class="org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor">
                        </bean> 
                </jaxws:inInterceptors> 
 
                <jaxws:features>
                        <bean 
class="org.apache.cxf.feature.LoggingFeature" />
                </jaxws:features>
 
                <jaxws:properties>
                        <entry key="ws-security.ut.no-callbacks" 
value="true" />
                </jaxws:properties>
 
        </jaxws:endpoint>
Thanks and regards,
Anand R


From:   Sergey Beryozkin <sb...@gmail.com>
To:     users@cxf.apache.org
Date:   08-02-11 05:22 PM
Subject:        Re: Problem with AbstractUsernameTokenInInterceptor



I've fixed this issue for 2.3.3 & 2.4.

Note that on 2.4-SNAPSHOT only this "ws-security.ut.no-callbacks" has been
renamed to a better "ws-security.validate.token" name.

Colm is doing some nice refactoring on his branch and the
"ws-security.ut.no-callbacks=true" line in the configuration would really
read a bit meaningless. The "ws-security.validate.token=false" would not
convey precisely that we want to postpone the validation of the name &
password in case of UT but it would be better anyway IMHO...

We can update the 2.4 Migration guide...

thanks, Sergey

On Fri, Feb 4, 2011 at 12:22 PM, Sergey Beryozkin 
<sb...@gmail.com>wrote:

> Actually, I may be understanding why it's not working for you.
>
> So if you have a policy embedded in WSDL and 
PolicyBasedWSS4JInInterceptor
> usually does all the work. However, if it's only a UsernameToken policy 
that
> is used then UsernameTokenInterceptor is used to do the actual 
processing,
> as an optimization.
>
> So here is a summary :
> 1. WSS4JInInterceptor is configured directly in java-first cases
> 2. PolicyBasedWSS4JInInterceptor is used when the policy is embedded in
> WSDL
> 3. UsernameTokenInterceptor is used when the policy which is embedded in
> WSDL contains only a UT assertion
>
> As it happens, the "ws-security.ut.no-callbacks" property is ignored in
> case 3.
> Can you add yet another breakpoint in UsernameTokenInterceptor ? If you
> confirm UsernameTokenInterceptor is used then I'll let you know how to
> intercept the flow with a UsernameTokenInterceptor subclass (hack 
really)
> and will do a minor fix to ensure the "ws-security.ut.no-callbacks" 
works
> for 3. as well
>
> Cheers, Sergey
>
>
> On Fri, Feb 4, 2011 at 11:52 AM, Sergey Beryozkin 
<sb...@gmail.com>wrote:
>
>> Hi Anand
>>
>> On Fri, Feb 4, 2011 at 6:50 AM, Anand R <An...@ibsplc.com> wrote:
>>
>>> Hi Sergey,
>>>
>>> As you mentioned, I added a breakpoint within
>>> WSS4JInInterceptor.handleMessage(). The web service invocation didn't
>>>  hit the breakpoint.
>>> WSS4JInInterceptor wasn't present in the chain of interceptors. I 
added
>>> this interceptor explicitly in my beans.xml.
>>>
>>
>>
>> I think I know what is happening. Given a policy is contained in WSDL,
>> PolicyBasedWSS4JInInterceptor is used, it extends WSS4JInInterceptor, 
CXF
>> adds it itself. Can you give it another try please, remove the explicit
>> WSS4JInInterceptor and add a breakpoint in
>> PolicyBasedWSS4JInInterceptor.handleMessage ?
>>
>>
>> Now I am getting the following exception.
>>>
>>> I also tried extending AbstractUsernameTokenAuthenticatingInterceptor. 
I
>>> am getting the same exception(No security action was defined!).
>>> I tried setting ws-security.ut.no-callbacks on and off. Both result in
>>> the same exception.
>>>
>>> I didn't understand what action is being referred here. I am attaching 
my
>>> wsdl for your reference. Is this problem anything to do with my policy
>>> specification?
>>>
>>> The wsdl is fine. As I briefly mentioned, the older 
AbstractUsernameTokenAuthenticatingInterceptor
>> does not work well with the wsdl first case. It is actually a 
WSS4JInInterceptor
>> subclass and does all sort of hacks to hide the complexity from the 
user and
>> provide an (unwrapped) UT to the concrete implementations. However
>> PolicyBasedWSS4JInInterceptor is used instead when the actions are
>> 'embedded' inside a given policy, so registering
>> AbstractUsernameTokenAuthenticatingInterceptor duplicates 
PolicyBasedWSS4JInInterceptor
>> (you still need to configure the actions even though
>> PolicyBasedWSS4JInInterceptor knows them from WSDL). I updated it to
>> continue working in the wsdl-first case (provided the no-callbacks 
property
>> is set) just to minimize the side-effects for the users already doing
>> concrete AbstractUsernameTokenAuthenticatingInterceptor impls. 
AbstractUsernameTokenAuthenticatingInterceptor
>> is ok for java-first cases but the newer 
AbstractUsernameTokenInterceptor
>> will work for all the cases.
>>
>> Check please PolicyBasedWSS4JInInterceptor.handleMessage
>>
>> thanks, Sergey
>>
>>
>>>
>>>
>>> org.apache.cxf.binding.soap.SoapFault: No security action was defined!
>>>         at
>>> 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getAction(WSS4JInInterceptor.java:471)
>>>         at
>>> 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:196)
>>>         at
>>> 
org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:96)
>>>         at
>>> 
org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:67)
>>>         at
>>> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>>>         at
>>> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>>>         at
>>> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>>>         at
>>> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>>>         at
>>> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>>>         at
>>> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>>>         at
>>> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>>>         at
>>> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>>>         at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>>>         at
>>> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>>>         at
>>> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>>         at
>>> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>>         at
>>> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>>>         at
>>> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>>>         at
>>> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>>         at
>>> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>>>         at
>>> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>>         at
>>> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>>>         at
>>> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>>>         at
>>> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>>>         at
>>> 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>>>         at java.lang.Thread.run(Thread.java:595)
>>>
>>>
>>> Thanks and regards,
>>> Anand
>>>
>>>
>>>
>>> From:        Sergey Beryozkin <sb...@gmail.com>
>>> To:        users@cxf.apache.org
>>> Date:        03-02-11 07:28 PM
>>> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>>> ------------------------------
>>>
>>>
>>>
>>> Hi - I do not understand why it not works. I've checked the code and I
>>> see
>>> that no test involving a hashed password exists. Likewise I don't
>>> understand
>>> why it works at the same time with clear passwords and no callbacks.
>>> I'm a bit busy right now, is there any chance that you could download 
the
>>> source for CXF 2.3.2, remove the ServerCallback property and just add 
a
>>> breakpoint in WSS4JInInterceptor.handleMessage() ?
>>>
>>> I think you're on the right track. I do not see other options for 
dealing
>>> with *hashed passwords*, well, unless you;re prepared to do some hacks 
by
>>> doing the container-managed authentication from the callback itself 
but
>>> that
>>> would not let you register the proper security context because the one
>>> which
>>> is created by the WSS4JInInterceptor has only a (WSS4J-created) 
Principal
>>> registered, i.e, no info about roles is available.
>>>
>>> I'd definitely follow this route myself.
>>> Note that AbstractUsernameTokenAuthenticatingInterceptor (in the
>>> ws-security
>>> module) is the other, legacy interceptor that you may also extend - as
>>> far
>>> as I know, a 3rd-party container has a test for a hashed UT involving
>>> this
>>> particular interceptor. No need to set the 
"ws-security.ut.no-callbacks",
>>> unless you have a wsdl-first case. Concrete implementations need to
>>> extend a
>>> method with several UT-related parameters which is a bit brittle in 
that
>>> adding more parameters to the
>>> AbstractUsernameTokenAuthenticatingInterceptor
>>> will break the users' interceptors.
>>>
>>> Thus extending AbstractUsernameTokenInterceptor (in 
rt/core/.../security)
>>> is
>>> recommended because we can easily update CXF UsernameToken bean with 
the
>>> new
>>> properties ((say the UT salt property, etc)) without the existing 
users
>>> noticing.
>>>
>>> Debug it if you can - it would help
>>>
>>> Sergey
>>>
>>>
>>>
>>> On Thu, Feb 3, 2011 at 1:02 PM, Anand R <An...@ibsplc.com> 
wrote:
>>>
>>> > Hi Sergey,
>>> >
>>> > As you had mentioned earlier, the namespace is
>>> >
>>> >
>>> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

>>> >
>>> > Please find the SOAP request message below.
>>> >
>>> > Actually, my requirement is to obtain the username and password from
>>> the
>>> > SOAP header to perform container authentication and then associate 
the
>>> > Subject with the current thread of execution. Am I using the correct
>>> > approach or do I just need to write a SOAPHeaderInterceptor and get 
the
>>> > required headers.
>>> >
>>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/
">
>>> >        <soap:Header>
>>> >                <wsse:Security soap:mustUnderstand="1"
>>> >                        xmlns:wsse="
>>> >
>>> >
>>> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

>>> > ">
>>> >                         <wsse:UsernameToken xmlns:wsse="
>>> >
>>> >
>>> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

>>> > "
>>> >                                 xmlns:wsu="
>>> >
>>> >
>>> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd

>>> > "
>>> >                                wsu:Id="UsernameToken-1">
>>> > <wsse:Username>libuser</wsse:Username>
>>> >                                <wsse:Password
>>> >                                        Type="
>>> >
>>> >
>>> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest

>>> > ">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password>
>>> >                                <wsse:Nonce     EncodingType="
>>> >
>>> >
>>> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary

>>> > ">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce>
>>> > <wsu:Created>2011-02-03T12:32:27.752Z</
>>> > wsu:Created>
>>> >                        </wsse:UsernameToken>
>>> >                </wsse:Security>
>>> >        </soap:Header>
>>> >        <soap:Body>
>>> >                <ns2:doEcho xmlns:ns2="
>>> http://types.echo.wssecurity.learn/
>>> > ">
>>> >                        <arg0>
>>> >                                <echoString>Hello
>>> WS-Security</echoString>
>>> >                        </arg0>
>>> >                </ns2:doEcho>
>>> >        </soap:Body>
>>> > </soap:Envelope>
>>> > Thanks and regards,
>>> > Anand R
>>> >
>>> >
>>> >
>>> > From:   Sergey Beryozkin <sb...@gmail.com>
>>> > To:     users@cxf.apache.org
>>> > Date:   03-02-11 05:13 PM
>>> > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>>> >
>>> >
>>> >
>>> > Hi
>>> >
>>> > WSS4JInInterceptor is already registering a custom UT processor if 
the
>>> > "ws-security.ut.no-callbacks" is set to true.
>>> > So the hashed UTs should be supported with your configuration, 
without
>>> the
>>> > need to register a callback.
>>> > Can you give me a favor and check the actual WS-Security namespace 
that
>>> is
>>> > used to qualify the security header ? You can add a CXF logging 
feature
>>> to
>>> > the list of jaxws:features
>>> >
>>> > thanks, Sergey
>>> >
>>> > On Thu, Feb 3, 2011 at 11:33 AM, Anand R <An...@ibsplc.com>
>>> wrote:
>>> >
>>> > > Thanks Sergy. I will try the custom UsernameTokenProcessor.
>>> > > Thanks and regards,
>>> > > Anand R
>>> > >
>>> > >
>>> > >
>>> > > From:   Sergey Beryozkin <sb...@gmail.com>
>>> > > To:     users@cxf.apache.org
>>> > > Date:   03-02-11 04:39 PM
>>> > > Subject:        Re: Problem with 
AbstractUsernameTokenInInterceptor
>>> > >
>>> > >
>>> > >
>>> > > Hi
>>> > >
>>> > > What WS-Security namespace is being used in the request ?
>>> > > If the "ws-security.ut.no-callbacks" is set to true then the
>>> > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should 
not
>>> be
>>> > > invoked because it does currently require a callback for hashed 
UTs.
>>> So
>>> > if
>>> > > the property is set then the WSS4JInInterceptor registers a custom
>>> > > UsernameTokenProcessor for
>>> > >
>>> > > "
>>> > >
>>> > >
>>> >
>>> >
>>> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

>>> >
>>> > >
>>> > > "
>>> > > and
>>> > > "
http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd
>>> ".
>>> > >
>>> > > Thanks, Sergey
>>> > >
>>> > > On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com>
>>> wrote:
>>> > >
>>> > > > Hi Sergey,
>>> > > >
>>> > > > Thanks for your response. I used to get the following exception
>>> when I
>>> > > did
>>> > > > not configure a callback handler. This exception does not come 
if
>>> the
>>> > > > password is plain text instead of a digest.
>>> > > >
>>> > > > org.apache.cxf.interceptor.Fault: General security error
>>> > > > (WSSecurityEngine: No password callback supplied)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
>>> > > >         at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>>> > > >        at
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>> > > >        at
>>> > > >
>>> > >
>>> >
>>> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>>> > > >        at
>>> > > >
>>> > >
>>> >
>>> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>>> > > >        at
>>> > > >
>>> > 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>>> > > >        at java.lang.Thread.run(Thread.java:595)
>>> > > > Caused by: org.apache.ws.security.WSSecurityException: General
>>> > security
>>> > > > error (WSSecurityEngine: No password callback supplied)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
>>> > > >        ... 24 more
>>> > > >
>>> > > >
>>> > > > Thanks and regards,
>>> > > > Anand R
>>> > > > System Architect
>>> > > > IBS Software Services Private Limited
>>> > > > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum 
-
>>> > > 695581,
>>> > > > Kerala, India
>>> > > > Telephone - +91-471-6614291, Mobile - +91-9846324022
>>> > > > E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > From:   Sergey Beryozkin <sb...@gmail.com>
>>> > > > To:     users@cxf.apache.org
>>> > > > Date:   03-02-11 04:08 PM
>>> > > > Subject:        Re: Problem with 
AbstractUsernameTokenInInterceptor
>>> > > >
>>> > > >
>>> > > >
>>> > > > Hi
>>> > > >
>>> > > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com>
>>> > wrote:
>>> > > >
>>> > > > > Hi,
>>> > > > >
>>> > > > > My requirement is to perform a custom authentication on the
>>> username
>>> > > and
>>> > > > > password that I receive as part of the UsernameToken header in
>>> the
>>> > > > > incoming SOAP request. I discovered that cxf-2.3.2 provides an
>>> > > > > AbstractUsernameTokenInInterceptor to perform this. I extended
>>> this
>>> > > > class
>>> > > > > and created my interceptor that overrides the createSubject
>>> method.
>>> > > When
>>> > > > I
>>> > > > > configure my interceptor in my beans.xml as shown below, I am
>>> > getting
>>> > > an
>>> > > > > exception.
>>> > > > >
>>> > > > > This exception comes up when I use a password digest. The 
plain
>>> text
>>> > > > > password works fine. Is there any problem in the way I have
>>> > configured
>>> > > > my
>>> > > > > interceptor?
>>> > > > >
>>> > > > >
>>> > > > > Entry in beans.xml
>>> > > > >
>>> > > > >        <jaxws:endpoint id="echo"
>>> > > > > implementor="learn.wssecurity.echo.EchoServiceImpl"
>>> > > > >                wsdlLocation="wsdl/echo/EchoService.wsdl"
>>> > > > > address="/EchoService">
>>> > > > >                <jaxws:inInterceptors>
>>> > > > >                          <bean
>>> > > > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
>>> > > > >                </jaxws:inInterceptors>
>>> > > > >                <jaxws:properties>
>>> > > > >                        <entry 
key="ws-security.callback-handler"
>>> > > > > value="learn.wssecurity.echo.ServerPasswordCallback" />
>>> > > > >                        <entry 
key="ws-security.ut.no-callbacks"
>>> > > > > value="true" />
>>> > > > >                </jaxws:properties>
>>> > > > >        </jaxws:endpoint>
>>> > > > >
>>> > > > >
>>> > > >
>>> > > > What is the purpose of registering ServerPasswordCallback ? If 
you
>>> set
>>> > a
>>> > > > "ws-security.ut.no-callbacks" property then you only need a
>>> callback
>>> > if
>>> > > > you
>>> > > > have an encrypted UT, so that the UT can be decrypted.
>>> > > > So this callback that you're registering may be interfering in 
the
>>> > case
>>> > > > when
>>> > > > you have a hashed UT token, can you remove it please and see 
what
>>> > > happens
>>> > > > ?
>>> > > >
>>> > > > Cheers, Sergey
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > >
>>> > > > > Exception
>>> > > > >
>>> > > > > java.lang.SecurityException: Security Token is not available 
on
>>> the
>>> > > > > current message
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
>>> > > > > 88)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>>> > > > >        at
>>> > javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>> > > > >        at
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>>> > > > >        at
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>>> > > > >        at
>>> > > > >
>>> > >
>>> 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>>> > > > >        at java.lang.Thread.run(Thread.java:595)
>>> > > > >
>>> > > > > Thanks and regards,
>>> > > > > Anand R
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > DISCLAIMER:
>>> > > > >
>>> > > > > "The information in this e-mail and any attachment is intended
>>> only
>>> > > for
>>> > > > > the person to whom it is addressed and may contain 
confidential
>>> > and/or
>>> > > > > privileged material. If you have received this e-mail in 
error,
>>> > kindly
>>> > > > > contact the sender and destroy all copies of the original
>>> > > communication.
>>> > > > > IBS makes no warranty, express or implied, nor guarantees the
>>> > > accuracy,
>>> > > > > adequacy or completeness of the information contained in this
>>> email
>>> > or
>>> > > > any
>>> > > > > attachment and is not liable for any errors, defects, 
omissions,
>>> > > viruses
>>> > > > > or for resultant loss or damage, if any, direct or indirect."
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > DISCLAIMER:
>>> > > >
>>> > > > "The information in this e-mail and any attachment is intended 
only
>>> > for
>>> > > > the person to whom it is addressed and may contain confidential
>>> and/or
>>> > > > privileged material. If you have received this e-mail in error,
>>> kindly
>>> > > > contact the sender and destroy all copies of the original
>>> > communication.
>>> > > > IBS makes no warranty, express or implied, nor guarantees the
>>> > accuracy,
>>> > > > adequacy or completeness of the information contained in this 
email
>>> or
>>> > > any
>>> > > > attachment and is not liable for any errors, defects, omissions,
>>> > viruses
>>> > > > or for resultant loss or damage, if any, direct or indirect."
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > DISCLAIMER:
>>> > >
>>> > > "The information in this e-mail and any attachment is intended 
only
>>> for
>>> > > the person to whom it is addressed and may contain confidential
>>> and/or
>>> > > privileged material. If you have received this e-mail in error,
>>> kindly
>>> > > contact the sender and destroy all copies of the original
>>> communication.
>>> > > IBS makes no warranty, express or implied, nor guarantees the
>>> accuracy,
>>> > > adequacy or completeness of the information contained in this 
email
>>> or
>>> > any
>>> > > attachment and is not liable for any errors, defects, omissions,
>>> viruses
>>> > > or for resultant loss or damage, if any, direct or indirect."
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > DISCLAIMER:
>>> >
>>> > "The information in this e-mail and any attachment is intended only 
for
>>> > the person to whom it is addressed and may contain confidential 
and/or
>>> > privileged material. If you have received this e-mail in error, 
kindly
>>> > contact the sender and destroy all copies of the original
>>> communication.
>>> > IBS makes no warranty, express or implied, nor guarantees the 
accuracy,
>>> > adequacy or completeness of the information contained in this email 
or
>>> any
>>> > attachment and is not liable for any errors, defects, omissions,
>>> viruses
>>> > or for resultant loss or damage, if any, direct or indirect."
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> DISCLAIMER:
>>>
>>> "The information in this e-mail and any attachment is intended only 
for
>>> the person to whom it is addressed and may contain confidential and/or
>>> privileged material. If you have received this e-mail in error, kindly
>>> contact the sender and destroy all copies of the original 
communication. IBS
>>> makes no warranty, express or implied, nor guarantees the accuracy, 
adequacy
>>> or completeness of the information contained in this email or any 
attachment
>>> and is not liable for any errors, defects, omissions, viruses or for
>>> resultant loss or damage, if any, direct or indirect."
>>>
>>>
>>>
>>>
>>>
>>
>







DISCLAIMER: 

"The information in this e-mail and any attachment is intended only for 
the person to whom it is addressed and may contain confidential and/or 
privileged material. If you have received this e-mail in error, kindly 
contact the sender and destroy all copies of the original communication. 
IBS makes no warranty, express or implied, nor guarantees the accuracy, 
adequacy or completeness of the information contained in this email or any 
attachment and is not liable for any errors, defects, omissions, viruses 
or for resultant loss or damage, if any, direct or indirect."

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Sergey Beryozkin <sb...@gmail.com>.

I've fixed this issue for 2.3.3 & 2.4.

Note that on 2.4-SNAPSHOT only this "ws-security.ut.no-callbacks" has been
renamed to a better "ws-security.validate.token" name.

Colm is doing some nice refactoring on his branch and the
"ws-security.ut.no-callbacks=true" line in the configuration would really
read a bit meaningless. The "ws-security.validate.token=false" would not
convey precisely that we want to postpone the validation of the name &
password in case of UT but it would be better anyway IMHO...

We can update the 2.4 Migration guide...

thanks, Sergey

On Fri, Feb 4, 2011 at 12:22 PM, Sergey Beryozkin <sb...@gmail.com>wrote:

> Actually, I may be understanding why it's not working for you.
>
> So if you have a policy embedded in WSDL and PolicyBasedWSS4JInInterceptor
> usually does all the work. However, if it's only a UsernameToken policy that
> is used then UsernameTokenInterceptor is used to do the actual processing,
> as an optimization.
>
> So here is a summary :
> 1. WSS4JInInterceptor is configured directly in java-first cases
> 2. PolicyBasedWSS4JInInterceptor is used when the policy is embedded in
> WSDL
> 3. UsernameTokenInterceptor is used when the policy which is embedded in
> WSDL contains only a UT assertion
>
> As it happens, the "ws-security.ut.no-callbacks" property is ignored in
> case 3.
> Can you add yet another breakpoint in UsernameTokenInterceptor ? If you
> confirm UsernameTokenInterceptor is used then I'll let you know how to
> intercept the flow with a UsernameTokenInterceptor subclass (hack really)
> and will do a minor fix to ensure the "ws-security.ut.no-callbacks" works
> for 3. as well
>
> Cheers, Sergey
>
>
> On Fri, Feb 4, 2011 at 11:52 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
>
>> Hi Anand
>>
>> On Fri, Feb 4, 2011 at 6:50 AM, Anand R <An...@ibsplc.com> wrote:
>>
>>> Hi Sergey,
>>>
>>> As you mentioned, I added a breakpoint within
>>> WSS4JInInterceptor.handleMessage(). The web service invocation didn't
>>>  hit the breakpoint.
>>> WSS4JInInterceptor wasn't present in the chain of interceptors. I added
>>> this interceptor explicitly in my beans.xml.
>>>
>>
>>
>> I think I know what is happening. Given a policy is contained in WSDL,
>> PolicyBasedWSS4JInInterceptor is used, it extends WSS4JInInterceptor, CXF
>> adds it itself. Can you give it another try please, remove the explicit
>> WSS4JInInterceptor and add a breakpoint in
>> PolicyBasedWSS4JInInterceptor.handleMessage ?
>>
>>
>> Now I am getting the following exception.
>>>
>>> I also tried extending AbstractUsernameTokenAuthenticatingInterceptor. I
>>> am getting the same exception(No security action was defined!).
>>> I tried setting ws-security.ut.no-callbacks on and off. Both result in
>>> the same exception.
>>>
>>> I didn't understand what action is being referred here. I am attaching my
>>> wsdl for your reference. Is this problem anything to do with my policy
>>> specification?
>>>
>>> The wsdl is fine. As I briefly mentioned, the older AbstractUsernameTokenAuthenticatingInterceptor
>> does not work well with the wsdl first case. It is actually a WSS4JInInterceptor
>> subclass and does all sort of hacks to hide the complexity from the user and
>> provide an (unwrapped) UT to the concrete implementations. However
>> PolicyBasedWSS4JInInterceptor is used instead when the actions are
>> 'embedded' inside a given policy, so registering
>> AbstractUsernameTokenAuthenticatingInterceptor duplicates PolicyBasedWSS4JInInterceptor
>> (you still need to configure the actions even though
>> PolicyBasedWSS4JInInterceptor knows them from WSDL). I updated it to
>> continue working in the wsdl-first case (provided the no-callbacks property
>> is set) just to minimize the side-effects for the users already doing
>> concrete AbstractUsernameTokenAuthenticatingInterceptor impls. AbstractUsernameTokenAuthenticatingInterceptor
>> is ok for java-first cases but the newer AbstractUsernameTokenInterceptor
>> will work for all the cases.
>>
>> Check please PolicyBasedWSS4JInInterceptor.handleMessage
>>
>> thanks, Sergey
>>
>>
>>>
>>>
>>> org.apache.cxf.binding.soap.SoapFault: No security action was defined!
>>>         at
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getAction(WSS4JInInterceptor.java:471)
>>>         at
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:196)
>>>         at
>>> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:96)
>>>         at
>>> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:67)
>>>         at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>>>         at
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>>>         at
>>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>>>         at
>>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>>>         at
>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>>>         at
>>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>>>         at
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>>>         at
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>>>         at
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>>>         at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>>         at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>>         at
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>>>         at
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>>>         at
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>>         at
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>>>         at
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>>         at
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>>>         at
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>>>         at
>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>>>         at
>>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>>>         at java.lang.Thread.run(Thread.java:595)
>>>
>>>
>>> Thanks and regards,
>>> Anand
>>>
>>>
>>>
>>> From:        Sergey Beryozkin <sb...@gmail.com>
>>> To:        users@cxf.apache.org
>>> Date:        03-02-11 07:28 PM
>>> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>>> ------------------------------
>>>
>>>
>>>
>>> Hi - I do not understand why it not works. I've checked the code and I
>>> see
>>> that no test involving a hashed password exists. Likewise I don't
>>> understand
>>> why it works at the same time with clear passwords and no callbacks.
>>> I'm a bit busy right now, is there any chance that you could download the
>>> source for CXF 2.3.2, remove the ServerCallback property and just add a
>>> breakpoint in WSS4JInInterceptor.handleMessage() ?
>>>
>>> I think you're on the right track. I do not see other options for dealing
>>> with *hashed passwords*, well, unless you;re prepared to do some hacks by
>>> doing the container-managed authentication from the callback itself but
>>> that
>>> would not let you register the proper security context because the one
>>> which
>>> is created by the WSS4JInInterceptor has only a (WSS4J-created) Principal
>>> registered, i.e, no info about roles is available.
>>>
>>> I'd definitely follow this route myself.
>>> Note that AbstractUsernameTokenAuthenticatingInterceptor (in the
>>> ws-security
>>> module) is the other, legacy interceptor that you may also extend - as
>>> far
>>> as I know, a 3rd-party container has a test for a hashed UT involving
>>> this
>>> particular interceptor. No need to set the "ws-security.ut.no-callbacks",
>>> unless you have a wsdl-first case. Concrete implementations need to
>>> extend a
>>> method with several UT-related parameters which is a bit brittle in that
>>> adding more parameters to the
>>> AbstractUsernameTokenAuthenticatingInterceptor
>>> will break the users' interceptors.
>>>
>>> Thus extending AbstractUsernameTokenInterceptor (in rt/core/.../security)
>>> is
>>> recommended because we can easily update CXF UsernameToken bean with the
>>> new
>>> properties ((say the UT salt property, etc)) without the existing  users
>>> noticing.
>>>
>>> Debug it if you can - it would help
>>>
>>> Sergey
>>>
>>>
>>>
>>> On Thu, Feb 3, 2011 at 1:02 PM, Anand R <An...@ibsplc.com> wrote:
>>>
>>> > Hi Sergey,
>>> >
>>> > As you had mentioned earlier, the namespace is
>>> >
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> >
>>> > Please find the SOAP request message below.
>>> >
>>> > Actually, my requirement is to obtain the username and password from
>>> the
>>> > SOAP header to perform container authentication and then associate the
>>> > Subject with the current thread of execution. Am I using the correct
>>> > approach or do I just need to write a SOAPHeaderInterceptor and get the
>>> > required headers.
>>> >
>>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>>> >        <soap:Header>
>>> >                <wsse:Security soap:mustUnderstand="1"
>>> >                        xmlns:wsse="
>>> >
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> > ">
>>> >                         <wsse:UsernameToken xmlns:wsse="
>>> >
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> > "
>>> >                                 xmlns:wsu="
>>> >
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> > "
>>> >                                wsu:Id="UsernameToken-1">
>>> >                                <wsse:Username>libuser</wsse:Username>
>>> >                                <wsse:Password
>>> >                                        Type="
>>> >
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest
>>> > ">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password>
>>> >                                <wsse:Nonce     EncodingType="
>>> >
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
>>> > ">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce>
>>> >                                <wsu:Created>2011-02-03T12:32:27.752Z</
>>> > wsu:Created>
>>> >                        </wsse:UsernameToken>
>>> >                </wsse:Security>
>>> >        </soap:Header>
>>> >        <soap:Body>
>>> >                <ns2:doEcho xmlns:ns2="
>>> http://types.echo.wssecurity.learn/
>>> > ">
>>> >                        <arg0>
>>> >                                <echoString>Hello
>>> WS-Security</echoString>
>>> >                        </arg0>
>>> >                </ns2:doEcho>
>>> >        </soap:Body>
>>> > </soap:Envelope>
>>> > Thanks and regards,
>>> > Anand R
>>> >
>>> >
>>> >
>>> > From:   Sergey Beryozkin <sb...@gmail.com>
>>> > To:     users@cxf.apache.org
>>> > Date:   03-02-11 05:13 PM
>>> > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>>> >
>>> >
>>> >
>>> > Hi
>>> >
>>> > WSS4JInInterceptor is already registering a custom UT processor if the
>>> > "ws-security.ut.no-callbacks" is set to true.
>>> > So the hashed UTs should be supported with your configuration, without
>>> the
>>> > need to register a callback.
>>> > Can you give me a favor and check the actual WS-Security namespace that
>>> is
>>> > used to qualify the security header ? You can add a CXF logging feature
>>> to
>>> > the list of jaxws:features
>>> >
>>> > thanks, Sergey
>>> >
>>> > On Thu, Feb 3, 2011 at 11:33 AM, Anand R <An...@ibsplc.com>
>>> wrote:
>>> >
>>> > > Thanks Sergy. I will try the custom UsernameTokenProcessor.
>>> > > Thanks and regards,
>>> > > Anand R
>>> > >
>>> > >
>>> > >
>>> > > From:   Sergey Beryozkin <sb...@gmail.com>
>>> > > To:     users@cxf.apache.org
>>> > > Date:   03-02-11 04:39 PM
>>> > > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>>> > >
>>> > >
>>> > >
>>> > > Hi
>>> > >
>>> > > What WS-Security namespace is being used in the request ?
>>> > > If the "ws-security.ut.no-callbacks" is set to true then the
>>> > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not
>>> be
>>> > > invoked because it does currently require a callback for hashed UTs.
>>> So
>>> > if
>>> > > the property is set then the WSS4JInInterceptor registers a custom
>>> > > UsernameTokenProcessor for
>>> > >
>>> > > "
>>> > >
>>> > >
>>> >
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> >
>>> > >
>>> > > "
>>> > > and
>>> > > "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd
>>> ".
>>> > >
>>> > > Thanks, Sergey
>>> > >
>>> > > On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com>
>>> wrote:
>>> > >
>>> > > > Hi Sergey,
>>> > > >
>>> > > > Thanks for your response. I used to get the following exception
>>> when I
>>> > > did
>>> > > > not configure a callback handler. This exception does not come if
>>> the
>>> > > > password is plain text instead of a digest.
>>> > > >
>>> > > > org.apache.cxf.interceptor.Fault: General security error
>>> > > > (WSSecurityEngine: No password callback supplied)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
>>> > > >         at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>>> > > >        at
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>> > > >        at
>>> > > >
>>> > >
>>> >
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>>> > > >        at
>>> > > >
>>> > >
>>> >
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>>> > > >        at
>>> > > >
>>> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>>> > > >        at java.lang.Thread.run(Thread.java:595)
>>> > > > Caused by: org.apache.ws.security.WSSecurityException: General
>>> > security
>>> > > > error (WSSecurityEngine: No password callback supplied)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
>>> > > >        at
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
>>> > > >        ... 24 more
>>> > > >
>>> > > >
>>> > > > Thanks and regards,
>>> > > > Anand R
>>> > > > System Architect
>>> > > > IBS Software Services Private Limited
>>> > > > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum -
>>> > > 695581,
>>> > > > Kerala, India
>>> > > > Telephone - +91-471-6614291, Mobile - +91-9846324022
>>> > > > E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > From:   Sergey Beryozkin <sb...@gmail.com>
>>> > > > To:     users@cxf.apache.org
>>> > > > Date:   03-02-11 04:08 PM
>>> > > > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>>> > > >
>>> > > >
>>> > > >
>>> > > > Hi
>>> > > >
>>> > > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com>
>>> > wrote:
>>> > > >
>>> > > > > Hi,
>>> > > > >
>>> > > > > My requirement is to perform a custom authentication on the
>>> username
>>> > > and
>>> > > > > password that I receive as part of the UsernameToken header in
>>> the
>>> > > > > incoming SOAP request. I discovered that cxf-2.3.2 provides an
>>> > > > > AbstractUsernameTokenInInterceptor to perform this. I extended
>>> this
>>> > > > class
>>> > > > > and created my interceptor that overrides the createSubject
>>> method.
>>> > > When
>>> > > > I
>>> > > > > configure my interceptor in my beans.xml as shown below, I am
>>> > getting
>>> > > an
>>> > > > > exception.
>>> > > > >
>>> > > > > This exception comes up when I use a password digest. The plain
>>> text
>>> > > > > password works fine. Is there any problem in the way I have
>>> > configured
>>> > > > my
>>> > > > > interceptor?
>>> > > > >
>>> > > > >
>>> > > > > Entry in beans.xml
>>> > > > >
>>> > > > >        <jaxws:endpoint id="echo"
>>> > > > > implementor="learn.wssecurity.echo.EchoServiceImpl"
>>> > > > >                wsdlLocation="wsdl/echo/EchoService.wsdl"
>>> > > > > address="/EchoService">
>>> > > > >                <jaxws:inInterceptors>
>>> > > > >                          <bean
>>> > > > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
>>> > > > >                </jaxws:inInterceptors>
>>> > > > >                <jaxws:properties>
>>> > > > >                        <entry key="ws-security.callback-handler"
>>> > > > > value="learn.wssecurity.echo.ServerPasswordCallback" />
>>> > > > >                        <entry key="ws-security.ut.no-callbacks"
>>> > > > > value="true" />
>>> > > > >                </jaxws:properties>
>>> > > > >        </jaxws:endpoint>
>>> > > > >
>>> > > > >
>>> > > >
>>> > > > What is the purpose of registering ServerPasswordCallback ? If you
>>> set
>>> > a
>>> > > > "ws-security.ut.no-callbacks" property then you only need a
>>> callback
>>> > if
>>> > > > you
>>> > > > have an encrypted UT, so that the UT can be decrypted.
>>> > > > So this callback that you're registering may be interfering in the
>>> > case
>>> > > > when
>>> > > > you have a hashed UT token, can you remove it please and see what
>>> > > happens
>>> > > > ?
>>> > > >
>>> > > > Cheers, Sergey
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > >
>>> > > > > Exception
>>> > > > >
>>> > > > > java.lang.SecurityException: Security Token is not available on
>>> the
>>> > > > > current message
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
>>> > > > > 88)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>>> > > > >        at
>>> > javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>> > > > >        at
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>>> > > > >        at
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>>> > > > >        at
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>>> > > > >        at
>>> > > > >
>>> > >
>>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>>> > > > >        at java.lang.Thread.run(Thread.java:595)
>>> > > > >
>>> > > > > Thanks and regards,
>>> > > > > Anand R
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > DISCLAIMER:
>>> > > > >
>>> > > > > "The information in this e-mail and any attachment is intended
>>> only
>>> > > for
>>> > > > > the person to whom it is addressed and may contain confidential
>>> > and/or
>>> > > > > privileged material. If you have received this e-mail in error,
>>> > kindly
>>> > > > > contact the sender and destroy all copies of the original
>>> > > communication.
>>> > > > > IBS makes no warranty, express or implied, nor guarantees the
>>> > > accuracy,
>>> > > > > adequacy or completeness of the information contained in this
>>> email
>>> > or
>>> > > > any
>>> > > > > attachment and is not liable for any errors, defects, omissions,
>>> > > viruses
>>> > > > > or for resultant loss or damage, if any, direct or indirect."
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > DISCLAIMER:
>>> > > >
>>> > > > "The information in this e-mail and any attachment is intended only
>>> > for
>>> > > > the person to whom it is addressed and may contain confidential
>>> and/or
>>> > > > privileged material. If you have received this e-mail in error,
>>> kindly
>>> > > > contact the sender and destroy all copies of the original
>>> > communication.
>>> > > > IBS makes no warranty, express or implied, nor guarantees the
>>> > accuracy,
>>> > > > adequacy or completeness of the information contained in this email
>>> or
>>> > > any
>>> > > > attachment and is not liable for any errors, defects, omissions,
>>> > viruses
>>> > > > or for resultant loss or damage, if any, direct or indirect."
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > DISCLAIMER:
>>> > >
>>> > > "The information in this e-mail and any attachment is intended only
>>> for
>>> > > the person to whom it is addressed and may contain confidential
>>> and/or
>>> > > privileged material. If you have received this e-mail in error,
>>> kindly
>>> > > contact the sender and destroy all copies of the original
>>> communication.
>>> > > IBS makes no warranty, express or implied, nor guarantees the
>>> accuracy,
>>> > > adequacy or completeness of the information contained in this email
>>> or
>>> > any
>>> > > attachment and is not liable for any errors, defects, omissions,
>>> viruses
>>> > > or for resultant loss or damage, if any, direct or indirect."
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > DISCLAIMER:
>>> >
>>> > "The information in this e-mail and any attachment is intended only for
>>> > the person to whom it is addressed and may contain confidential and/or
>>> > privileged material. If you have received this e-mail in error, kindly
>>> > contact the sender and destroy all copies of the original
>>> communication.
>>> > IBS makes no warranty, express or implied, nor guarantees the accuracy,
>>> > adequacy or completeness of the information contained in this email or
>>> any
>>> > attachment and is not liable for any errors, defects, omissions,
>>> viruses
>>> > or for resultant loss or damage, if any, direct or indirect."
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> DISCLAIMER:
>>>
>>> "The information in this e-mail and any attachment is intended only for
>>> the person to whom it is addressed and may contain confidential and/or
>>> privileged material. If you have received this e-mail in error, kindly
>>> contact the sender and destroy all copies of the original communication. IBS
>>> makes no warranty, express or implied, nor guarantees the accuracy, adequacy
>>> or completeness of the information contained in this email or any attachment
>>> and is not liable for any errors, defects, omissions, viruses or for
>>> resultant loss or damage, if any, direct or indirect."
>>>
>>>
>>>
>>>
>>>
>>
>

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Sergey Beryozkin <sb...@gmail.com>.

Actually, I may be understanding why it's not working for you.

So if you have a policy embedded in WSDL and PolicyBasedWSS4JInInterceptor
usually does all the work. However, if it's only a UsernameToken policy that
is used then UsernameTokenInterceptor is used to do the actual processing,
as an optimization.

So here is a summary :
1. WSS4JInInterceptor is configured directly in java-first cases
2. PolicyBasedWSS4JInInterceptor is used when the policy is embedded in WSDL
3. UsernameTokenInterceptor is used when the policy which is embedded in
WSDL contains only a UT assertion

As it happens, the "ws-security.ut.no-callbacks" property is ignored in case
3.
Can you add yet another breakpoint in UsernameTokenInterceptor ? If you
confirm UsernameTokenInterceptor is used then I'll let you know how to
intercept the flow with a UsernameTokenInterceptor subclass (hack really)
and will do a minor fix to ensure the "ws-security.ut.no-callbacks" works
for 3. as well

Cheers, Sergey

On Fri, Feb 4, 2011 at 11:52 AM, Sergey Beryozkin <sb...@gmail.com>wrote:

> Hi Anand
>
> On Fri, Feb 4, 2011 at 6:50 AM, Anand R <An...@ibsplc.com> wrote:
>
>> Hi Sergey,
>>
>> As you mentioned, I added a breakpoint within
>> WSS4JInInterceptor.handleMessage(). The web service invocation didn't
>>  hit the breakpoint.
>> WSS4JInInterceptor wasn't present in the chain of interceptors. I added
>> this interceptor explicitly in my beans.xml.
>>
>
>
> I think I know what is happening. Given a policy is contained in WSDL,
> PolicyBasedWSS4JInInterceptor is used, it extends WSS4JInInterceptor, CXF
> adds it itself. Can you give it another try please, remove the explicit
> WSS4JInInterceptor and add a breakpoint in
> PolicyBasedWSS4JInInterceptor.handleMessage ?
>
>
> Now I am getting the following exception.
>>
>> I also tried extending AbstractUsernameTokenAuthenticatingInterceptor. I
>> am getting the same exception(No security action was defined!).
>> I tried setting ws-security.ut.no-callbacks on and off. Both result in the
>> same exception.
>>
>> I didn't understand what action is being referred here. I am attaching my
>> wsdl for your reference. Is this problem anything to do with my policy
>> specification?
>>
>> The wsdl is fine. As I briefly mentioned, the older AbstractUsernameTokenAuthenticatingInterceptor
> does not work well with the wsdl first case. It is actually a WSS4JInInterceptor
> subclass and does all sort of hacks to hide the complexity from the user and
> provide an (unwrapped) UT to the concrete implementations. However
> PolicyBasedWSS4JInInterceptor is used instead when the actions are
> 'embedded' inside a given policy, so registering
> AbstractUsernameTokenAuthenticatingInterceptor duplicates PolicyBasedWSS4JInInterceptor
> (you still need to configure the actions even though
> PolicyBasedWSS4JInInterceptor knows them from WSDL). I updated it to
> continue working in the wsdl-first case (provided the no-callbacks property
> is set) just to minimize the side-effects for the users already doing
> concrete AbstractUsernameTokenAuthenticatingInterceptor impls. AbstractUsernameTokenAuthenticatingInterceptor
> is ok for java-first cases but the newer AbstractUsernameTokenInterceptor
> will work for all the cases.
>
> Check please PolicyBasedWSS4JInInterceptor.handleMessage
>
> thanks, Sergey
>
>
>>
>>
>> org.apache.cxf.binding.soap.SoapFault: No security action was defined!
>>         at
>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getAction(WSS4JInInterceptor.java:471)
>>         at
>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:196)
>>         at
>> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:96)
>>         at
>> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:67)
>>         at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>>         at
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>>         at
>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>>         at
>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>>         at
>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>>         at
>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>>         at
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>>         at
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>>         at
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>         at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>>         at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>>         at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>         at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>>         at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>         at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>>         at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>>         at
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>>         at
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>>         at java.lang.Thread.run(Thread.java:595)
>>
>>
>> Thanks and regards,
>> Anand
>>
>>
>>
>> From:        Sergey Beryozkin <sb...@gmail.com>
>> To:        users@cxf.apache.org
>> Date:        03-02-11 07:28 PM
>> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>> ------------------------------
>>
>>
>>
>> Hi - I do not understand why it not works. I've checked the code and I see
>> that no test involving a hashed password exists. Likewise I don't
>> understand
>> why it works at the same time with clear passwords and no callbacks.
>> I'm a bit busy right now, is there any chance that you could download the
>> source for CXF 2.3.2, remove the ServerCallback property and just add a
>> breakpoint in WSS4JInInterceptor.handleMessage() ?
>>
>> I think you're on the right track. I do not see other options for dealing
>> with *hashed passwords*, well, unless you;re prepared to do some hacks by
>> doing the container-managed authentication from the callback itself but
>> that
>> would not let you register the proper security context because the one
>> which
>> is created by the WSS4JInInterceptor has only a (WSS4J-created) Principal
>> registered, i.e, no info about roles is available.
>>
>> I'd definitely follow this route myself.
>> Note that AbstractUsernameTokenAuthenticatingInterceptor (in the
>> ws-security
>> module) is the other, legacy interceptor that you may also extend - as far
>> as I know, a 3rd-party container has a test for a hashed UT involving this
>> particular interceptor. No need to set the "ws-security.ut.no-callbacks",
>> unless you have a wsdl-first case. Concrete implementations need to extend
>> a
>> method with several UT-related parameters which is a bit brittle in that
>> adding more parameters to the
>> AbstractUsernameTokenAuthenticatingInterceptor
>> will break the users' interceptors.
>>
>> Thus extending AbstractUsernameTokenInterceptor (in rt/core/.../security)
>> is
>> recommended because we can easily update CXF UsernameToken bean with the
>> new
>> properties ((say the UT salt property, etc)) without the existing  users
>> noticing.
>>
>> Debug it if you can - it would help
>>
>> Sergey
>>
>>
>>
>> On Thu, Feb 3, 2011 at 1:02 PM, Anand R <An...@ibsplc.com> wrote:
>>
>> > Hi Sergey,
>> >
>> > As you had mentioned earlier, the namespace is
>> >
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> >
>> > Please find the SOAP request message below.
>> >
>> > Actually, my requirement is to obtain the username and password from the
>> > SOAP header to perform container authentication and then associate the
>> > Subject with the current thread of execution. Am I using the correct
>> > approach or do I just need to write a SOAPHeaderInterceptor and get the
>> > required headers.
>> >
>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> >        <soap:Header>
>> >                <wsse:Security soap:mustUnderstand="1"
>> >                        xmlns:wsse="
>> >
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> > ">
>> >                         <wsse:UsernameToken xmlns:wsse="
>> >
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> > "
>> >                                 xmlns:wsu="
>> >
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> > "
>> >                                wsu:Id="UsernameToken-1">
>> >                                <wsse:Username>libuser</wsse:Username>
>> >                                <wsse:Password
>> >                                        Type="
>> >
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest
>> > ">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password>
>> >                                <wsse:Nonce     EncodingType="
>> >
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
>> > ">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce>
>> >                                <wsu:Created>2011-02-03T12:32:27.752Z</
>> > wsu:Created>
>> >                        </wsse:UsernameToken>
>> >                </wsse:Security>
>> >        </soap:Header>
>> >        <soap:Body>
>> >                <ns2:doEcho xmlns:ns2="
>> http://types.echo.wssecurity.learn/
>> > ">
>> >                        <arg0>
>> >                                <echoString>Hello
>> WS-Security</echoString>
>> >                        </arg0>
>> >                </ns2:doEcho>
>> >        </soap:Body>
>> > </soap:Envelope>
>> > Thanks and regards,
>> > Anand R
>> >
>> >
>> >
>> > From:   Sergey Beryozkin <sb...@gmail.com>
>> > To:     users@cxf.apache.org
>> > Date:   03-02-11 05:13 PM
>> > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>> >
>> >
>> >
>> > Hi
>> >
>> > WSS4JInInterceptor is already registering a custom UT processor if the
>> > "ws-security.ut.no-callbacks" is set to true.
>> > So the hashed UTs should be supported with your configuration, without
>> the
>> > need to register a callback.
>> > Can you give me a favor and check the actual WS-Security namespace that
>> is
>> > used to qualify the security header ? You can add a CXF logging feature
>> to
>> > the list of jaxws:features
>> >
>> > thanks, Sergey
>> >
>> > On Thu, Feb 3, 2011 at 11:33 AM, Anand R <An...@ibsplc.com>
>> wrote:
>> >
>> > > Thanks Sergy. I will try the custom UsernameTokenProcessor.
>> > > Thanks and regards,
>> > > Anand R
>> > >
>> > >
>> > >
>> > > From:   Sergey Beryozkin <sb...@gmail.com>
>> > > To:     users@cxf.apache.org
>> > > Date:   03-02-11 04:39 PM
>> > > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>> > >
>> > >
>> > >
>> > > Hi
>> > >
>> > > What WS-Security namespace is being used in the request ?
>> > > If the "ws-security.ut.no-callbacks" is set to true then the
>> > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not
>> be
>> > > invoked because it does currently require a callback for hashed UTs.
>> So
>> > if
>> > > the property is set then the WSS4JInInterceptor registers a custom
>> > > UsernameTokenProcessor for
>> > >
>> > > "
>> > >
>> > >
>> >
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> >
>> > >
>> > > "
>> > > and
>> > > "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd".
>> > >
>> > > Thanks, Sergey
>> > >
>> > > On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com>
>> wrote:
>> > >
>> > > > Hi Sergey,
>> > > >
>> > > > Thanks for your response. I used to get the following exception when
>> I
>> > > did
>> > > > not configure a callback handler. This exception does not come if
>> the
>> > > > password is plain text instead of a digest.
>> > > >
>> > > > org.apache.cxf.interceptor.Fault: General security error
>> > > > (WSSecurityEngine: No password callback supplied)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
>> > > >         at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>> > > >        at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>> > > >        at
>> > > >
>> > >
>> >
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>> > > >        at
>> > > >
>> > >
>> >
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>> > > >        at
>> > > >
>> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>> > > >        at java.lang.Thread.run(Thread.java:595)
>> > > > Caused by: org.apache.ws.security.WSSecurityException: General
>> > security
>> > > > error (WSSecurityEngine: No password callback supplied)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
>> > > >        at
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
>> > > >        ... 24 more
>> > > >
>> > > >
>> > > > Thanks and regards,
>> > > > Anand R
>> > > > System Architect
>> > > > IBS Software Services Private Limited
>> > > > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum -
>> > > 695581,
>> > > > Kerala, India
>> > > > Telephone - +91-471-6614291, Mobile - +91-9846324022
>> > > > E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > From:   Sergey Beryozkin <sb...@gmail.com>
>> > > > To:     users@cxf.apache.org
>> > > > Date:   03-02-11 04:08 PM
>> > > > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>> > > >
>> > > >
>> > > >
>> > > > Hi
>> > > >
>> > > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com>
>> > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > My requirement is to perform a custom authentication on the
>> username
>> > > and
>> > > > > password that I receive as part of the UsernameToken header in the
>> > > > > incoming SOAP request. I discovered that cxf-2.3.2 provides an
>> > > > > AbstractUsernameTokenInInterceptor to perform this. I extended
>> this
>> > > > class
>> > > > > and created my interceptor that overrides the createSubject
>> method.
>> > > When
>> > > > I
>> > > > > configure my interceptor in my beans.xml as shown below, I am
>> > getting
>> > > an
>> > > > > exception.
>> > > > >
>> > > > > This exception comes up when I use a password digest. The plain
>> text
>> > > > > password works fine. Is there any problem in the way I have
>> > configured
>> > > > my
>> > > > > interceptor?
>> > > > >
>> > > > >
>> > > > > Entry in beans.xml
>> > > > >
>> > > > >        <jaxws:endpoint id="echo"
>> > > > > implementor="learn.wssecurity.echo.EchoServiceImpl"
>> > > > >                wsdlLocation="wsdl/echo/EchoService.wsdl"
>> > > > > address="/EchoService">
>> > > > >                <jaxws:inInterceptors>
>> > > > >                          <bean
>> > > > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
>> > > > >                </jaxws:inInterceptors>
>> > > > >                <jaxws:properties>
>> > > > >                        <entry key="ws-security.callback-handler"
>> > > > > value="learn.wssecurity.echo.ServerPasswordCallback" />
>> > > > >                        <entry key="ws-security.ut.no-callbacks"
>> > > > > value="true" />
>> > > > >                </jaxws:properties>
>> > > > >        </jaxws:endpoint>
>> > > > >
>> > > > >
>> > > >
>> > > > What is the purpose of registering ServerPasswordCallback ? If you
>> set
>> > a
>> > > > "ws-security.ut.no-callbacks" property then you only need a callback
>> > if
>> > > > you
>> > > > have an encrypted UT, so that the UT can be decrypted.
>> > > > So this callback that you're registering may be interfering in the
>> > case
>> > > > when
>> > > > you have a hashed UT token, can you remove it please and see what
>> > > happens
>> > > > ?
>> > > >
>> > > > Cheers, Sergey
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > >
>> > > > > Exception
>> > > > >
>> > > > > java.lang.SecurityException: Security Token is not available on
>> the
>> > > > > current message
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
>> > > > > 88)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>> > > > >        at
>> > javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>> > > > >        at
>> > > > >
>> > > >
>> > >
>> >
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>> > > > >        at
>> > > > >
>> > > >
>> > >
>> >
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>> > > > >        at
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>> > > > >        at
>> > > > >
>> > >
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>> > > > >        at java.lang.Thread.run(Thread.java:595)
>> > > > >
>> > > > > Thanks and regards,
>> > > > > Anand R
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > DISCLAIMER:
>> > > > >
>> > > > > "The information in this e-mail and any attachment is intended
>> only
>> > > for
>> > > > > the person to whom it is addressed and may contain confidential
>> > and/or
>> > > > > privileged material. If you have received this e-mail in error,
>> > kindly
>> > > > > contact the sender and destroy all copies of the original
>> > > communication.
>> > > > > IBS makes no warranty, express or implied, nor guarantees the
>> > > accuracy,
>> > > > > adequacy or completeness of the information contained in this
>> email
>> > or
>> > > > any
>> > > > > attachment and is not liable for any errors, defects, omissions,
>> > > viruses
>> > > > > or for resultant loss or damage, if any, direct or indirect."
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > DISCLAIMER:
>> > > >
>> > > > "The information in this e-mail and any attachment is intended only
>> > for
>> > > > the person to whom it is addressed and may contain confidential
>> and/or
>> > > > privileged material. If you have received this e-mail in error,
>> kindly
>> > > > contact the sender and destroy all copies of the original
>> > communication.
>> > > > IBS makes no warranty, express or implied, nor guarantees the
>> > accuracy,
>> > > > adequacy or completeness of the information contained in this email
>> or
>> > > any
>> > > > attachment and is not liable for any errors, defects, omissions,
>> > viruses
>> > > > or for resultant loss or damage, if any, direct or indirect."
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > DISCLAIMER:
>> > >
>> > > "The information in this e-mail and any attachment is intended only
>> for
>> > > the person to whom it is addressed and may contain confidential and/or
>> > > privileged material. If you have received this e-mail in error, kindly
>> > > contact the sender and destroy all copies of the original
>> communication.
>> > > IBS makes no warranty, express or implied, nor guarantees the
>> accuracy,
>> > > adequacy or completeness of the information contained in this email or
>> > any
>> > > attachment and is not liable for any errors, defects, omissions,
>> viruses
>> > > or for resultant loss or damage, if any, direct or indirect."
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > DISCLAIMER:
>> >
>> > "The information in this e-mail and any attachment is intended only for
>> > the person to whom it is addressed and may contain confidential and/or
>> > privileged material. If you have received this e-mail in error, kindly
>> > contact the sender and destroy all copies of the original communication.
>> > IBS makes no warranty, express or implied, nor guarantees the accuracy,
>> > adequacy or completeness of the information contained in this email or
>> any
>> > attachment and is not liable for any errors, defects, omissions, viruses
>> > or for resultant loss or damage, if any, direct or indirect."
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>>
>>
>>
>> DISCLAIMER:
>>
>> "The information in this e-mail and any attachment is intended only for
>> the person to whom it is addressed and may contain confidential and/or
>> privileged material. If you have received this e-mail in error, kindly
>> contact the sender and destroy all copies of the original communication. IBS
>> makes no warranty, express or implied, nor guarantees the accuracy, adequacy
>> or completeness of the information contained in this email or any attachment
>> and is not liable for any errors, defects, omissions, viruses or for
>> resultant loss or damage, if any, direct or indirect."
>>
>>
>>
>>
>>
>

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi Anand

On Fri, Feb 4, 2011 at 6:50 AM, Anand R <An...@ibsplc.com> wrote:

> Hi Sergey,
>
> As you mentioned, I added a breakpoint within
> WSS4JInInterceptor.handleMessage(). The web service invocation didn't  hit
> the breakpoint.
> WSS4JInInterceptor wasn't present in the chain of interceptors. I added
> this interceptor explicitly in my beans.xml.



I think I know what is happening. Given a policy is contained in WSDL,
PolicyBasedWSS4JInInterceptor is used, it extends WSS4JInInterceptor, CXF
adds it itself. Can you give it another try please, remove the explicit
WSS4JInInterceptor and add a breakpoint in
PolicyBasedWSS4JInInterceptor.handleMessage ?


Now I am getting the following exception.
>
> I also tried extending AbstractUsernameTokenAuthenticatingInterceptor. I
> am getting the same exception(No security action was defined!).
> I tried setting ws-security.ut.no-callbacks on and off. Both result in the
> same exception.
>
> I didn't understand what action is being referred here. I am attaching my
> wsdl for your reference. Is this problem anything to do with my policy
> specification?
>
> The wsdl is fine. As I briefly mentioned, the older AbstractUsernameTokenAuthenticatingInterceptor
does not work well with the wsdl first case. It is actually a
WSS4JInInterceptor
subclass and does all sort of hacks to hide the complexity from the user and
provide an (unwrapped) UT to the concrete implementations. However
PolicyBasedWSS4JInInterceptor is used instead when the actions are
'embedded' inside a given policy, so registering
AbstractUsernameTokenAuthenticatingInterceptor duplicates
PolicyBasedWSS4JInInterceptor
(you still need to configure the actions even though
PolicyBasedWSS4JInInterceptor knows them from WSDL). I updated it to
continue working in the wsdl-first case (provided the no-callbacks property
is set) just to minimize the side-effects for the users already doing
concrete AbstractUsernameTokenAuthenticatingInterceptor impls.
AbstractUsernameTokenAuthenticatingInterceptor
is ok for java-first cases but the newer AbstractUsernameTokenInterceptor
will work for all the cases.

Check please PolicyBasedWSS4JInInterceptor.handleMessage

thanks, Sergey


>
>
> org.apache.cxf.binding.soap.SoapFault: No security action was defined!
>         at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getAction(WSS4JInInterceptor.java:471)
>         at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:196)
>         at
> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:96)
>         at
> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:67)
>         at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>         at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>         at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>         at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>         at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>         at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>         at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>         at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>         at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>         at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>         at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>         at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>         at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>         at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>         at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>         at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>         at java.lang.Thread.run(Thread.java:595)
>
>
> Thanks and regards,
> Anand
>
>
>
> From:        Sergey Beryozkin <sb...@gmail.com>
> To:        users@cxf.apache.org
> Date:        03-02-11 07:28 PM
> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> ------------------------------
>
>
>
> Hi - I do not understand why it not works. I've checked the code and I see
> that no test involving a hashed password exists. Likewise I don't
> understand
> why it works at the same time with clear passwords and no callbacks.
> I'm a bit busy right now, is there any chance that you could download the
> source for CXF 2.3.2, remove the ServerCallback property and just add a
> breakpoint in WSS4JInInterceptor.handleMessage() ?
>
> I think you're on the right track. I do not see other options for dealing
> with *hashed passwords*, well, unless you;re prepared to do some hacks by
> doing the container-managed authentication from the callback itself but
> that
> would not let you register the proper security context because the one
> which
> is created by the WSS4JInInterceptor has only a (WSS4J-created) Principal
> registered, i.e, no info about roles is available.
>
> I'd definitely follow this route myself.
> Note that AbstractUsernameTokenAuthenticatingInterceptor (in the
> ws-security
> module) is the other, legacy interceptor that you may also extend - as far
> as I know, a 3rd-party container has a test for a hashed UT involving this
> particular interceptor. No need to set the "ws-security.ut.no-callbacks",
> unless you have a wsdl-first case. Concrete implementations need to extend
> a
> method with several UT-related parameters which is a bit brittle in that
> adding more parameters to the
> AbstractUsernameTokenAuthenticatingInterceptor
> will break the users' interceptors.
>
> Thus extending AbstractUsernameTokenInterceptor (in rt/core/.../security)
> is
> recommended because we can easily update CXF UsernameToken bean with the
> new
> properties ((say the UT salt property, etc)) without the existing  users
> noticing.
>
> Debug it if you can - it would help
>
> Sergey
>
>
>
> On Thu, Feb 3, 2011 at 1:02 PM, Anand R <An...@ibsplc.com> wrote:
>
> > Hi Sergey,
> >
> > As you had mentioned earlier, the namespace is
> >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >
> > Please find the SOAP request message below.
> >
> > Actually, my requirement is to obtain the username and password from the
> > SOAP header to perform container authentication and then associate the
> > Subject with the current thread of execution. Am I using the correct
> > approach or do I just need to write a SOAPHeaderInterceptor and get the
> > required headers.
> >
> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> >        <soap:Header>
> >                <wsse:Security soap:mustUnderstand="1"
> >                        xmlns:wsse="
> >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> > ">
> >                         <wsse:UsernameToken xmlns:wsse="
> >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> > "
> >                                 xmlns:wsu="
> >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> > "
> >                                wsu:Id="UsernameToken-1">
> >                                <wsse:Username>libuser</wsse:Username>
> >                                <wsse:Password
> >                                        Type="
> >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest
> > ">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password>
> >                                <wsse:Nonce     EncodingType="
> >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
> > ">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce>
> >                                <wsu:Created>2011-02-03T12:32:27.752Z</
> > wsu:Created>
> >                        </wsse:UsernameToken>
> >                </wsse:Security>
> >        </soap:Header>
> >        <soap:Body>
> >                <ns2:doEcho xmlns:ns2="
> http://types.echo.wssecurity.learn/
> > ">
> >                        <arg0>
> >                                <echoString>Hello WS-Security</echoString>
> >                        </arg0>
> >                </ns2:doEcho>
> >        </soap:Body>
> > </soap:Envelope>
> > Thanks and regards,
> > Anand R
> >
> >
> >
> > From:   Sergey Beryozkin <sb...@gmail.com>
> > To:     users@cxf.apache.org
> > Date:   03-02-11 05:13 PM
> > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> >
> >
> >
> > Hi
> >
> > WSS4JInInterceptor is already registering a custom UT processor if the
> > "ws-security.ut.no-callbacks" is set to true.
> > So the hashed UTs should be supported with your configuration, without
> the
> > need to register a callback.
> > Can you give me a favor and check the actual WS-Security namespace that
> is
> > used to qualify the security header ? You can add a CXF logging feature
> to
> > the list of jaxws:features
> >
> > thanks, Sergey
> >
> > On Thu, Feb 3, 2011 at 11:33 AM, Anand R <An...@ibsplc.com> wrote:
> >
> > > Thanks Sergy. I will try the custom UsernameTokenProcessor.
> > > Thanks and regards,
> > > Anand R
> > >
> > >
> > >
> > > From:   Sergey Beryozkin <sb...@gmail.com>
> > > To:     users@cxf.apache.org
> > > Date:   03-02-11 04:39 PM
> > > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> > >
> > >
> > >
> > > Hi
> > >
> > > What WS-Security namespace is being used in the request ?
> > > If the "ws-security.ut.no-callbacks" is set to true then the
> > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not be
> > > invoked because it does currently require a callback for hashed UTs. So
> > if
> > > the property is set then the WSS4JInInterceptor registers a custom
> > > UsernameTokenProcessor for
> > >
> > > "
> > >
> > >
> >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >
> > >
> > > "
> > > and
> > > "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd".
> > >
> > > Thanks, Sergey
> > >
> > > On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com>
> wrote:
> > >
> > > > Hi Sergey,
> > > >
> > > > Thanks for your response. I used to get the following exception when
> I
> > > did
> > > > not configure a callback handler. This exception does not come if the
> > > > password is plain text instead of a digest.
> > > >
> > > > org.apache.cxf.interceptor.Fault: General security error
> > > > (WSSecurityEngine: No password callback supplied)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
> > > >         at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> > > >        at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > > >        at
> > > >
> > >
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> > > >        at
> > > >
> > >
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> > > >        at
> > > >
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> > > >        at java.lang.Thread.run(Thread.java:595)
> > > > Caused by: org.apache.ws.security.WSSecurityException: General
> > security
> > > > error (WSSecurityEngine: No password callback supplied)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
> > > >        ... 24 more
> > > >
> > > >
> > > > Thanks and regards,
> > > > Anand R
> > > > System Architect
> > > > IBS Software Services Private Limited
> > > > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum -
> > > 695581,
> > > > Kerala, India
> > > > Telephone - +91-471-6614291, Mobile - +91-9846324022
> > > > E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
> > > >
> > > >
> > > >
> > > >
> > > > From:   Sergey Beryozkin <sb...@gmail.com>
> > > > To:     users@cxf.apache.org
> > > > Date:   03-02-11 04:08 PM
> > > > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> > > >
> > > >
> > > >
> > > > Hi
> > > >
> > > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com>
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > My requirement is to perform a custom authentication on the
> username
> > > and
> > > > > password that I receive as part of the UsernameToken header in the
> > > > > incoming SOAP request. I discovered that cxf-2.3.2 provides an
> > > > > AbstractUsernameTokenInInterceptor to perform this. I extended this
> > > > class
> > > > > and created my interceptor that overrides the createSubject method.
> > > When
> > > > I
> > > > > configure my interceptor in my beans.xml as shown below, I am
> > getting
> > > an
> > > > > exception.
> > > > >
> > > > > This exception comes up when I use a password digest. The plain
> text
> > > > > password works fine. Is there any problem in the way I have
> > configured
> > > > my
> > > > > interceptor?
> > > > >
> > > > >
> > > > > Entry in beans.xml
> > > > >
> > > > >        <jaxws:endpoint id="echo"
> > > > > implementor="learn.wssecurity.echo.EchoServiceImpl"
> > > > >                wsdlLocation="wsdl/echo/EchoService.wsdl"
> > > > > address="/EchoService">
> > > > >                <jaxws:inInterceptors>
> > > > >                          <bean
> > > > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
> > > > >                </jaxws:inInterceptors>
> > > > >                <jaxws:properties>
> > > > >                        <entry key="ws-security.callback-handler"
> > > > > value="learn.wssecurity.echo.ServerPasswordCallback" />
> > > > >                        <entry key="ws-security.ut.no-callbacks"
> > > > > value="true" />
> > > > >                </jaxws:properties>
> > > > >        </jaxws:endpoint>
> > > > >
> > > > >
> > > >
> > > > What is the purpose of registering ServerPasswordCallback ? If you
> set
> > a
> > > > "ws-security.ut.no-callbacks" property then you only need a callback
> > if
> > > > you
> > > > have an encrypted UT, so that the UT can be decrypted.
> > > > So this callback that you're registering may be interfering in the
> > case
> > > > when
> > > > you have a hashed UT token, can you remove it please and see what
> > > happens
> > > > ?
> > > >
> > > > Cheers, Sergey
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Exception
> > > > >
> > > > > java.lang.SecurityException: Security Token is not available on the
> > > > > current message
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> > > > > 88)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> > > > >        at
> > javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > > > >        at
> > > > >
> > > >
> > >
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> > > > >        at
> > > > >
> > > >
> > >
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> > > > >        at
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> > > > >        at
> > > > >
> > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> > > > >        at java.lang.Thread.run(Thread.java:595)
> > > > >
> > > > > Thanks and regards,
> > > > > Anand R
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > DISCLAIMER:
> > > > >
> > > > > "The information in this e-mail and any attachment is intended only
> > > for
> > > > > the person to whom it is addressed and may contain confidential
> > and/or
> > > > > privileged material. If you have received this e-mail in error,
> > kindly
> > > > > contact the sender and destroy all copies of the original
> > > communication.
> > > > > IBS makes no warranty, express or implied, nor guarantees the
> > > accuracy,
> > > > > adequacy or completeness of the information contained in this email
> > or
> > > > any
> > > > > attachment and is not liable for any errors, defects, omissions,
> > > viruses
> > > > > or for resultant loss or damage, if any, direct or indirect."
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > DISCLAIMER:
> > > >
> > > > "The information in this e-mail and any attachment is intended only
> > for
> > > > the person to whom it is addressed and may contain confidential
> and/or
> > > > privileged material. If you have received this e-mail in error,
> kindly
> > > > contact the sender and destroy all copies of the original
> > communication.
> > > > IBS makes no warranty, express or implied, nor guarantees the
> > accuracy,
> > > > adequacy or completeness of the information contained in this email
> or
> > > any
> > > > attachment and is not liable for any errors, defects, omissions,
> > viruses
> > > > or for resultant loss or damage, if any, direct or indirect."
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > DISCLAIMER:
> > >
> > > "The information in this e-mail and any attachment is intended only for
> > > the person to whom it is addressed and may contain confidential and/or
> > > privileged material. If you have received this e-mail in error, kindly
> > > contact the sender and destroy all copies of the original
> communication.
> > > IBS makes no warranty, express or implied, nor guarantees the accuracy,
> > > adequacy or completeness of the information contained in this email or
> > any
> > > attachment and is not liable for any errors, defects, omissions,
> viruses
> > > or for resultant loss or damage, if any, direct or indirect."
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> > DISCLAIMER:
> >
> > "The information in this e-mail and any attachment is intended only for
> > the person to whom it is addressed and may contain confidential and/or
> > privileged material. If you have received this e-mail in error, kindly
> > contact the sender and destroy all copies of the original communication.
> > IBS makes no warranty, express or implied, nor guarantees the accuracy,
> > adequacy or completeness of the information contained in this email or
> any
> > attachment and is not liable for any errors, defects, omissions, viruses
> > or for resultant loss or damage, if any, direct or indirect."
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for the
> person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication. IBS
> makes no warranty, express or implied, nor guarantees the accuracy, adequacy
> or completeness of the information contained in this email or any attachment
> and is not liable for any errors, defects, omissions, viruses or for
> resultant loss or damage, if any, direct or indirect."
>
>
>
>
>

Re: Building REST style web services

Posted by Celinio <ce...@yahoo.com>.

Thanks, I just found out this alternative way indeed.

--- On Fri, 2/4/11, Sergey Beryozkin <sb...@gmail.com> wrote:

From: Sergey Beryozkin <sb...@gmail.com>
Subject: Re: Building REST style web services
To: users@cxf.apache.org
Date: Friday, February 4, 2011, 3:14 AM

Hi

On Fri, Feb 4, 2011 at 8:51 AM, Celinio <ce...@yahoo.com> wrote:

> Building REST style web services
>
> Hi,
> I am a bit new to CXF and wondering what is the recommended way to build
> REST style web services with CXF now.
>
> I simply decorated my method with the @Get and @HttpResource annotations:
>
>     @WebService
> public interface IBMICalculator {
>
>     @Get
>     @HttpResource(location = "/computeBMI/{weight}/{height}")
>     public  double computeBMI(@WebParam(name="weight") double weight,
> @WebParam(name="height") double height) ;
> }
>
> I imported the binding extension xml file in my spring xml configuration
> file, cxf.xml:
> <import resource="classpath:META-INF/cxf/cxf-extension-http-binding.xml"/>
>
> And i declared an endpoint :
>  <jaxws:endpoint id="calcBMI"
>                   implementor="com.company.bmi.services.IBMICalculatorImpl"
>                   address="/cxfBmi"
>                   bindingUri="http://apache.org/cxf/binding/http">
>                   <jaxws:serviceFactory>
>            <bean
> class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean">
>                <property name="wrapped" value="true" />
>            </bean>
>        </jaxws:serviceFactory>
>    </jaxws:endpoint>
>

Here's an alternative approach, using JAX-RS

@Path("/")
public interface IBMICalculator {

    @GET
    @Path("/computeBMI/{weight}/{height}")
    @Produces("text/plain")
    public  double computeBMI(@QueryParam("weight") double weight,
@QueryParam("height") double height) ;
}

<import resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml"/>

<jaxrs:endpoint serviceClass="com.company.bmi.services.IBMICalculatorImp
                          address="/cxfBmi"/>

though the endpoint declaration may be more involved.


>
> It works like a charm. However I read that "This binding has been
> deprecated and is likely to be removed from CXF in one of its future
> releases"
> https://cwiki.apache.org/CXF20DOC/http-binding.html
>
>
the reason it was deprecated was that it was maintained and unlikely to be
maintained


> So what is the recommanded way to build REST style web services with CXF
> now ?
>

Please see the JAX-RS section : http://cxf.apache.org/docs/jax-rs.html

The only restriction of JAX-RS compared to the HTTP binding is that no
wrapping/unwrapping is supported. Example,

@Produces("text/plain")
 public  double computeBMI(@QueryParam("weight") double weight,
@QueryParam("height") double height) ;

@Produces("text/plain") is the hint to the runtime that the 'double'
response value needs to be returned as is, without wrapping into something
like
<response>12.3</response>

If the response wrapping is needed then a custom JAX-RS provider can easily
deal with wrapping the response.

However, if we had say

@Consumes("text/xml")
@POST
public  void addItem(double weight, double height) ;

where the weight and height are not query parameters but have been unwrapped
from XML such as

<item>
<weight>123</weight>
<height>123</height>
</item>

then it definitely won't work in JAX-RS.
Having

@Consumes("text/xml")
@POST
public  void addItem(Item item) ;

will do better....


Hope that helps, Sergey


> Thanks for helping.
>
>
>

Re: Building REST style web services

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi

On Fri, Feb 4, 2011 at 8:51 AM, Celinio <ce...@yahoo.com> wrote:

> Building REST style web services
>
> Hi,
> I am a bit new to CXF and wondering what is the recommended way to build
> REST style web services with CXF now.
>
> I simply decorated my method with the @Get and @HttpResource annotations:
>
>     @WebService
> public interface IBMICalculator {
>
>     @Get
>     @HttpResource(location = "/computeBMI/{weight}/{height}")
>     public  double computeBMI(@WebParam(name="weight") double weight,
> @WebParam(name="height") double height) ;
> }
>
> I imported the binding extension xml file in my spring xml configuration
> file, cxf.xml:
> <import resource="classpath:META-INF/cxf/cxf-extension-http-binding.xml"/>
>
> And i declared an endpoint :
>  <jaxws:endpoint id="calcBMI"
>                   implementor="com.company.bmi.services.IBMICalculatorImpl"
>                   address="/cxfBmi"
>                   bindingUri="http://apache.org/cxf/binding/http">
>                   <jaxws:serviceFactory>
>            <bean
> class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean">
>                <property name="wrapped" value="true" />
>            </bean>
>        </jaxws:serviceFactory>
>    </jaxws:endpoint>
>

Here's an alternative approach, using JAX-RS

@Path("/")
public interface IBMICalculator {

    @GET
    @Path("/computeBMI/{weight}/{height}")
    @Produces("text/plain")
    public  double computeBMI(@QueryParam("weight") double weight,
@QueryParam("height") double height) ;
}

<import resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml"/>

<jaxrs:endpoint serviceClass="com.company.bmi.services.IBMICalculatorImp
                          address="/cxfBmi"/>

though the endpoint declaration may be more involved.


>
> It works like a charm. However I read that "This binding has been
> deprecated and is likely to be removed from CXF in one of its future
> releases"
> https://cwiki.apache.org/CXF20DOC/http-binding.html
>
>
the reason it was deprecated was that it was maintained and unlikely to be
maintained


> So what is the recommanded way to build REST style web services with CXF
> now ?
>

Please see the JAX-RS section : http://cxf.apache.org/docs/jax-rs.html

The only restriction of JAX-RS compared to the HTTP binding is that no
wrapping/unwrapping is supported. Example,

@Produces("text/plain")
 public  double computeBMI(@QueryParam("weight") double weight,
@QueryParam("height") double height) ;

@Produces("text/plain") is the hint to the runtime that the 'double'
response value needs to be returned as is, without wrapping into something
like
<response>12.3</response>

If the response wrapping is needed then a custom JAX-RS provider can easily
deal with wrapping the response.

However, if we had say

@Consumes("text/xml")
@POST
public  void addItem(double weight, double height) ;

where the weight and height are not query parameters but have been unwrapped
from XML such as

<item>
<weight>123</weight>
<height>123</height>
</item>

then it definitely won't work in JAX-RS.
Having

@Consumes("text/xml")
@POST
public  void addItem(Item item) ;

will do better....


Hope that helps, Sergey


> Thanks for helping.
>
>
>

Building REST style web services

Posted by Celinio <ce...@yahoo.com>.

Building REST style web services

Hi,
I am a bit new to CXF and wondering what is the recommended way to build REST style web services with CXF now.

I simply decorated my method with the @Get and @HttpResource annotations:

    @WebService
public interface IBMICalculator {
    
    @Get
    @HttpResource(location = "/computeBMI/{weight}/{height}")
    public  double computeBMI(@WebParam(name="weight") double weight, @WebParam(name="height") double height) ;
}

I imported the binding extension xml file in my spring xml configuration file, cxf.xml:
<import resource="classpath:META-INF/cxf/cxf-extension-http-binding.xml"/>

And i declared an endpoint :
 <jaxws:endpoint id="calcBMI"
                  implementor="com.company.bmi.services.IBMICalculatorImpl"
                  address="/cxfBmi"
                  bindingUri="http://apache.org/cxf/binding/http">
                  <jaxws:serviceFactory>
           <bean class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean">
               <property name="wrapped" value="true" />
           </bean>
       </jaxws:serviceFactory>
   </jaxws:endpoint>
   
It works like a charm. However I read that "This binding has been deprecated and is likely to be removed from CXF in one of its future releases"
https://cwiki.apache.org/CXF20DOC/http-binding.html

So what is the recommanded way to build REST style web services with CXF now ?
Thanks for helping.

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Anand R <An...@ibsplc.com>.

Hi Sergey,

I guess the attachment didn't get through. I have pasted my wsdl contents 
below.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="EchoService" targetNamespace="
http://echo.wssecurity.learn/"
        xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="
http://www.w3.org/2001/XMLSchema"
        xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="
http://echo.wssecurity.learn/"
        xmlns:types="http://types.echo.wssecurity.learn/" 
        xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
"
        xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
        xmlns:sp="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

        <wsp:Policy wsu:Id="UsernameToken">
                <wsp:ExactlyOne>
                        <wsp:All>
                                <sp:SupportingTokens>
                                        <wsp:Policy>
                                                <sp:UsernameToken
                                                        sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
                                                        <wsp:Policy>
 <sp:HashPassword />
                                                        </wsp:Policy>
                                                </sp:UsernameToken>
                                        </wsp:Policy>
                                </sp:SupportingTokens>
                        </wsp:All>
                </wsp:ExactlyOne>
        </wsp:Policy>

        <wsdl:types>
                <schema xmlns="http://www.w3.org/2001/XMLSchema">
                        <import namespace="
http://types.echo.wssecurity.learn/" 
schemaLocation="EchoService_schema.xsd" />
                </schema>
        </wsdl:types>

        <wsdl:message name="doEchoResponse">
                <wsdl:part name="parameters" 
element="types:doEchoResponse">
                </wsdl:part>
        </wsdl:message>

        <wsdl:message name="doEcho">
                <wsdl:part name="parameters" element="types:doEcho">
                </wsdl:part>
        </wsdl:message>

        <wsdl:portType name="EchoService">
                <wsdl:operation name="doEcho">
                        <wsdl:input name="doEcho" message="tns:doEcho">
                        </wsdl:input>
                        <wsdl:output name="doEchoResponse" 
message="tns:doEchoResponse">
                        </wsdl:output>
                </wsdl:operation>
        </wsdl:portType>

        <wsdl:binding name="EchoServiceServiceSoapBinding" 
type="tns:EchoService">
 
                <soap:binding style="document" transport="
http://schemas.xmlsoap.org/soap/http" />
                <wsdl:operation name="doEcho">
                        <wsp:PolicyReference xmlns:wsp="
http://schemas.xmlsoap.org/ws/2004/09/policy"
                        URI="#UsernameToken" />
                        <soap:operation soapAction="doEcho" 
style="document" />
                        <wsdl:input name="doEcho">
                                <soap:body use="literal" />
                        </wsdl:input>
                        <wsdl:output name="doEchoResponse">
                                <soap:body use="literal" />
                        </wsdl:output>
                </wsdl:operation>
        </wsdl:binding>

        <wsdl:service name="EchoService">
                <wsdl:port name="EchoPort" 
binding="tns:EchoServiceServiceSoapBinding">
                        <soap:address location="
http://localhost:8080/cxf/webservices/echo" />
                </wsdl:port>
        </wsdl:service>

</wsdl:definitions>

Thanks and regards,
Anand






DISCLAIMER: 

"The information in this e-mail and any attachment is intended only for 
the person to whom it is addressed and may contain confidential and/or 
privileged material. If you have received this e-mail in error, kindly 
contact the sender and destroy all copies of the original communication. 
IBS makes no warranty, express or implied, nor guarantees the accuracy, 
adequacy or completeness of the information contained in this email or any 
attachment and is not liable for any errors, defects, omissions, viruses 
or for resultant loss or damage, if any, direct or indirect."

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Anand R <An...@ibsplc.com>.

Hi Sergey,

As you mentioned, I added a breakpoint within 
WSS4JInInterceptor.handleMessage(). The web service invocation didn't  hit 
the breakpoint.
WSS4JInInterceptor wasn't present in the chain of interceptors. I added 
this interceptor explicitly in my beans.xml. Now I am getting the 
following exception.

I also tried extending AbstractUsernameTokenAuthenticatingInterceptor. I 
am getting the same exception(No security action was defined!). 
I tried setting ws-security.ut.no-callbacks on and off. Both result in the 
same exception.

I didn't understand what action is being referred here. I am attaching my 
wsdl for your reference. Is this problem anything to do with my policy 
specification?



org.apache.cxf.binding.soap.SoapFault: No security action was defined!
        at 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getAction(WSS4JInInterceptor.java:471)
        at 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:196)
        at 
org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:96)
        at 
org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:67)
        at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
        at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
        at 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
        at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
        at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
        at 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
        at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
        at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
        at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
        at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
        at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
        at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
        at java.lang.Thread.run(Thread.java:595)



Thanks and regards,
Anand



From:   Sergey Beryozkin <sb...@gmail.com>
To:     users@cxf.apache.org
Date:   03-02-11 07:28 PM
Subject:        Re: Problem with AbstractUsernameTokenInInterceptor



Hi - I do not understand why it not works. I've checked the code and I see
that no test involving a hashed password exists. Likewise I don't 
understand
why it works at the same time with clear passwords and no callbacks.
I'm a bit busy right now, is there any chance that you could download the
source for CXF 2.3.2, remove the ServerCallback property and just add a
breakpoint in WSS4JInInterceptor.handleMessage() ?

I think you're on the right track. I do not see other options for dealing
with *hashed passwords*, well, unless you;re prepared to do some hacks by
doing the container-managed authentication from the callback itself but 
that
would not let you register the proper security context because the one 
which
is created by the WSS4JInInterceptor has only a (WSS4J-created) Principal
registered, i.e, no info about roles is available.

I'd definitely follow this route myself.
Note that AbstractUsernameTokenAuthenticatingInterceptor (in the 
ws-security
module) is the other, legacy interceptor that you may also extend - as far
as I know, a 3rd-party container has a test for a hashed UT involving this
particular interceptor. No need to set the "ws-security.ut.no-callbacks",
unless you have a wsdl-first case. Concrete implementations need to extend 
a
method with several UT-related parameters which is a bit brittle in that
adding more parameters to the 
AbstractUsernameTokenAuthenticatingInterceptor
will break the users' interceptors.

Thus extending AbstractUsernameTokenInterceptor (in rt/core/.../security) 
is
recommended because we can easily update CXF UsernameToken bean with the 
new
properties ((say the UT salt property, etc)) without the existing  users
noticing.

Debug it if you can - it would help

Sergey



On Thu, Feb 3, 2011 at 1:02 PM, Anand R <An...@ibsplc.com> wrote:

> Hi Sergey,
>
> As you had mentioned earlier, the namespace is
>
> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

>
> Please find the SOAP request message below.
>
> Actually, my requirement is to obtain the username and password from the
> SOAP header to perform container authentication and then associate the
> Subject with the current thread of execution. Am I using the correct
> approach or do I just need to write a SOAPHeaderInterceptor and get the
> required headers.
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>        <soap:Header>
>                <wsse:Security soap:mustUnderstand="1"
>                        xmlns:wsse="
>
> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

> ">
>                         <wsse:UsernameToken xmlns:wsse="
>
> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

> "
>                                 xmlns:wsu="
>
> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd

> "
>                                wsu:Id="UsernameToken-1">
>                                <wsse:Username>libuser</wsse:Username>
>                                <wsse:Password
>                                        Type="
>
> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest

> ">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password>
>                                <wsse:Nonce     EncodingType="
>
> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary

> ">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce>
>                                <wsu:Created>2011-02-03T12:32:27.752Z</
> wsu:Created>
>                        </wsse:UsernameToken>
>                </wsse:Security>
>        </soap:Header>
>        <soap:Body>
>                <ns2:doEcho xmlns:ns2="
http://types.echo.wssecurity.learn/
> ">
>                        <arg0>
>                                <echoString>Hello 
WS-Security</echoString>
>                        </arg0>
>                </ns2:doEcho>
>        </soap:Body>
> </soap:Envelope>
> Thanks and regards,
> Anand R
>
>
>
> From:   Sergey Beryozkin <sb...@gmail.com>
> To:     users@cxf.apache.org
> Date:   03-02-11 05:13 PM
> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>
>
>
> Hi
>
> WSS4JInInterceptor is already registering a custom UT processor if the
> "ws-security.ut.no-callbacks" is set to true.
> So the hashed UTs should be supported with your configuration, without 
the
> need to register a callback.
> Can you give me a favor and check the actual WS-Security namespace that 
is
> used to qualify the security header ? You can add a CXF logging feature 
to
> the list of jaxws:features
>
> thanks, Sergey
>
> On Thu, Feb 3, 2011 at 11:33 AM, Anand R <An...@ibsplc.com> wrote:
>
> > Thanks Sergy. I will try the custom UsernameTokenProcessor.
> > Thanks and regards,
> > Anand R
> >
> >
> >
> > From:   Sergey Beryozkin <sb...@gmail.com>
> > To:     users@cxf.apache.org
> > Date:   03-02-11 04:39 PM
> > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> >
> >
> >
> > Hi
> >
> > What WS-Security namespace is being used in the request ?
> > If the "ws-security.ut.no-callbacks" is set to true then the
> > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not 
be
> > invoked because it does currently require a callback for hashed UTs. 
So
> if
> > the property is set then the WSS4JInInterceptor registers a custom
> > UsernameTokenProcessor for
> >
> > "
> >
> >
>
> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

>
> >
> > "
> > and
> > "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd".
> >
> > Thanks, Sergey
> >
> > On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com> 
wrote:
> >
> > > Hi Sergey,
> > >
> > > Thanks for your response. I used to get the following exception when 
I
> > did
> > > not configure a callback handler. This exception does not come if 
the
> > > password is plain text instead of a digest.
> > >
> > > org.apache.cxf.interceptor.Fault: General security error
> > > (WSSecurityEngine: No password callback supplied)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
> > >         at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> > >        at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > >        at
> > >
> >
> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> > >        at
> > >
> >
> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> > >        at
> > >
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> > >        at java.lang.Thread.run(Thread.java:595)
> > > Caused by: org.apache.ws.security.WSSecurityException: General
> security
> > > error (WSSecurityEngine: No password callback supplied)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
> > >        ... 24 more
> > >
> > >
> > > Thanks and regards,
> > > Anand R
> > > System Architect
> > > IBS Software Services Private Limited
> > > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum -
> > 695581,
> > > Kerala, India
> > > Telephone - +91-471-6614291, Mobile - +91-9846324022
> > > E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
> > >
> > >
> > >
> > >
> > > From:   Sergey Beryozkin <sb...@gmail.com>
> > > To:     users@cxf.apache.org
> > > Date:   03-02-11 04:08 PM
> > > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> > >
> > >
> > >
> > > Hi
> > >
> > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > My requirement is to perform a custom authentication on the 
username
> > and
> > > > password that I receive as part of the UsernameToken header in the
> > > > incoming SOAP request. I discovered that cxf-2.3.2 provides an
> > > > AbstractUsernameTokenInInterceptor to perform this. I extended 
this
> > > class
> > > > and created my interceptor that overrides the createSubject 
method.
> > When
> > > I
> > > > configure my interceptor in my beans.xml as shown below, I am
> getting
> > an
> > > > exception.
> > > >
> > > > This exception comes up when I use a password digest. The plain 
text
> > > > password works fine. Is there any problem in the way I have
> configured
> > > my
> > > > interceptor?
> > > >
> > > >
> > > > Entry in beans.xml
> > > >
> > > >        <jaxws:endpoint id="echo"
> > > > implementor="learn.wssecurity.echo.EchoServiceImpl"
> > > >                wsdlLocation="wsdl/echo/EchoService.wsdl"
> > > > address="/EchoService">
> > > >                <jaxws:inInterceptors>
> > > >                          <bean
> > > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
> > > >                </jaxws:inInterceptors>
> > > >                <jaxws:properties>
> > > >                        <entry key="ws-security.callback-handler"
> > > > value="learn.wssecurity.echo.ServerPasswordCallback" />
> > > >                        <entry key="ws-security.ut.no-callbacks"
> > > > value="true" />
> > > >                </jaxws:properties>
> > > >        </jaxws:endpoint>
> > > >
> > > >
> > >
> > > What is the purpose of registering ServerPasswordCallback ? If you 
set
> a
> > > "ws-security.ut.no-callbacks" property then you only need a callback
> if
> > > you
> > > have an encrypted UT, so that the UT can be decrypted.
> > > So this callback that you're registering may be interfering in the
> case
> > > when
> > > you have a hashed UT token, can you remove it please and see what
> > happens
> > > ?
> > >
> > > Cheers, Sergey
> > >
> > >
> > >
> > >
> > > >
> > > > Exception
> > > >
> > > > java.lang.SecurityException: Security Token is not available on 
the
> > > > current message
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> > > > 88)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> > > >        at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > > >        at
> > > >
> > >
> >
> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> > > >        at
> > > >
> > >
> >
> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> > > >        at
> > > >
> > 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> > > >        at java.lang.Thread.run(Thread.java:595)
> > > >
> > > > Thanks and regards,
> > > > Anand R
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > DISCLAIMER:
> > > >
> > > > "The information in this e-mail and any attachment is intended 
only
> > for
> > > > the person to whom it is addressed and may contain confidential
> and/or
> > > > privileged material. If you have received this e-mail in error,
> kindly
> > > > contact the sender and destroy all copies of the original
> > communication.
> > > > IBS makes no warranty, express or implied, nor guarantees the
> > accuracy,
> > > > adequacy or completeness of the information contained in this 
email
> or
> > > any
> > > > attachment and is not liable for any errors, defects, omissions,
> > viruses
> > > > or for resultant loss or damage, if any, direct or indirect."
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > DISCLAIMER:
> > >
> > > "The information in this e-mail and any attachment is intended only
> for
> > > the person to whom it is addressed and may contain confidential 
and/or
> > > privileged material. If you have received this e-mail in error, 
kindly
> > > contact the sender and destroy all copies of the original
> communication.
> > > IBS makes no warranty, express or implied, nor guarantees the
> accuracy,
> > > adequacy or completeness of the information contained in this email 
or
> > any
> > > attachment and is not liable for any errors, defects, omissions,
> viruses
> > > or for resultant loss or damage, if any, direct or indirect."
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> > DISCLAIMER:
> >
> > "The information in this e-mail and any attachment is intended only 
for
> > the person to whom it is addressed and may contain confidential and/or
> > privileged material. If you have received this e-mail in error, kindly
> > contact the sender and destroy all copies of the original 
communication.
> > IBS makes no warranty, express or implied, nor guarantees the 
accuracy,
> > adequacy or completeness of the information contained in this email or
> any
> > attachment and is not liable for any errors, defects, omissions, 
viruses
> > or for resultant loss or damage, if any, direct or indirect."
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for
> the person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication.
> IBS makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy or completeness of the information contained in this email or 
any
> attachment and is not liable for any errors, defects, omissions, viruses
> or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>







DISCLAIMER: 

"The information in this e-mail and any attachment is intended only for 
the person to whom it is addressed and may contain confidential and/or 
privileged material. If you have received this e-mail in error, kindly 
contact the sender and destroy all copies of the original communication. 
IBS makes no warranty, express or implied, nor guarantees the accuracy, 
adequacy or completeness of the information contained in this email or any 
attachment and is not liable for any errors, defects, omissions, viruses 
or for resultant loss or damage, if any, direct or indirect."

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi - I do not understand why it not works. I've checked the code and I see
that no test involving a hashed password exists. Likewise I don't understand
why it works at the same time with clear passwords and no callbacks.
I'm a bit busy right now, is there any chance that you could download the
source for CXF 2.3.2, remove the ServerCallback property and just add a
breakpoint in WSS4JInInterceptor.handleMessage() ?

I think you're on the right track. I do not see other options for dealing
with *hashed passwords*, well, unless you;re prepared to do some hacks by
doing the container-managed authentication from the callback itself but that
would not let you register the proper security context because the one which
is created by the WSS4JInInterceptor has only a (WSS4J-created) Principal
registered, i.e, no info about roles is available.

I'd definitely follow this route myself.
Note that AbstractUsernameTokenAuthenticatingInterceptor (in the ws-security
module) is the other, legacy interceptor that you may also extend - as far
as I know, a 3rd-party container has a test for a hashed UT involving this
particular interceptor. No need to set the "ws-security.ut.no-callbacks",
unless you have a wsdl-first case. Concrete implementations need to extend a
method with several UT-related parameters which is a bit brittle in that
adding more parameters to the AbstractUsernameTokenAuthenticatingInterceptor
will break the users' interceptors.

Thus extending AbstractUsernameTokenInterceptor (in rt/core/.../security) is
recommended because we can easily update CXF UsernameToken bean with the new
properties ((say the UT salt property, etc)) without the existing  users
noticing.

Debug it if you can - it would help

Sergey



On Thu, Feb 3, 2011 at 1:02 PM, Anand R <An...@ibsplc.com> wrote:

> Hi Sergey,
>
> As you had mentioned earlier, the namespace is
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>
> Please find the SOAP request message below.
>
> Actually, my requirement is to obtain the username and password from the
> SOAP header to perform container authentication and then associate the
> Subject with the current thread of execution. Am I using the correct
> approach or do I just need to write a SOAPHeaderInterceptor and get the
> required headers.
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>        <soap:Header>
>                <wsse:Security soap:mustUnderstand="1"
>                        xmlns:wsse="
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> ">
>                         <wsse:UsernameToken xmlns:wsse="
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
>                                 xmlns:wsu="
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
>                                wsu:Id="UsernameToken-1">
>                                <wsse:Username>libuser</wsse:Username>
>                                <wsse:Password
>                                        Type="
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest
> ">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password>
>                                <wsse:Nonce     EncodingType="
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
> ">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce>
>                                <wsu:Created>2011-02-03T12:32:27.752Z</
> wsu:Created>
>                        </wsse:UsernameToken>
>                </wsse:Security>
>        </soap:Header>
>        <soap:Body>
>                <ns2:doEcho xmlns:ns2="http://types.echo.wssecurity.learn/
> ">
>                        <arg0>
>                                <echoString>Hello WS-Security</echoString>
>                        </arg0>
>                </ns2:doEcho>
>        </soap:Body>
> </soap:Envelope>
> Thanks and regards,
> Anand R
>
>
>
> From:   Sergey Beryozkin <sb...@gmail.com>
> To:     users@cxf.apache.org
> Date:   03-02-11 05:13 PM
> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>
>
>
> Hi
>
> WSS4JInInterceptor is already registering a custom UT processor if the
> "ws-security.ut.no-callbacks" is set to true.
> So the hashed UTs should be supported with your configuration, without the
> need to register a callback.
> Can you give me a favor and check the actual WS-Security namespace that is
> used to qualify the security header ? You can add a CXF logging feature to
> the list of jaxws:features
>
> thanks, Sergey
>
> On Thu, Feb 3, 2011 at 11:33 AM, Anand R <An...@ibsplc.com> wrote:
>
> > Thanks Sergy. I will try the custom UsernameTokenProcessor.
> > Thanks and regards,
> > Anand R
> >
> >
> >
> > From:   Sergey Beryozkin <sb...@gmail.com>
> > To:     users@cxf.apache.org
> > Date:   03-02-11 04:39 PM
> > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> >
> >
> >
> > Hi
> >
> > What WS-Security namespace is being used in the request ?
> > If the "ws-security.ut.no-callbacks" is set to true then the
> > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not be
> > invoked because it does currently require a callback for hashed UTs. So
> if
> > the property is set then the WSS4JInInterceptor registers a custom
> > UsernameTokenProcessor for
> >
> > "
> >
> >
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>
> >
> > "
> > and
> > "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd".
> >
> > Thanks, Sergey
> >
> > On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com> wrote:
> >
> > > Hi Sergey,
> > >
> > > Thanks for your response. I used to get the following exception when I
> > did
> > > not configure a callback handler. This exception does not come if the
> > > password is plain text instead of a digest.
> > >
> > > org.apache.cxf.interceptor.Fault: General security error
> > > (WSSecurityEngine: No password callback supplied)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
> > >         at
> > >
> > >
> >
> >
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> > >        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > >        at
> > >
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> > >        at
> > >
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> > >        at
> > >
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> > >        at java.lang.Thread.run(Thread.java:595)
> > > Caused by: org.apache.ws.security.WSSecurityException: General
> security
> > > error (WSSecurityEngine: No password callback supplied)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
> > >        ... 24 more
> > >
> > >
> > > Thanks and regards,
> > > Anand R
> > > System Architect
> > > IBS Software Services Private Limited
> > > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum -
> > 695581,
> > > Kerala, India
> > > Telephone - +91-471-6614291, Mobile - +91-9846324022
> > > E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
> > >
> > >
> > >
> > >
> > > From:   Sergey Beryozkin <sb...@gmail.com>
> > > To:     users@cxf.apache.org
> > > Date:   03-02-11 04:08 PM
> > > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> > >
> > >
> > >
> > > Hi
> > >
> > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > My requirement is to perform a custom authentication on the username
> > and
> > > > password that I receive as part of the UsernameToken header in the
> > > > incoming SOAP request. I discovered that cxf-2.3.2 provides an
> > > > AbstractUsernameTokenInInterceptor to perform this. I extended this
> > > class
> > > > and created my interceptor that overrides the createSubject method.
> > When
> > > I
> > > > configure my interceptor in my beans.xml as shown below, I am
> getting
> > an
> > > > exception.
> > > >
> > > > This exception comes up when I use a password digest. The plain text
> > > > password works fine. Is there any problem in the way I have
> configured
> > > my
> > > > interceptor?
> > > >
> > > >
> > > > Entry in beans.xml
> > > >
> > > >        <jaxws:endpoint id="echo"
> > > > implementor="learn.wssecurity.echo.EchoServiceImpl"
> > > >                wsdlLocation="wsdl/echo/EchoService.wsdl"
> > > > address="/EchoService">
> > > >                <jaxws:inInterceptors>
> > > >                          <bean
> > > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
> > > >                </jaxws:inInterceptors>
> > > >                <jaxws:properties>
> > > >                        <entry key="ws-security.callback-handler"
> > > > value="learn.wssecurity.echo.ServerPasswordCallback" />
> > > >                        <entry key="ws-security.ut.no-callbacks"
> > > > value="true" />
> > > >                </jaxws:properties>
> > > >        </jaxws:endpoint>
> > > >
> > > >
> > >
> > > What is the purpose of registering ServerPasswordCallback ? If you set
> a
> > > "ws-security.ut.no-callbacks" property then you only need a callback
> if
> > > you
> > > have an encrypted UT, so that the UT can be decrypted.
> > > So this callback that you're registering may be interfering in the
> case
> > > when
> > > you have a hashed UT token, can you remove it please and see what
> > happens
> > > ?
> > >
> > > Cheers, Sergey
> > >
> > >
> > >
> > >
> > > >
> > > > Exception
> > > >
> > > > java.lang.SecurityException: Security Token is not available on the
> > > > current message
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> > > > 88)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> > > >        at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > > >        at
> > > >
> > >
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> > > >        at
> > > >
> > >
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> > > >        at
> > > >
> > > >
> > >
> > >
> >
> >
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> > > >        at
> > > >
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> > > >        at java.lang.Thread.run(Thread.java:595)
> > > >
> > > > Thanks and regards,
> > > > Anand R
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > DISCLAIMER:
> > > >
> > > > "The information in this e-mail and any attachment is intended only
> > for
> > > > the person to whom it is addressed and may contain confidential
> and/or
> > > > privileged material. If you have received this e-mail in error,
> kindly
> > > > contact the sender and destroy all copies of the original
> > communication.
> > > > IBS makes no warranty, express or implied, nor guarantees the
> > accuracy,
> > > > adequacy or completeness of the information contained in this email
> or
> > > any
> > > > attachment and is not liable for any errors, defects, omissions,
> > viruses
> > > > or for resultant loss or damage, if any, direct or indirect."
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > DISCLAIMER:
> > >
> > > "The information in this e-mail and any attachment is intended only
> for
> > > the person to whom it is addressed and may contain confidential and/or
> > > privileged material. If you have received this e-mail in error, kindly
> > > contact the sender and destroy all copies of the original
> communication.
> > > IBS makes no warranty, express or implied, nor guarantees the
> accuracy,
> > > adequacy or completeness of the information contained in this email or
> > any
> > > attachment and is not liable for any errors, defects, omissions,
> viruses
> > > or for resultant loss or damage, if any, direct or indirect."
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> > DISCLAIMER:
> >
> > "The information in this e-mail and any attachment is intended only for
> > the person to whom it is addressed and may contain confidential and/or
> > privileged material. If you have received this e-mail in error, kindly
> > contact the sender and destroy all copies of the original communication.
> > IBS makes no warranty, express or implied, nor guarantees the accuracy,
> > adequacy or completeness of the information contained in this email or
> any
> > attachment and is not liable for any errors, defects, omissions, viruses
> > or for resultant loss or damage, if any, direct or indirect."
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for
> the person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication.
> IBS makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy or completeness of the information contained in this email or any
> attachment and is not liable for any errors, defects, omissions, viruses
> or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Anand R <An...@ibsplc.com>.

Hi Sergey,

As you had mentioned earlier, the namespace is 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd 

Please find the SOAP request message below.

Actually, my requirement is to obtain the username and password from the 
SOAP header to perform container authentication and then associate the 
Subject with the current thread of execution. Am I using the correct 
approach or do I just need to write a SOAPHeaderInterceptor and get the 
required headers.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <soap:Header>
                <wsse:Security soap:mustUnderstand="1"
                        xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
">
                        <wsse:UsernameToken xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
"
                                xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
"
                                wsu:Id="UsernameToken-1">
                                <wsse:Username>libuser</wsse:Username>
                                <wsse:Password
                                        Type="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest
">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password>
                                <wsse:Nonce     EncodingType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce>
                                <wsu:Created>2011-02-03T12:32:27.752Z</
wsu:Created>
                        </wsse:UsernameToken>
                </wsse:Security>
        </soap:Header>
        <soap:Body>
                <ns2:doEcho xmlns:ns2="http://types.echo.wssecurity.learn/
">
                        <arg0>
                                <echoString>Hello WS-Security</echoString>
                        </arg0>
                </ns2:doEcho>
        </soap:Body>
</soap:Envelope>
Thanks and regards,
Anand R



From:   Sergey Beryozkin <sb...@gmail.com>
To:     users@cxf.apache.org
Date:   03-02-11 05:13 PM
Subject:        Re: Problem with AbstractUsernameTokenInInterceptor



Hi

WSS4JInInterceptor is already registering a custom UT processor if the
"ws-security.ut.no-callbacks" is set to true.
So the hashed UTs should be supported with your configuration, without the
need to register a callback.
Can you give me a favor and check the actual WS-Security namespace that is
used to qualify the security header ? You can add a CXF logging feature to
the list of jaxws:features

thanks, Sergey

On Thu, Feb 3, 2011 at 11:33 AM, Anand R <An...@ibsplc.com> wrote:

> Thanks Sergy. I will try the custom UsernameTokenProcessor.
> Thanks and regards,
> Anand R
>
>
>
> From:   Sergey Beryozkin <sb...@gmail.com>
> To:     users@cxf.apache.org
> Date:   03-02-11 04:39 PM
> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>
>
>
> Hi
>
> What WS-Security namespace is being used in the request ?
> If the "ws-security.ut.no-callbacks" is set to true then the
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not be
> invoked because it does currently require a callback for hashed UTs. So 
if
> the property is set then the WSS4JInInterceptor registers a custom
> UsernameTokenProcessor for
>
> "
>
> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

>
> "
> and
> "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd".
>
> Thanks, Sergey
>
> On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com> wrote:
>
> > Hi Sergey,
> >
> > Thanks for your response. I used to get the following exception when I
> did
> > not configure a callback handler. This exception does not come if the
> > password is plain text instead of a digest.
> >
> > org.apache.cxf.interceptor.Fault: General security error
> > (WSSecurityEngine: No password callback supplied)
> >        at
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
> >        at
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
> >        at
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
> >         at
> >
> >
>
> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> >        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> >        at
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> >        at
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >        at
> >
> >
>
> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> >        at
> >
> >
>
> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> >        at
> >
> >
>
> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >        at
> >
> >
>
> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> >        at
> >
> >
>
> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> >        at
> >
> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> >        at
> >
> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> >        at
> >
> >
>
> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> >        at
> > 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> >        at java.lang.Thread.run(Thread.java:595)
> > Caused by: org.apache.ws.security.WSSecurityException: General 
security
> > error (WSSecurityEngine: No password callback supplied)
> >        at
> >
> >
>
> 
org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
> >        at
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
> >        at
> >
> >
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
> >        ... 24 more
> >
> >
> > Thanks and regards,
> > Anand R
> > System Architect
> > IBS Software Services Private Limited
> > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum -
> 695581,
> > Kerala, India
> > Telephone - +91-471-6614291, Mobile - +91-9846324022
> > E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
> >
> >
> >
> >
> > From:   Sergey Beryozkin <sb...@gmail.com>
> > To:     users@cxf.apache.org
> > Date:   03-02-11 04:08 PM
> > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> >
> >
> >
> > Hi
> >
> > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com> 
wrote:
> >
> > > Hi,
> > >
> > > My requirement is to perform a custom authentication on the username
> and
> > > password that I receive as part of the UsernameToken header in the
> > > incoming SOAP request. I discovered that cxf-2.3.2 provides an
> > > AbstractUsernameTokenInInterceptor to perform this. I extended this
> > class
> > > and created my interceptor that overrides the createSubject method.
> When
> > I
> > > configure my interceptor in my beans.xml as shown below, I am 
getting
> an
> > > exception.
> > >
> > > This exception comes up when I use a password digest. The plain text
> > > password works fine. Is there any problem in the way I have 
configured
> > my
> > > interceptor?
> > >
> > >
> > > Entry in beans.xml
> > >
> > >        <jaxws:endpoint id="echo"
> > > implementor="learn.wssecurity.echo.EchoServiceImpl"
> > >                wsdlLocation="wsdl/echo/EchoService.wsdl"
> > > address="/EchoService">
> > >                <jaxws:inInterceptors>
> > >                          <bean
> > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
> > >                </jaxws:inInterceptors>
> > >                <jaxws:properties>
> > >                        <entry key="ws-security.callback-handler"
> > > value="learn.wssecurity.echo.ServerPasswordCallback" />
> > >                        <entry key="ws-security.ut.no-callbacks"
> > > value="true" />
> > >                </jaxws:properties>
> > >        </jaxws:endpoint>
> > >
> > >
> >
> > What is the purpose of registering ServerPasswordCallback ? If you set 
a
> > "ws-security.ut.no-callbacks" property then you only need a callback 
if
> > you
> > have an encrypted UT, so that the UT can be decrypted.
> > So this callback that you're registering may be interfering in the 
case
> > when
> > you have a hashed UT token, can you remove it please and see what
> happens
> > ?
> >
> > Cheers, Sergey
> >
> >
> >
> >
> > >
> > > Exception
> > >
> > > java.lang.SecurityException: Security Token is not available on the
> > > current message
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> > > 88)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> > >        at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > >        at
> > >
> >
> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> > >        at
> > >
> >
> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> > >        at
> > >
> > >
> >
> >
>
> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> > >        at
> > >
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> > >        at java.lang.Thread.run(Thread.java:595)
> > >
> > > Thanks and regards,
> > > Anand R
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > DISCLAIMER:
> > >
> > > "The information in this e-mail and any attachment is intended only
> for
> > > the person to whom it is addressed and may contain confidential 
and/or
> > > privileged material. If you have received this e-mail in error, 
kindly
> > > contact the sender and destroy all copies of the original
> communication.
> > > IBS makes no warranty, express or implied, nor guarantees the
> accuracy,
> > > adequacy or completeness of the information contained in this email 
or
> > any
> > > attachment and is not liable for any errors, defects, omissions,
> viruses
> > > or for resultant loss or damage, if any, direct or indirect."
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> > DISCLAIMER:
> >
> > "The information in this e-mail and any attachment is intended only 
for
> > the person to whom it is addressed and may contain confidential and/or
> > privileged material. If you have received this e-mail in error, kindly
> > contact the sender and destroy all copies of the original 
communication.
> > IBS makes no warranty, express or implied, nor guarantees the 
accuracy,
> > adequacy or completeness of the information contained in this email or
> any
> > attachment and is not liable for any errors, defects, omissions, 
viruses
> > or for resultant loss or damage, if any, direct or indirect."
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for
> the person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication.
> IBS makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy or completeness of the information contained in this email or 
any
> attachment and is not liable for any errors, defects, omissions, viruses
> or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>







DISCLAIMER: 

"The information in this e-mail and any attachment is intended only for 
the person to whom it is addressed and may contain confidential and/or 
privileged material. If you have received this e-mail in error, kindly 
contact the sender and destroy all copies of the original communication. 
IBS makes no warranty, express or implied, nor guarantees the accuracy, 
adequacy or completeness of the information contained in this email or any 
attachment and is not liable for any errors, defects, omissions, viruses 
or for resultant loss or damage, if any, direct or indirect."

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi

WSS4JInInterceptor is already registering a custom UT processor if the
"ws-security.ut.no-callbacks" is set to true.
So the hashed UTs should be supported with your configuration, without the
need to register a callback.
Can you give me a favor and check the actual WS-Security namespace that is
used to qualify the security header ? You can add a CXF logging feature to
the list of jaxws:features

thanks, Sergey

On Thu, Feb 3, 2011 at 11:33 AM, Anand R <An...@ibsplc.com> wrote:

> Thanks Sergy. I will try the custom UsernameTokenProcessor.
> Thanks and regards,
> Anand R
>
>
>
> From:   Sergey Beryozkin <sb...@gmail.com>
> To:     users@cxf.apache.org
> Date:   03-02-11 04:39 PM
> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>
>
>
> Hi
>
> What WS-Security namespace is being used in the request ?
> If the "ws-security.ut.no-callbacks" is set to true then the
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not be
> invoked because it does currently require a callback for hashed UTs. So if
> the property is set then the WSS4JInInterceptor registers a custom
> UsernameTokenProcessor for
>
> "
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>
> "
> and
> "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd".
>
> Thanks, Sergey
>
> On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com> wrote:
>
> > Hi Sergey,
> >
> > Thanks for your response. I used to get the following exception when I
> did
> > not configure a callback handler. This exception does not come if the
> > password is plain text instead of a digest.
> >
> > org.apache.cxf.interceptor.Fault: General security error
> > (WSSecurityEngine: No password callback supplied)
> >        at
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
> >        at
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
> >        at
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
> >         at
> >
> >
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> >        at
> >
> >
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> >        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> >        at
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> >        at
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >        at
> >
> >
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> >        at
> >
> >
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> >        at
> >
> >
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >        at
> >
> >
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> >        at
> >
> >
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> >        at
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> >        at
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> >        at
> >
> >
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> >        at
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> >        at java.lang.Thread.run(Thread.java:595)
> > Caused by: org.apache.ws.security.WSSecurityException: General security
> > error (WSSecurityEngine: No password callback supplied)
> >        at
> >
> >
>
> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
> >        at
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
> >        at
> >
> >
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
> >        ... 24 more
> >
> >
> > Thanks and regards,
> > Anand R
> > System Architect
> > IBS Software Services Private Limited
> > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum -
> 695581,
> > Kerala, India
> > Telephone - +91-471-6614291, Mobile - +91-9846324022
> > E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
> >
> >
> >
> >
> > From:   Sergey Beryozkin <sb...@gmail.com>
> > To:     users@cxf.apache.org
> > Date:   03-02-11 04:08 PM
> > Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
> >
> >
> >
> > Hi
> >
> > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com> wrote:
> >
> > > Hi,
> > >
> > > My requirement is to perform a custom authentication on the username
> and
> > > password that I receive as part of the UsernameToken header in the
> > > incoming SOAP request. I discovered that cxf-2.3.2 provides an
> > > AbstractUsernameTokenInInterceptor to perform this. I extended this
> > class
> > > and created my interceptor that overrides the createSubject method.
> When
> > I
> > > configure my interceptor in my beans.xml as shown below, I am getting
> an
> > > exception.
> > >
> > > This exception comes up when I use a password digest. The plain text
> > > password works fine. Is there any problem in the way I have configured
> > my
> > > interceptor?
> > >
> > >
> > > Entry in beans.xml
> > >
> > >        <jaxws:endpoint id="echo"
> > > implementor="learn.wssecurity.echo.EchoServiceImpl"
> > >                wsdlLocation="wsdl/echo/EchoService.wsdl"
> > > address="/EchoService">
> > >                <jaxws:inInterceptors>
> > >                          <bean
> > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
> > >                </jaxws:inInterceptors>
> > >                <jaxws:properties>
> > >                        <entry key="ws-security.callback-handler"
> > > value="learn.wssecurity.echo.ServerPasswordCallback" />
> > >                        <entry key="ws-security.ut.no-callbacks"
> > > value="true" />
> > >                </jaxws:properties>
> > >        </jaxws:endpoint>
> > >
> > >
> >
> > What is the purpose of registering ServerPasswordCallback ? If you set a
> > "ws-security.ut.no-callbacks" property then you only need a callback if
> > you
> > have an encrypted UT, so that the UT can be decrypted.
> > So this callback that you're registering may be interfering in the case
> > when
> > you have a hashed UT token, can you remove it please and see what
> happens
> > ?
> >
> > Cheers, Sergey
> >
> >
> >
> >
> > >
> > > Exception
> > >
> > > java.lang.SecurityException: Security Token is not available on the
> > > current message
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> > > 88)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> > >        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > >        at
> > >
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> > >        at
> > >
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> > >        at
> > >
> > >
> >
> >
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> > >        at
> > >
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> > >        at java.lang.Thread.run(Thread.java:595)
> > >
> > > Thanks and regards,
> > > Anand R
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > DISCLAIMER:
> > >
> > > "The information in this e-mail and any attachment is intended only
> for
> > > the person to whom it is addressed and may contain confidential and/or
> > > privileged material. If you have received this e-mail in error, kindly
> > > contact the sender and destroy all copies of the original
> communication.
> > > IBS makes no warranty, express or implied, nor guarantees the
> accuracy,
> > > adequacy or completeness of the information contained in this email or
> > any
> > > attachment and is not liable for any errors, defects, omissions,
> viruses
> > > or for resultant loss or damage, if any, direct or indirect."
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> > DISCLAIMER:
> >
> > "The information in this e-mail and any attachment is intended only for
> > the person to whom it is addressed and may contain confidential and/or
> > privileged material. If you have received this e-mail in error, kindly
> > contact the sender and destroy all copies of the original communication.
> > IBS makes no warranty, express or implied, nor guarantees the accuracy,
> > adequacy or completeness of the information contained in this email or
> any
> > attachment and is not liable for any errors, defects, omissions, viruses
> > or for resultant loss or damage, if any, direct or indirect."
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for
> the person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication.
> IBS makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy or completeness of the information contained in this email or any
> attachment and is not liable for any errors, defects, omissions, viruses
> or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Anand R <An...@ibsplc.com>.

Thanks Sergy. I will try the custom UsernameTokenProcessor.
Thanks and regards,
Anand R



From:   Sergey Beryozkin <sb...@gmail.com>
To:     users@cxf.apache.org
Date:   03-02-11 04:39 PM
Subject:        Re: Problem with AbstractUsernameTokenInInterceptor



Hi

What WS-Security namespace is being used in the request ?
If the "ws-security.ut.no-callbacks" is set to true then the
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not be
invoked because it does currently require a callback for hashed UTs. So if
the property is set then the WSS4JInInterceptor registers a custom
UsernameTokenProcessor for

"
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

"
and
"http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd".

Thanks, Sergey

On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com> wrote:

> Hi Sergey,
>
> Thanks for your response. I used to get the following exception when I 
did
> not configure a callback handler. This exception does not come if the
> password is plain text instead of a digest.
>
> org.apache.cxf.interceptor.Fault: General security error
> (WSSecurityEngine: No password callback supplied)
>        at
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
>        at
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
>        at
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
>         at
>
> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>        at
>
> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>        at
>
> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>        at
>
> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>        at
>
> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>        at
>
> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>        at
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>        at
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>        at
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>        at
>
> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>        at
>
> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at
>
> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>        at
>
> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>        at
>
> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>        at
>
> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at
>
> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at
> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>        at
> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>        at
>
> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>        at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>        at java.lang.Thread.run(Thread.java:595)
> Caused by: org.apache.ws.security.WSSecurityException: General security
> error (WSSecurityEngine: No password callback supplied)
>        at
>
> 
org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
>        at
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
>        at
>
> 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
>        ... 24 more
>
>
> Thanks and regards,
> Anand R
> System Architect
> IBS Software Services Private Limited
> 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum - 
695581,
> Kerala, India
> Telephone - +91-471-6614291, Mobile - +91-9846324022
> E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
>
>
>
>
> From:   Sergey Beryozkin <sb...@gmail.com>
> To:     users@cxf.apache.org
> Date:   03-02-11 04:08 PM
> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>
>
>
> Hi
>
> On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com> wrote:
>
> > Hi,
> >
> > My requirement is to perform a custom authentication on the username 
and
> > password that I receive as part of the UsernameToken header in the
> > incoming SOAP request. I discovered that cxf-2.3.2 provides an
> > AbstractUsernameTokenInInterceptor to perform this. I extended this
> class
> > and created my interceptor that overrides the createSubject method. 
When
> I
> > configure my interceptor in my beans.xml as shown below, I am getting 
an
> > exception.
> >
> > This exception comes up when I use a password digest. The plain text
> > password works fine. Is there any problem in the way I have configured
> my
> > interceptor?
> >
> >
> > Entry in beans.xml
> >
> >        <jaxws:endpoint id="echo"
> > implementor="learn.wssecurity.echo.EchoServiceImpl"
> >                wsdlLocation="wsdl/echo/EchoService.wsdl"
> > address="/EchoService">
> >                <jaxws:inInterceptors>
> >                          <bean
> > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
> >                </jaxws:inInterceptors>
> >                <jaxws:properties>
> >                        <entry key="ws-security.callback-handler"
> > value="learn.wssecurity.echo.ServerPasswordCallback" />
> >                        <entry key="ws-security.ut.no-callbacks"
> > value="true" />
> >                </jaxws:properties>
> >        </jaxws:endpoint>
> >
> >
>
> What is the purpose of registering ServerPasswordCallback ? If you set a
> "ws-security.ut.no-callbacks" property then you only need a callback if
> you
> have an encrypted UT, so that the UT can be decrypted.
> So this callback that you're registering may be interfering in the case
> when
> you have a hashed UT token, can you remove it please and see what 
happens
> ?
>
> Cheers, Sergey
>
>
>
>
> >
> > Exception
> >
> > java.lang.SecurityException: Security Token is not available on the
> > current message
> >        at
> >
> >
>
> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> > 88)
> >        at
> >
> >
>
> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
> >        at
> >
> >
>
> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> >        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> >        at
> >
> >
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> >        at
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> >        at
> >
> >
>
> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >        at
> >
> >
>
> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> >        at
> >
> >
>
> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> >        at
> >
> >
>
> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >        at
> >
> >
>
> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> >        at
> >
> >
>
> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> >        at
> >
> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> >        at
> >
> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> >        at
> >
> >
>
> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> >        at
> > 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> >        at java.lang.Thread.run(Thread.java:595)
> >
> > Thanks and regards,
> > Anand R
> >
> >
> >
> >
> >
> >
> >
> > DISCLAIMER:
> >
> > "The information in this e-mail and any attachment is intended only 
for
> > the person to whom it is addressed and may contain confidential and/or
> > privileged material. If you have received this e-mail in error, kindly
> > contact the sender and destroy all copies of the original 
communication.
> > IBS makes no warranty, express or implied, nor guarantees the 
accuracy,
> > adequacy or completeness of the information contained in this email or
> any
> > attachment and is not liable for any errors, defects, omissions, 
viruses
> > or for resultant loss or damage, if any, direct or indirect."
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for
> the person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication.
> IBS makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy or completeness of the information contained in this email or 
any
> attachment and is not liable for any errors, defects, omissions, viruses
> or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>







DISCLAIMER: 

"The information in this e-mail and any attachment is intended only for 
the person to whom it is addressed and may contain confidential and/or 
privileged material. If you have received this e-mail in error, kindly 
contact the sender and destroy all copies of the original communication. 
IBS makes no warranty, express or implied, nor guarantees the accuracy, 
adequacy or completeness of the information contained in this email or any 
attachment and is not liable for any errors, defects, omissions, viruses 
or for resultant loss or damage, if any, direct or indirect."

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi

What WS-Security namespace is being used in the request ?
If the "ws-security.ut.no-callbacks" is set to true then the
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not be
invoked because it does currently require a callback for hashed UTs. So if
the property is set then the WSS4JInInterceptor registers a custom
UsernameTokenProcessor for

"
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
"
and
"http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd".

Thanks, Sergey

On Thu, Feb 3, 2011 at 10:51 AM, Anand R <An...@ibsplc.com> wrote:

> Hi Sergey,
>
> Thanks for your response. I used to get the following exception when I did
> not configure a callback handler. This exception does not come if the
> password is plain text instead of a digest.
>
> org.apache.cxf.interceptor.Fault: General security error
> (WSSecurityEngine: No password callback supplied)
>        at
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
>        at
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
>        at
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
>         at
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>        at
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>        at
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>        at
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>        at
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>        at
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>        at
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>        at
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>        at
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>        at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>        at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>        at
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>        at
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>        at
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>        at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>        at
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>        at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>        at java.lang.Thread.run(Thread.java:595)
> Caused by: org.apache.ws.security.WSSecurityException: General security
> error (WSSecurityEngine: No password callback supplied)
>        at
>
> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
>        at
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
>        at
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
>        ... 24 more
>
>
> Thanks and regards,
> Anand R
> System Architect
> IBS Software Services Private Limited
> 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum - 695581,
> Kerala, India
> Telephone - +91-471-6614291, Mobile - +91-9846324022
> E-Mail - anand.raman@ibsplc.com, www.ibsplc.com
>
>
>
>
> From:   Sergey Beryozkin <sb...@gmail.com>
> To:     users@cxf.apache.org
> Date:   03-02-11 04:08 PM
> Subject:        Re: Problem with AbstractUsernameTokenInInterceptor
>
>
>
> Hi
>
> On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com> wrote:
>
> > Hi,
> >
> > My requirement is to perform a custom authentication on the username and
> > password that I receive as part of the UsernameToken header in the
> > incoming SOAP request. I discovered that cxf-2.3.2 provides an
> > AbstractUsernameTokenInInterceptor to perform this. I extended this
> class
> > and created my interceptor that overrides the createSubject method. When
> I
> > configure my interceptor in my beans.xml as shown below, I am getting an
> > exception.
> >
> > This exception comes up when I use a password digest. The plain text
> > password works fine. Is there any problem in the way I have configured
> my
> > interceptor?
> >
> >
> > Entry in beans.xml
> >
> >        <jaxws:endpoint id="echo"
> > implementor="learn.wssecurity.echo.EchoServiceImpl"
> >                wsdlLocation="wsdl/echo/EchoService.wsdl"
> > address="/EchoService">
> >                <jaxws:inInterceptors>
> >                          <bean
> > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
> >                </jaxws:inInterceptors>
> >                <jaxws:properties>
> >                        <entry key="ws-security.callback-handler"
> > value="learn.wssecurity.echo.ServerPasswordCallback" />
> >                        <entry key="ws-security.ut.no-callbacks"
> > value="true" />
> >                </jaxws:properties>
> >        </jaxws:endpoint>
> >
> >
>
> What is the purpose of registering ServerPasswordCallback ? If you set a
> "ws-security.ut.no-callbacks" property then you only need a callback if
> you
> have an encrypted UT, so that the UT can be decrypted.
> So this callback that you're registering may be interfering in the case
> when
> you have a hashed UT token, can you remove it please and see what happens
> ?
>
> Cheers, Sergey
>
>
>
>
> >
> > Exception
> >
> > java.lang.SecurityException: Security Token is not available on the
> > current message
> >        at
> >
> >
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> > 88)
> >        at
> >
> >
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
> >        at
> >
> >
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> >        at
> >
> >
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> >        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> >        at
> >
> >
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> >        at
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> >        at
> >
> >
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >        at
> >
> >
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> >        at
> >
> >
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> >        at
> >
> >
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >        at
> >
> >
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> >        at
> >
> >
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> >        at
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> >        at
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> >        at
> >
> >
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> >        at
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> >        at java.lang.Thread.run(Thread.java:595)
> >
> > Thanks and regards,
> > Anand R
> >
> >
> >
> >
> >
> >
> >
> > DISCLAIMER:
> >
> > "The information in this e-mail and any attachment is intended only for
> > the person to whom it is addressed and may contain confidential and/or
> > privileged material. If you have received this e-mail in error, kindly
> > contact the sender and destroy all copies of the original communication.
> > IBS makes no warranty, express or implied, nor guarantees the accuracy,
> > adequacy or completeness of the information contained in this email or
> any
> > attachment and is not liable for any errors, defects, omissions, viruses
> > or for resultant loss or damage, if any, direct or indirect."
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for
> the person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication.
> IBS makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy or completeness of the information contained in this email or any
> attachment and is not liable for any errors, defects, omissions, viruses
> or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Anand R <An...@ibsplc.com>.

Hi Sergey,

Thanks for your response. I used to get the following exception when I did 
not configure a callback handler. This exception does not come if the 
password is plain text instead of a digest.

org.apache.cxf.interceptor.Fault: General security error 
(WSSecurityEngine: No password callback supplied)
        at 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154)
        at 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114)
        at 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72)
        at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
        at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
        at 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
        at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
        at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
        at 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
        at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
        at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
        at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
        at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
        at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
        at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
        at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.ws.security.WSSecurityException: General security 
error (WSSecurityEngine: No password callback supplied)
        at 
org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
        at 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167)
        at 
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129)
        ... 24 more
 
 
Thanks and regards,
Anand R 
System Architect 
IBS Software Services Private Limited 
2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum - 695581, 
Kerala, India
Telephone - +91-471-6614291, Mobile - +91-9846324022 
E-Mail - anand.raman@ibsplc.com, www.ibsplc.com 




From:   Sergey Beryozkin <sb...@gmail.com>
To:     users@cxf.apache.org
Date:   03-02-11 04:08 PM
Subject:        Re: Problem with AbstractUsernameTokenInInterceptor



Hi

On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com> wrote:

> Hi,
>
> My requirement is to perform a custom authentication on the username and
> password that I receive as part of the UsernameToken header in the
> incoming SOAP request. I discovered that cxf-2.3.2 provides an
> AbstractUsernameTokenInInterceptor to perform this. I extended this 
class
> and created my interceptor that overrides the createSubject method. When 
I
> configure my interceptor in my beans.xml as shown below, I am getting an
> exception.
>
> This exception comes up when I use a password digest. The plain text
> password works fine. Is there any problem in the way I have configured 
my
> interceptor?
>
>
> Entry in beans.xml
>
>        <jaxws:endpoint id="echo"
> implementor="learn.wssecurity.echo.EchoServiceImpl"
>                wsdlLocation="wsdl/echo/EchoService.wsdl"
> address="/EchoService">
>                <jaxws:inInterceptors>
>                          <bean
> class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
>                </jaxws:inInterceptors>
>                <jaxws:properties>
>                        <entry key="ws-security.callback-handler"
> value="learn.wssecurity.echo.ServerPasswordCallback" />
>                        <entry key="ws-security.ut.no-callbacks"
> value="true" />
>                </jaxws:properties>
>        </jaxws:endpoint>
>
>

What is the purpose of registering ServerPasswordCallback ? If you set a
"ws-security.ut.no-callbacks" property then you only need a callback if 
you
have an encrypted UT, so that the UT can be decrypted.
So this callback that you're registering may be interfering in the case 
when
you have a hashed UT token, can you remove it please and see what happens 
?

Cheers, Sergey




>
> Exception
>
> java.lang.SecurityException: Security Token is not available on the
> current message
>        at
>
> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> 88)
>        at
>
> 
org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
>        at
>
> 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>        at
>
> 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>        at
>
> 
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>        at
>
> 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>        at
>
> 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>        at
>
> 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>        at
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>        at
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>        at
>
> 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>        at
>
> 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>        at
>
> 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at
>
> 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>        at
>
> 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>        at
>
> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>        at
>
> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at
>
> 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at
> 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>        at
> 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>        at
>
> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>        at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>        at java.lang.Thread.run(Thread.java:595)
>
> Thanks and regards,
> Anand R
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for
> the person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication.
> IBS makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy or completeness of the information contained in this email or 
any
> attachment and is not liable for any errors, defects, omissions, viruses
> or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>







DISCLAIMER: 

"The information in this e-mail and any attachment is intended only for 
the person to whom it is addressed and may contain confidential and/or 
privileged material. If you have received this e-mail in error, kindly 
contact the sender and destroy all copies of the original communication. 
IBS makes no warranty, express or implied, nor guarantees the accuracy, 
adequacy or completeness of the information contained in this email or any 
attachment and is not liable for any errors, defects, omissions, viruses 
or for resultant loss or damage, if any, direct or indirect."

Re: Problem with AbstractUsernameTokenInInterceptor

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi

On Thu, Feb 3, 2011 at 6:37 AM, Anand R <An...@ibsplc.com> wrote:

> Hi,
>
> My requirement is to perform a custom authentication on the username and
> password that I receive as part of the UsernameToken header in the
> incoming SOAP request. I discovered that cxf-2.3.2 provides an
> AbstractUsernameTokenInInterceptor to perform this. I extended this class
> and created my interceptor that overrides the createSubject method. When I
> configure my interceptor in my beans.xml as shown below, I am getting an
> exception.
>
> This exception comes up when I use a password digest. The plain text
> password works fine. Is there any problem in the way I have configured my
> interceptor?
>
>
> Entry in beans.xml
>
>        <jaxws:endpoint id="echo"
> implementor="learn.wssecurity.echo.EchoServiceImpl"
>                wsdlLocation="wsdl/echo/EchoService.wsdl"
> address="/EchoService">
>                <jaxws:inInterceptors>
>                          <bean
> class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/>
>                </jaxws:inInterceptors>
>                <jaxws:properties>
>                        <entry key="ws-security.callback-handler"
> value="learn.wssecurity.echo.ServerPasswordCallback" />
>                        <entry key="ws-security.ut.no-callbacks"
> value="true" />
>                </jaxws:properties>
>        </jaxws:endpoint>
>
>

What is the purpose of registering ServerPasswordCallback ? If you set a
"ws-security.ut.no-callbacks" property then you only need a callback if you
have an encrypted UT, so that the UT can be decrypted.
So this callback that you're registering may be interfering in the case when
you have a hashed UT token, can you remove it please and see what happens ?

Cheers, Sergey




>
> Exception
>
> java.lang.SecurityException: Security Token is not available on the
> current message
>        at
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java:
> 88)
>        at
>
> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47)
>        at
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>        at
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>        at
>
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>        at
>
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>        at
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>        at
>
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>        at
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>        at
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>        at
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>        at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>        at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
>        at
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>        at
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>        at
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
>        at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>        at
>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>        at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>        at java.lang.Thread.run(Thread.java:595)
>
> Thanks and regards,
> Anand R
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for
> the person to whom it is addressed and may contain confidential and/or
> privileged material. If you have received this e-mail in error, kindly
> contact the sender and destroy all copies of the original communication.
> IBS makes no warranty, express or implied, nor guarantees the accuracy,
> adequacy or completeness of the information contained in this email or any
> attachment and is not liable for any errors, defects, omissions, viruses
> or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>