Using STS and WCF having issue with unsecured or incorrectly secured fault exception

Question

I'm working with a couple of WCF services all secured using WIF and a STS provider (all using out of the box Microsoft code and examples). These services were all built using .NET 3.5 and have all been recently updated to .NET 4.0. ALL .dlls associated with the services have been updated to 4.0 as well. These services had worked as-is for years until I updated the framework versions.

The problem is now when a call is made to a WCF service that secured by the STS WCF service, there is an error generated after the token is passed back to client application that called the WCF service secured by the STS:

An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.

HResult -2146233087

{"An error occurred when processing the security tokens in the message."}

Server stack trace: at System.ServiceModel.Channels.SecurityChannelFactory1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout) at System.ServiceModel.Channels.SecurityChannelFactory1.SecurityRequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout) at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout) at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout) at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call(ServiceChannel channel, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade) at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at MyProject.IMyService.GetInfo() at MyProject.Proxy.GetInfo() in c:\Projects\Proxy.cs:line 36

Digging deeper it also shows:

InvalidSecurityToken as the InnerException.Code.Subcode.Name property value.

So I have looked at the following which all suggest an issue with the clock on the system, and none have worked:

http://blogs.msdn.com/b/dhrubach/archive/2009/12/14/9936037.aspx
An unsecured or incorrectly secured fault was received from the other party.(When working with SAML )
http://blogs.msdn.com/b/xiaowen/archive/2009/03/26/tip-add-a-clock-skew-to-prevent-some-security-faults.aspx?Redirected=true

I've attached to the debugger in these services and trying to walk through the code but I cannot find the culprit. Does anyone know where I might be amiss with this?

EDIT: The interesting thing is the tough part of the WIF in the STS service doing the authentication works! I have logging turned on and the following is captured:

Service authorization succeeded.  
Service: http:// localhost:4068 /MyID/MyID.svc  
Action: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue  
ClientIdentity: Domain\allen; S-1-5-21-1234567890-1234567895-0987654321-45678 
AuthorizationContext: uuid-22fad22a-22fe-123c-9b69-a22c23f569ce-99 
ActivityId: <null>  
ServiceAuthorizationManager: <default>

I've also turned on WCF logging in the .config to look at the .svc files, and they did not yield any error information pinpointing the issue. It's like the STS says: "Hey you are authenticated, we passed you and generated the token, and now we are done!" It seems the calling client does not like the token. However this has worked for eons untill I changed framework versions. From my knowledge there were not any major WIF changes from 3.5 -> 4.0, but rather the big changes were in 4.5 where WIF was integrated in the framework.

So all of the authorization works, it's just there is an issue with the token being accepted I suppose by the client?

Answer 1

First of all, what where your tracing options? Tracing only System.ServiceModel may not yield enough info. At the very least you should add System.ServiceModel.Activation, and probably a couple addtional ones related to WIF (and I would add System.Security).

I had a very similar error using STS and integrating a java client with a .net server. Here is how i solved it.

1. Build a new client for the service and have it connect to the server. Monitor messages with Fiddler
2. Do the same with the current client
3. Compare the messages sent. I know you can get them from the WCF trace log, but i like fiddler better.

I my case combining tracing with message inspection allowed me to find the error (a policy error on the java client, and a stupid code error on the service custom security policy)

Hope this helps!

Edit

Here is a link that sets up all tracing activity except for system.servicemodel.activation. It may come in handy

http://msdn.microsoft.com/en-us/library/ee517292.aspx

Answer 2

It could be that the Client has still both Versions of the framework installed.

Since the names of classes are the same in both, it could be that the Client is running code from the "wrong" Version of the framework.

To fix it you can fully qualify the class names.

see: http://msdn.microsoft.com/en-us/library/jj157089.aspx