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?

Superstar

I see 1 upvote and 1 downvote for the question. Please provide feedback so that the question can be improved if downvoting. I have tried to rpovide as much information as possible. – Superstar

You didn't really provide much, please show code how is your security set both in code and in web.config. What I can see from the exception stack, something went wrong during your security token handling on the WCF side. – Enmity

Just an idea but could you try to expose the client on an ssl endpoint? – Troglodyte

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

Postulate

I was trying to trace Microsoft.IdentityModel but it returned nothing. Is there a way to trace everything (even if it's really chatty) just to find everything instead of guessing? I tried * for the name="*" but it didn't work. – Superstar

I think you cant just enable tracing for all apps as you would on java (go figure) but at the very least you should include System.IdentityModel, System.ServiceModel, System.ServiceModel.Activation and System.ServiceModel.MessageLogging. – Postulate

In the System.ServiceModel log I see an exception that states the following: Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties. This can occur if the service is configured for security and the client is not using security. This was followed by a 'Warning' that stated: The security protocol cannot verify the incoming message. I started researching but to no avail. Does this sound like the root issue? – Superstar

One other comment - remember this worked for years in .NET 3.5, so the likelyhood of a mismatched binding out of thin air is unlikely IMO. – Superstar

Are you 100% sure that the client and server endpoints match, and i mean. ServiceContracts and DataContracts. I'm assuming that the bindings match otherwise you'd have other errors firts. But, again, are you sure that Service and DataContracts match? – Postulate

Also, endpoint identities, are you using one? If its host or dns based maybe some change in the network configuration is making thigs go south – Postulate

It's all on the same machine though so running through addresses using localhost. What do you make of that error? The binding is wsFederationHttpBinding – Superstar

I awarded you the bounty as it was expiring within the hour. This is still unsolved so help is still needed on my last. – Superstar

let us continue this discussion in chat – Postulate

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

Pemba

The issue is I'm targeting .NET 4.0 and not 4.5 when WIF was integrated into the framework. Therefore WIF for 3.5 or 4.0 uses the same method for implementation. The link speaks to the issues from 3.5 to 4.5 changes. Or is there something else on this front that can be applied when using .NET 4.0 like I am? – Superstar