Wcf – WIF STS ID3242: The security token could not be authenticated or authorized

sts-securitytokenservicewcfwif

I'm getting the following error in my client application when it tries to authenticate to my service:

ID3242: The security token could not be authenticated or authorized

Here is the configuration of the client:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
  <ws2007HttpBinding>
    <binding name="stsBinding">
      <security mode="Message">
        <message clientCredentialType="UserName"
          establishSecurityContext="false"
          negotiateServiceCredential="true"/>
      </security>
    </binding>
  </ws2007HttpBinding>
  <ws2007FederationHttpBinding>
    <binding name="echoClaimsBinding">
      <security mode="Message">
        <message>
          <claimTypeRequirements>
            <add claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" isOptional="false"/>
          </claimTypeRequirements>
          <issuer address="http://localhost:17240/STS.svc"
                  bindingConfiguration="stsBinding"
                  binding="ws2007HttpBinding">
            <identity>
              <dns value="WCFSTS"/>
            </identity>
          </issuer>
          <issuerMetadata address="http://localhost:17240/STS.svc/Mex"></issuerMetadata>
        </message>
      </security>
    </binding>
  </ws2007FederationHttpBinding>
</bindings>
<behaviors>
  <endpointBehaviors>
    <behavior name="echoClaimsBehavior">
      <clientCredentials>
        <serviceCertificate>
          <defaultCertificate
            findValue="CN=WCFSTS"
            storeLocation="LocalMachine"
            storeName="My"
            x509FindType="FindBySubjectDistinguishedName"/>
          <authentication
            revocationMode="NoCheck"
            certificateValidationMode="None"/>
        </serviceCertificate>
      </clientCredentials>
    </behavior>
  </endpointBehaviors>
</behaviors>
<client>
  <endpoint address="http://localhost:1438/EchoClaims.svc/EchoClaims"
            binding="ws2007FederationHttpBinding"
            bindingConfiguration="echoClaimsBinding"
            contract="TestService.IEchoClaims"
            name="WS2007FederationHttpBinding_IEchoClaims"
            behaviorConfiguration="echoClaimsBehavior">
    <identity>
      <dns value="WCFServer"/>
    </identity>
  </endpoint>
</client>
</system.serviceModel>
</configuration>

Here is the configuration of the service

<?xml version="1.0"?>
<configuration>
<configSections>
<section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>

<system.web>
<compilation debug="true" targetFramework="4.0">
  <assemblies>
    <add assembly="Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
  </assemblies>
</compilation>
</system.web>

<system.serviceModel>
<services>
  <service name="WcfService1.EchoClaims"
           behaviorConfiguration="echoClaimsBehavior">

    <endpoint address=""
              contract="WcfService1.IEchoClaims"
              binding="ws2007FederationHttpBinding"
              bindingConfiguration="echoClaimsBinding"></endpoint>
    <endpoint address="mex"
           binding="mexHttpBinding"
           contract="IMetadataExchange" />
  </service>
</services>
<behaviors>
  <serviceBehaviors>
    <behavior name="echoClaimsBehavior">

      <serviceMetadata httpGetEnabled="true" />
      <serviceCredentials>           
        <serviceCertificate 
          findValue="CN=WCFServer" 
          storeLocation="LocalMachine" 
          storeName="My" 
          x509FindType="FindBySubjectDistinguishedName" />
      </serviceCredentials>
    </behavior>
  </serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

<bindings>
  <ws2007FederationHttpBinding>
    <binding name="echoClaimsBinding">
      <security mode="Message">
        <message negotiateServiceCredential="true">
          <!--<issuerMetadata address="http://localhost:17240/STS.svc/mex" />-->
          <claimTypeRequirements>
            <!--Following are the claims offered by STS 'http://localhost:17240/STS.svc'. Add or uncomment claims that you require by your application and then update the federation metadata of this application.-->
            <add claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" isOptional="false" />               
          </claimTypeRequirements>
        </message>
      </security>
    </binding>
  </ws2007FederationHttpBinding>
</bindings>
<diagnostics>
  <messageLogging logEntireMessage="true"
                  logMessagesAtServiceLevel="true"
                  logMessagesAtTransportLevel="true"></messageLogging>
</diagnostics>
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
<microsoft.identityModel>
<service>
  <audienceUris mode="Never"/>        
  <issuerNameRegistry type="WcfService1.CustomIssuerNameRegistry, WcfService1"/>        
</service>
</microsoft.identityModel>
<system.diagnostics>
<sources>
  <source name="System.ServiceModel" switchValue="Warning, Error, ActivityTracing"
       propagateActivity="true">
    <listeners>
      <add name="ServiceModelTraceListener"/>
    </listeners>
  </source>
</sources>
<sharedListeners>
  <add initializeData="ecb_tracelog.svclog"
                type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
                name="ServiceModelTraceListener" traceOutputOptions="Timestamp">
    <filter type="" />
  </add>
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
</configuration>

Please let me know if anyone has an idea of how to determine why authentication is failing. I have Geneva STS tracing on verbose, but it's not giving me any messages about why the certificate isn't being authenticated.

Best Answer

In a similar situation, this forum post by Dominick Baier suggests that the web service rejects the token, so tracing at the STS would not show any problem.

He suggests to check this web service's <microsoft.identityModel><service><securityTokenHandlers><securityTokenHandlerConfiguration><audienceUris> section in its web.config, and to switch on the Microsoft.IdentityModel trace source in that same file.

