You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by huidong <hu...@yahoo.com> on 2010/02/03 00:22:08 UTC

An invalid security token was provided (Bad UsernameToken Values)

i am running a .Net WCF client to call a service on linux host with CXF
framework. 

the inbound message looks like:

Payload: <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

<s:Header><a:Action
s:mustUnderstand="1"/><a:MessageID>urn:uuid:7f809251-17cb-4319-9fd8-04889601e956</a:MessageID>

<a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo>

<a:To
s:mustUnderstand="1">https://sas/ws/saw/services/SawSelfServices</a:To>

<o:Security s:mustUnderstand="1"
xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<u:Timestamp
u:Id="_0"><u:Created>2010-02-02T22:10:48.955Z</u:Created><u:Expires>2010-02-02T22:15:48.955Z</u:Expires></u:Timestamp>

<o:UsernameToken u:Id="uuid-17aef8db-845a-4b9c-bceb-f8cde31933b6-1
<o:Username>wstest</o:Username>
<o:Password
o:Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">*****</o:Password>
</o:UsernameToken>

</o:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">****</s:Body>
</s:Envelope>

I received a error message:

[14:10:53.081] {http--81-5$573121065}
org.apache.ws.security.WSSecurityException: An invalid security token was
provided (Bad UsernameToken Values)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.ws.security.message.token.UsernameToken.<init>(UsernameToken.java:179)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(UsernameTokenProcessor.java:56)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:326)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:243)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:199)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:78)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:406)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
[14:10:53.081] {http--81-5$573121065}   at
javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
[14:10:53.081] {http--81-5$573121065}   at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
[14:10:53.081] {http--81-5$573121065}   at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[14:10:53.081] {http--81-5$573121065}   at
com.caucho.server.security.SecurityFilterChain.doFilter(SecurityFilterChain.java:134)
[14:10:53.081] {http--81-5$573121065}   at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
[14:10:53.081] {http--81-5$573121065}   at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
[14:10:53.081] {http--81-5$573121065}   at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
[14:10:53.081] {http--81-5$573121065}   at
com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
[14:10:53.081] {http--81-5$573121065}   at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)


what was wrong?? i cannot see anything invalid. and a java client just runs
fine. any help will be greatly appreciated!

-- 
View this message in context: http://old.nabble.com/An-invalid-security-token-was-provided-%28Bad-UsernameToken-Values%29-tp27429163p27429163.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: An invalid security token was provided (Bad UsernameToken Values)

Posted by huidong <hu...@yahoo.com>.
I googled more, and found this link:

http://marc.info/?l=wss4j-dev&m=124386256631302&w=2

it seems it is a on-going issue for a while. Microsoft messed it up.
however, how to get around it? 

interop is so frustrating.



