如何在 WCF 服务的所有后续 HTTP 请求标头中获得身份验证 cookies？

Question

I am having troubles getting authentication cookies placed into the HTTP Request Headers of a client Windows Service consuming a WCF Service hosted in IIS that is using 'Sessions'. The client app uses Forms Authentication to gain access to the WCF Service. After a successful Authentication, I capture the HTTP Response header contains a Set-Cookie for.ASPXAUTH and a Set-Cookie for ASP.NET_SessionId. I add these cookies to the HTTP Request header for all subsequent requests to the WCF Service. Using the Fiddler debugging tool I can see that for every request to the WCF service, two HTTP Requests are sent. The first HTTP Request header does not contain the cookies but the second HTTP Request does. When I secure the service by setting the Authorization section of the web.config to 'deny users=”?”', the first HTTP Request without the cookies in the header forces a 'Redirect' back to login preventing access to the service. The first request I believe to be related to the use of 'Sessions'. When I disable 'Sessions' in my WCF Service, I get only one HTTP Request per WCF call and the cookies are in the header. How do I get the cookies returned from Authentication in all of the HTTP Request headers sent to my WCF Service? Any help with this issue would be very much appreciated.

I have included my bindings from the client.

  <customBinding>
    <binding name="CustomBinding_IMySyncService" receiveTimeout="00:01:00"
      sendTimeout="00:01:00">
      <reliableSession acknowledgementInterval="00:00:30"
                       inactivityTimeout="00:03:00"
                       maxTransferWindowSize="4096" />
      <binaryMessageEncoding maxReadPoolSize="2147483647" maxWritePoolSize="2147483647">
        <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
          maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
      </binaryMessageEncoding>
      <httpsTransport manualAddressing="false" maxBufferPoolSize="2147483647"
        maxReceivedMessageSize="2147483647" allowCookies="false" authenticationScheme="Anonymous"
        bypassProxyOnLocal="false" decompressionEnabled="true" hostNameComparisonMode="StrongWildcard"
        keepAliveEnabled="true" maxBufferSize="2147483647" proxyAuthenticationScheme="Anonymous"
        realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"
        useDefaultWebProxy="true" />
    </binding>
    <binding name="CustomBinding_AuthenticationService">
      <binaryMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16">
        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
          maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      </binaryMessageEncoding>
      <httpsTransport manualAddressing="false" maxBufferPoolSize="524288"
        maxReceivedMessageSize="65536" allowCookies="false" authenticationScheme="Anonymous"
        bypassProxyOnLocal="false" decompressionEnabled="true" hostNameComparisonMode="StrongWildcard"
        keepAliveEnabled="true" maxBufferSize="65536" proxyAuthenticationScheme="Anonymous"
        realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"
        useDefaultWebProxy="true" />
    </binding>
  </customBinding>

Answer 1

I guess by session you mean reliable session allowed in your binding. Reliable session sends infrastructure messages which are out of your control. The modifying that behavior with demand some modification on very low level of WCF channel stack.

If you want to use ASP.NET session handled by cookies you have to use ASP.NET compatibility mode. Even with ASP.NET compatibility WCF doesn't suppose that authentication will be handled by cookies - the correct way is authenticating each request. WCF also by default doesn't use cookies at all.

ASP.NET compatibility mode is supposed to be used with plain web services - as backward compatibility with old ASMX web services. So it doesn't have to work with more advanced protocols like WS-Reliable Session. Use either reliable session or ASP.NET compatibility - not both.

Once you are using reliable session you already have WCF session (the single service instance handles all request from the same client proxy instance) so you don't need ASP.NET session. If you use built-in WCF security pipeline authentication credentials should be send by the proxy automatically within each message.