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 <[email protected]>
To: [email protected]
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
<[email protected]>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
<[email protected]>wrote:
>
>> Hi Anand
>>
>> On Fri, Feb 4, 2011 at 6:50 AM, Anand R <[email protected]> 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 <[email protected]>
>>> To: [email protected]
>>> 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 <[email protected]>
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 <[email protected]>
>>> > To: [email protected]
>>> > 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 <[email protected]>
>>> wrote:
>>> >
>>> > > Thanks Sergy. I will try the custom UsernameTokenProcessor.
>>> > > Thanks and regards,
>>> > > Anand R
>>> > >
>>> > >
>>> > >
>>> > > From: Sergey Beryozkin <[email protected]>
>>> > > To: [email protected]
>>> > > 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 <[email protected]>
>>> 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 - [email protected], www.ibsplc.com
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > From: Sergey Beryozkin <[email protected]>
>>> > > > To: [email protected]
>>> > > > Date: 03-02-11 04:08 PM
>>> > > > Subject: Re: Problem with
AbstractUsernameTokenInInterceptor
>>> > > >
>>> > > >
>>> > > >
>>> > > > Hi
>>> > > >
>>> > > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <[email protected]>
>>> > 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."
