Strange WSE error when trying to connect to web service

[edmicman]

I'm working on an ASP.NET 2.0 app with WSE 3.0, that is trying to connect to a web service that was written with ASP.NET 1.1 and WSE 2. It's close, but when I try to actually retrieve data, I'm getting this error:

System.Web.Services.Protocols.SoapHeaderException: System.Web.Services.Protocols.SoapHeaderException: Server unavailable, please try later ---> System.Configuration.ConfigurationException: WSE535: The following SecurityToken QName is unsupported: http://schemas.xmlsoap.org/ws/2005/02/sc:DerivedKeyToken.

I'm not finding hardly anything when searching for any of the phrases in the error - WSE535, qname, anything. Any ideas or pointers? Any more info that I can give that would help? Thanks!

[jwenting]

an explanation of that error should be available either from the MSDN (if it's a Microsoft error code), W3C, or WS-I.

[edmicman]

Unfortunately, searching for any specifics from that error message ("WSE535", "The following SecurityToken QName is unsupported", etc.) isn't turning up much. A lot of the google hits are Java related for some reason, and I'm not finding much that actually *explains* what that message might mean. Any tips on debugging web services, esp from a client standpoint?

[jwenting]

First result from an Apache mailing list:

I've developed a Web service secured with WSS4J. The client is a .NET
client using WSE. I'm using X509 tokens and the current configuration
works fine since early CVS releases of WSS4J. I recently upgraded to
1.5.0 and my java clients works fine. But the .NET client stopped
working with this message:

Message "WSE535: The following SecurityToken QName is unsupported:
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-wssecurity-secext-1.1.xsd:SignatureConfirmation.
Please check your configuration for registered SecurityToken qnames."

It seems to me that the new version works in WSS1.1 compliance so
following the specification sends the SignatureConfirmation. .NET is not
1.1 compliant so it doesn't expect that element.
I think anyway should exists a way to force WSS4J work in 1.0 mode
anyway, or to be backward compatible.

[jwenting]

And some replies:

Hello,
I am not sure .NET is wss11 compliant or not, but the wss11 namespace used
by WSS4J is outdated. The new namespace is: "
http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1"
I think this needs correction in WSS4J.

Thanks,
Ashutosh

I resolved setting ENABLE_SIGNATURE_CONFIRMATION to false. I think it's
wrong that WSS4J enables it by default since it's still based on
outdated specs..

[edmicman]

Thanks, I saw those results and didn't they they applied very well. It's *close*, but seems to be speaking to an Apache option. I'll check again and see if there's an equivalent .NET option. Thanks again for all your help!