WCF Client Certificate Authentication with Anonymous Access Disabled in IIS...Again. RRS feed

  • Question

  • Hi,

    I have spent a great deal of time and effort in both writing test code, and Googling for an answer to what based on the number of times it's been asked, would seem to be a straight-forward question for a common WCF use case:

    How to allow clients to authenticate to an IIS-hosted WCF Service using a certificate, WITHOUT having Anonymous Authentication enabled on the endpoint in IIS.

    Using basicHttpsBinding, wsHttpBinding and customBinding, I've tried configuring my WCF Service (and client) bindings for both Transport and TransportWithMessageCredential security modes with clientCredentialType="Certificate", and in the end, it ALWAYS comes down to the same error:

    "...Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service..."

    I have seen this question asked as far back as 2009, and have yet to see a satisfactory answer in which the "solution" doesn't end with Anonymous authentication being enabled in IIS anyway, and various hacks utilized to get around the implications of such a requirement.

    What I've come to believe is that for whatever reason, such a use case just cannot currently be implemented for an IIS-hosted WCF Web Service. I believe this behavior is either by design, or more likely a bug. I believe it is a bug because I can implement this use case for OTHER client authentication schemes such as "Basic". Meaning, that I can enable ONLY Basic Authentication in IIS, and specify the appropriate service and client configuration settings, and it works as expected. I suspect that it would also work with the other Authentication schemes (except certificates of course) as well. 

    In my mind, there is no logical reason why enabling Anonymous authentication is required in IIS for client certificate authentication, but (presumbly) not for the other authentication schemes .

    Based on my testing, the problem I'm seeing is that in the service configuration, when "Certificate" is specified as the Transport ClientCredentialType, instead of mapping to the IIS Certificate Mapping authentication scheme (iisClientCertificateMappingAuthentication), it instead, defaults to "Anonymous", and THAT is why Anonymous authentication MUST be enabled in IIS.

    I of course acknowledge that I could be wrong, and would welcome any responses that in fact show the successful implementation of this use case (or of course, provide a link to said implementation). Otherwise, it would be great if someone from Microsoft would confirm this behavior, and even better, acknowledge that it is an issue that will be looked into/resolved. :)


    Tuesday, December 11, 2018 3:25 PM

All replies

  • Hi Twebby1763,

    I'm not from Microsoft, but I think you're right. In the case I configured, IIS does need to enable anonymous authentication when a client uses a certificate as an identity credential.

    Best Regards


    Thursday, December 13, 2018 2:18 PM
  • Hi Abraham,

    Thanks for your response.

    Since I've posted, I've continued to test various scenarios, and have become even MORE convinced that the behavior/limitation/bug I've described is in fact the case...But, being an optimist, I hold out hope against all odds, that that this use-case can be implemented. :)

    I've done extensive (weeks) research on this issue, and I've found that the articles/blogs/posts on the Certificate Authentication topic generally fall in to three categories:

    1. Configuring Certificate Mapping in IIS, while omitting mention of the configuration of client apps that will actually authenticate to the server via Certificate Mapping

    2. Configuring Client Apps to authenticate to IIS using X.509 Certificates, but punting on the topic of IIS configuration; including, Certificate Mapping and/or the fact that Anonymous Authentication MUST be enabled in IIS in order for the client app to successfully authenticate via certificate.

    3. Those that purport to address this exact scenario, but don't actually work (e.g.: "Configuring client certificates for mutual authentication on IIS 8" on Medium dot com [h t t p s : / /]).

    It seems completely odd that in the first two instances -especially on the various MSDocs tutorial pages- that there seems to be an almost conscious effort to avoid addressing BOTH sides (client and server) of how to implement WCF Certificate Authentication in the same post...It's always from the standpoint of either server (IIS) OR service/client configuration.

    Regarding category #3, I will say, that after doing everything suggested by these "solutions", initially, it appeared to work. However, it was fools gold because what I discovered, was that when I recompiled and re-published my WCF web service, in IIS, Anonymous Authentication was being "silently" re-enabled for the web application. Which I suspect might have been the case with those posting "solutions" for this use-case, and they didn't realize it before posting their solution.

    I had to add an <authentication> section to my service's web.config, disabling Anonymous Authentication, to prevent it being reset during publishing.

    It's just mind boggling that after all these years, and countless questions on the topic, that Microsoft hasn't either definitively addressed it by adding guidance for the correct way to implement Certificate Authentication with Anonymous Access disabled, or fixed the issue by either adding "Certificate Authentication" to the list of Authentication options in IIS Manager, or at the very least, making sure that when Transport>clientCredentialType is set to "Certificate", it actually maps to the iisClientCertificateMapping authentication scheme that's enabled behind the scenes, when Client Certificate Mapping is configured via the site/application's Configuration Editor in IIS Manager.

    I believe I will probably cross-post this question to the IIS forum.

    Thanks again for your response Abraham.



    Friday, December 14, 2018 2:41 PM