Related Solutions

C# – Catch-22 prevents streamed TCP WCF service securable by WIF; ruining the Christmas, mental health

WCF has gotchas in a few areas with streaming (I'm looking at you, MTOM¹) due to a fundamental issue in how it fails to perform preauthentication the way most people would think that should work (it only affects subsequent requests for that channel, not the first request) Ok, so this is not exactly your issue but please follow along as I will get to yours at the end. Normally the HTTP challenge works like this:

client hits server anonymously
server says, sorry, 401, I need authentication
client hits server with authentication token
server accepts.

Now, if you ever try to enable MTOM streaming on an WCF endpoint on the server, it will not complain. But, when you configure it on the client proxy (as you should, they must match bindings) it will explode in a fiery death. The reason for this is that the above sequence of events that WCF is trying to prevent is this:

client streams 100MB file to server anonymously in a single POST
server says sorry, 401, I need authentication
client again streams 100MB file to server with an authentication header
server accepts.

Notice that you just sent 200MB to the server when you only needed to send 100MB. Well, this is the problem. The answer is to send the authentication on the first attempt but this is not possible in WCF without writing a custom behaviour. Anyway, I digress.

Your Problem

First up, let me tell you that what you're trying is impossible². Now, in order for you to stop spinning your wheels, let me tell you why:

It strikes me that you are now wandering in a similar class of problem. If you enable message level security, the client must load the entire stream of data into memory before it can actually close out the message with the usual hash function and xml signature required by ws-security. If it has to read the entire stream to sign the single message (which is not really a message, but it's a single continuous stream) then you can see the problem here. WCF will have to stream it once "locally" to compute the message security, then stream it again to send it to the server. This is clearly a silly thing, so WCF does not permit message level security for streaming data.

So, the simple answer here is that you should send the token either as a parameter to the initial web service, or as a SOAP header and use a custom behaviour to validate it. You cannot use WS-Security to do this. Frankly, this is not just a WCF issue - I cannot see how it could practically work for any other stacks.

Solving the MTOM Problem

This is just for an example how I solved my MTOM streaming issue for basic authentication, so perhaps you could take the guts of this and implement something similar for your issue. The crux of it is that in order to enable your custom message inspector, you have to disable all notion of security on the client proxy (it remains enabled on the server,) apart from transport level (SSL):

this._contentService.Endpoint.Behaviors.Add(
    new BasicAuthenticationBehavior(
        username: this.Settings.HttpUser,
        password: this.Settings.HttpPass));
var binding = (BasicHttpBinding)this._contentService.Endpoint.Binding;
binding.Security.Mode = BasicHttpSecurityMode.Transport; // SSL only            
binding.Security.Transport.ClientCredentialType = 
   HttpClientCredentialType.None; // Do not provide

Note that I have turned off transport security here because I will be providing that myself using a message inspector and custom behaviour:

internal class BasicAuthenticationBehavior : IEndpointBehavior
{
    private readonly string _username;
    private readonly string _password;

    public BasicAuthenticationBehavior(string username, string password)
    {
        this._username = username;
        this._password = password;
    }
    public void AddBindingParameters(ServiceEndpoint endpoint, 
        BindingParameterCollection bindingParameters) { }
    public void ApplyClientBehavior(ServiceEndpoint endpoint,
        ClientRuntime clientRuntime)
    {
        var inspector = new BasicAuthenticationInspector(
            this._username, this._password);
        clientRuntime.MessageInspectors.Add(inspector);
    }
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint,
        EndpointDispatcher endpointDispatcher) { }
    public void Validate(ServiceEndpoint endpoint) { }
}

internal class BasicAuthenticationInspector : IClientMessageInspector
{
    private readonly string _username;
    private readonly string _password;

    public BasicAuthenticationInspector(string username, string password)
    {
        this._username = username;
        this._password = password;
    }

    public void AfterReceiveReply(ref Message reply,
        object correlationState) { }

    public object BeforeSendRequest(ref Message request,
        IClientChannel channel)
    {
        // we add the headers manually rather than using credentials 
        // due to proxying issues, and with the 101-continue http verb 
        var authInfo = Convert.ToBase64String(
            Encoding.Default.GetBytes(this._username + ":" + this._password));

        var messageProperty = new HttpRequestMessageProperty();
        messageProperty.Headers.Add("Authorization", "Basic " + authInfo);
        request.Properties[HttpRequestMessageProperty.Name] = messageProperty;

        return null;
    }
}

So, this example is for anyone who is suffering with the MTOM issue, but also as a skeleton for you to implement something similar to authenticate your token generated by the primary WIF-secured token service.

Hope this helps.

(1) Large Data and Streaming

(2) Message Security in WCF (see "disadvantages.")

C# – How to solve System.ServiceModel.ServerTooBusyException in WCF

Check first if the App Pool is fine. If your application produces too much exceptions in a time period you would get the same error message.

In my experience often - if the relevant properties maxConcurrentInstances and maxConcurrentSessions are correctly set like here - it is something faulty in the web.config when this error occures.

Best Answer

Related Solutions

C# – Catch-22 prevents streamed TCP WCF service securable by WIF; ruining the Christmas, mental health

C# – How to solve System.ServiceModel.ServerTooBusyException in WCF

Related Topic