huidong wrote:
> 
> i am running a .Net WCF client to call a service on linux host with CXF
> 2.2.6 framework. 
> 
> the inbound message looks like:
> 
> Payload: <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
> xmlns:a="http://www.w3.org/2005/08/addressing"
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
> 
> <s:Header><a:Action
> s:mustUnderstand="1"/><a:MessageID>urn:uuid:7f809251-17cb-4319-9fd8-04889601e956</a:MessageID>
> 
> <a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo>
> 
> <a:To
> s:mustUnderstand="1">https://sas/ws/saw/services/SawSelfServices</a:To>
> 
> <o:Security s:mustUnderstand="1"
> xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
> 
> <u:Timestamp
> u:Id="_0"><u:Created>2010-02-02T22:10:48.955Z</u:Created><u:Expires>2010-02-02T22:15:48.955Z</u:Expires></u:Timestamp>
> 
> <o:UsernameToken u:Id="uuid-17aef8db-845a-4b9c-bceb-f8cde31933b6-1
> <o:Username>wstest</o:Username>
> <o:Password
> o:Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">*****</o:Password>
> </o:UsernameToken>
> 
> </o:Security>
> </s:Header>
> <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema">****</s:Body>
> </s:Envelope>
> 
> I received a error message:
> 
> [14:10:53.081] {http--81-5$573121065}
> org.apache.ws.security.WSSecurityException: An invalid security token was
> provided (Bad UsernameToken Values)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.message.token.UsernameToken.<init>(UsernameToken.java:179)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(UsernameTokenProcessor.java:56)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:326)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:243)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:199)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:78)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:406)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> [14:10:53.081] {http--81-5$573121065}   at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
> [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.security.SecurityFilterChain.doFilter(SecurityFilterChain.java:134)
> [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
> [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
> [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
> [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
> [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
> 
> 
> what was wrong?? i cannot see anything invalid. i am using WSHttpBinding
> to connect to CXF services. and a java client just runs fine. any help
> will be greatly appreciated!
> 
> 

-- 
View this message in context: http://old.nabble.com/An-invalid-security-token-was-provided-%28Bad-UsernameToken-Values%29-tp27429163p27444367.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: An invalid security token was provided (Bad UsernameToken Values)

Posted by Daniel Kulp <dk...@apache.org>.
On Wed February 3 2010 4:23:51 pm huidong wrote:
> According to spec, the "Username" and "Password" child elements of
> "UsernameToken" are NOT supposed to be qualified.   The message you put
>  here has them qualified.
> 
> I think there is a setting in the WSConfig object to allow accepting the
>  out of spec name/passwords, I'm just not sure how that would be used with
>  the WSS4JInInterceptor.   I added some code last week to allow configuring
>  in a specific WSConfig object relatively easily, but that's not available
>  in a release yet.
> 
> Dan
> 
> thanks Dan.
> 
> this is the java client message that works. the only difference is the
> "Type" attribute is simple "Type" instead of "wsse:Type". could this be the
> reason?

Oops.. Yea.  That's the reason.   The attributes are supposed to not be 
qualified, not the elements.   So  "Type", not "wsse:Type".   The config thing 
I mentioned earlier gets around that.

Dan


> 
> 
> <wsse:UsernameToken
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
> ity-secext-1.0.xsd"
>  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
> ity-utility-1.0.xsd" wsu:Id="UsernameToken-1">
> 
> <wsse:Username>ws***</wsse:Username>
> <wsse:Password
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-toke
> n-profile-1.0#PasswordText">*****</wsse:Password>
> 
> </wsse:UsernameToken>
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: An invalid security token was provided (Bad UsernameToken Values)

Posted by Antoine Roux <an...@net-vitesse.com>.
Hi,
I know this is a bit dated, but I just wanted to mention that I had exactly
the same problem with CXF 2.2.5 and that Dan's solution worked perfectly.
In the startup of my application, I added at some point
WSSConfig.getDefaultWSConfig()
.setAllowNamespaceQualifiedPasswordTypes(true). It worked!

Thanks Dan.



On Fri, Feb 5, 2010 at 12:48 AM, huidong <hu...@yahoo.com> wrote:

>
> i am using the latest 2.2.6. can you elaborate how to pass WSconfig object?
> my configuration is something like:
>
> <jaxws:inInterceptors>
>
>      <bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
>        <constructor-arg>
>          <map>
>            <entry key="action" value="UsernameToken" />
>            <entry key="passwordType" value="PasswordText" />
>            <entry key="passwordCallbackClass"
> value="***.ws.impl.PasswordCallback" />
>            <entry key="allowNamespaceQualifiedPasswordTypes" value="true"
> />
>          </map>
>        </constructor-arg>
>      </bean>
>    </jaxws:inInterceptors>
>
> this way, after i modified WSS4JInInterceptor, it works fine for both
> java/.Net clients.
>
>
> dkulp wrote:
> >
> >
> >
> > Well, the code on trunk is a bit different now in that the WSConfig
> object
> > that is used can be passed in as a property.    Thus, with that, it's
> much
> > easier.
> >
> > One option for you COULD be to do something like:
> >
> >
> WSSConfig.getDefaultWSConfig().setAllowNamespaceQualifiedPasswordTypes(true);
> >
> > in some user code or something at startup.  That should set the default
> > config
> > object to allow it which would then be used for processsing.
> >
> > Dan
> >
>
> --
> View this message in context:
> http://old.nabble.com/An-invalid-security-token-was-provided-%28Bad-UsernameToken-Values%29-tp27429163p27461028.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>

Re: An invalid security token was provided (Bad UsernameToken Values)

Posted by huidong <hu...@yahoo.com>.
i am using the latest 2.2.6. can you elaborate how to pass WSconfig object?
my configuration is something like:

<jaxws:inInterceptors>
      
      <bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
        <constructor-arg>
          <map>       
            <entry key="action" value="UsernameToken" />
            <entry key="passwordType" value="PasswordText" />                  
            <entry key="passwordCallbackClass"
value="***.ws.impl.PasswordCallback" />
            <entry key="allowNamespaceQualifiedPasswordTypes" value="true"
/>
          </map>
        </constructor-arg>
      </bean>
    </jaxws:inInterceptors>

this way, after i modified WSS4JInInterceptor, it works fine for both
java/.Net clients.


dkulp wrote:
> 
> 
> 
> Well, the code on trunk is a bit different now in that the WSConfig object 
> that is used can be passed in as a property.    Thus, with that, it's much 
> easier.
> 
> One option for you COULD be to do something like:
> 
> WSSConfig.getDefaultWSConfig().setAllowNamespaceQualifiedPasswordTypes(true);
> 
> in some user code or something at startup.  That should set the default
> config 
> object to allow it which would then be used for processsing.
> 
> Dan
> 

-- 
View this message in context: http://old.nabble.com/An-invalid-security-token-was-provided-%28Bad-UsernameToken-Values%29-tp27429163p27461028.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: An invalid security token was provided (Bad UsernameToken Values)

Posted by Daniel Kulp <dk...@apache.org>.
On Thu February 4 2010 12:31:36 pm huidong wrote:
> Dan,
> 
> you are right. there is a setting in the WSSConfig obj to allow accepting
> out of spec password. however, WSS4JInInterceptor does not set WSSConfig
> before this call:
> 
> wsResult = getSecurityEngine().processSecurityHeader(...)
> 
> therefore, the securityEngine simply get the default WSSConfig, the setting
> does not take effect. i think the correct way should be:
> 
> getSecurityEngine().setWssConfig(reqData.getWssConfig());
> wsResult = getSecurityEngine().processSecurityHeader(...)
> 
> am i right?

Well, the code on trunk is a bit different now in that the WSConfig object 
that is used can be passed in as a property.    Thus, with that, it's much 
easier.

One option for you COULD be to do something like:

WSSConfig.getDefaultWSConfig().setAllowNamespaceQualifiedPasswordTypes(true);

in some user code or something at startup.  That should set the default config 
object to allow it which would then be used for processsing.

Dan


> 
> dkulp wrote:
> > According to spec, the "Username" and "Password" child elements of
> > "UsernameToken" are NOT supposed to be qualified.   The message you put
> > here
> > has them qualified.
> >
> > I think there is a setting in the WSConfig object to allow accepting the
> > out
> > of spec name/passwords, I'm just not sure how that would be used with the
> > WSS4JInInterceptor.   I added some code last week to allow configuring in
> > a
> > specific WSConfig object relatively easily, but that's not available in a
> > release yet.
> >
> > Dan
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: An invalid security token was provided (Bad UsernameToken Values)

Posted by huidong <hu...@yahoo.com>.

Dan, 

you are right. there is a setting in the WSSConfig obj to allow accepting
out of spec password. however, WSS4JInInterceptor did not set WSSConfig
before this call:

wsResult = getSecurityEngine().processSecurityHeader(...)

therefore, the securityEngine simply get the default WSSConfig, the setting
does not take effect. i think the correct way should be:

getSecurityEngine().setWssConfig(reqData.getWssConfig());
wsResult = getSecurityEngine().processSecurityHeader(...)

am i right?



dkulp wrote:
> 
> 
> According to spec, the "Username" and "Password" child elements of 
> "UsernameToken" are NOT supposed to be qualified.   The message you put
> here 
> has them qualified.  
> 
> I think there is a setting in the WSConfig object to allow accepting the
> out 
> of spec name/passwords, I'm just not sure how that would be used with the 
> WSS4JInInterceptor.   I added some code last week to allow configuring in
> a 
> specific WSConfig object relatively easily, but that's not available in a 
> release yet.   
> 
> Dan
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/An-invalid-security-token-was-provided-%28Bad-UsernameToken-Values%29-tp27429163p27456566.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: An invalid security token was provided (Bad UsernameToken Values)

Posted by huidong <hu...@yahoo.com>.



According to spec, the "Username" and "Password" child elements of 
"UsernameToken" are NOT supposed to be qualified.   The message you put here 
has them qualified.  

I think there is a setting in the WSConfig object to allow accepting the out 
of spec name/passwords, I'm just not sure how that would be used with the 
WSS4JInInterceptor.   I added some code last week to allow configuring in a 
specific WSConfig object relatively easily, but that's not available in a 
release yet.   

Dan

thanks Dan.

this is the java client message that works. the only difference is the
"Type" attribute is simple "Type" instead of "wsse:Type". could this be the
reason?


<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>ws***</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">*****</wsse:Password>

</wsse:UsernameToken>

-- 
View this message in context: http://old.nabble.com/An-invalid-security-token-was-provided-%28Bad-UsernameToken-Values%29-tp27429163p27443711.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: An invalid security token was provided (Bad UsernameToken Values)

Posted by Daniel Kulp <dk...@apache.org>.
According to spec, the "Username" and "Password" child elements of 
"UsernameToken" are NOT supposed to be qualified.   The message you put here 
has them qualified.  

I think there is a setting in the WSConfig object to allow accepting the out 
of spec name/passwords, I'm just not sure how that would be used with the 
WSS4JInInterceptor.   I added some code last week to allow configuring in a 
specific WSConfig object relatively easily, but that's not available in a 
release yet.   

Dan


On Tue February 2 2010 6:22:08 pm huidong wrote:
> i am running a .Net WCF client to call a service on linux host with CXF
> framework.
> 
> the inbound message looks like:
> 
> Payload: <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
> xmlns:a="http://www.w3.org/2005/08/addressing"
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity
> -utility-1.0.xsd">
> 
> <s:Header><a:Action
> s:mustUnderstand="1"/><a:MessageID>urn:uuid:7f809251-17cb-4319-9fd8-0488960
> 1e956</a:MessageID>
> 
> <a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Add
> ress></a:ReplyTo>
> 
> <a:To
> s:mustUnderstand="1">https://sas/ws/saw/services/SawSelfServices</a:To>
> 
> <o:Security s:mustUnderstand="1"
> xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity
> -secext-1.0.xsd">
> 
> <u:Timestamp
> u:Id="_0"><u:Created>2010-02-02T22:10:48.955Z</u:Created><u:Expires>2010-02
> -02T22:15:48.955Z</u:Expires></u:Timestamp>
> 
> <o:UsernameToken u:Id="uuid-17aef8db-845a-4b9c-bceb-f8cde31933b6-1
> <o:Username>wstest</o:Username>
> <o:Password
> o:Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-to
> ken-profile-1.0#PasswordText">*****</o:Password> </o:UsernameToken>
> 
> </o:Security>
> </s:Header>
> <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema">****</s:Body>
> </s:Envelope>
> 
> I received a error message:
> 
> [14:10:53.081] {http--81-5$573121065}
> org.apache.ws.security.WSSecurityException: An invalid security token was
> provided (Bad UsernameToken Values)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.message.token.UsernameToken.<init>(UsernameToken.jav
> a:179) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken
> (UsernameTokenProcessor.java:91) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(Usernam
> eTokenProcessor.java:56) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEng
> ine.java:326) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEng
> ine.java:243) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInIn
> terceptor.java:199) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInIn
> terceptor.java:78) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:243) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationO
> bserver.java:109) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestinati
> on.java:98) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(Servle
> tController.java:406) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController
> .java:178) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServl
> et.java:142) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(Abstract
> HTTPServlet.java:179) [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPSer
> vlet.java:103) [14:10:53.081] {http--81-5$573121065}   at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
> [14:10:53.081] {http--81-5$573121065}   at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPSe
> rvlet.java:159) [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.j
> ava:103) [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.security.SecurityFilterChain.doFilter(SecurityFilterChain
> .java:134) [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:
> 187) [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java
> :265) [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
> [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
> [14:10:53.081] {http--81-5$573121065}   at
> com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
> 
> 
> what was wrong?? i cannot see anything invalid. and a java client just runs
> fine. any help will be greatly appreciated!
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog