December 16, 2011 1 Comment
Multiple authentication support for a single endpoint is a feature which will be shipped with WCF 4.5. This is a very cool feature to make sure that we as developers can easier test our integration with multiple authentication scenarios.
When you are integrating systems, you always run into challenges where you have to simulate external systems through you Development, Test & Acceptance environments. Especially at your Development and Test environments. Building stubs is a way to simulate external systems. Unfortunately external systems mostly use different kind of authentication mechanisms, so your stubs need to support different kind of authentication mechanisms. Something want you don’t want is managing multiple stubs or provide different configuration files to make sure that your stub is able to support multiple authentication mechanisms.
Something what I tried was using the following configuration file:
<system.serviceModel> <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> <bindings> <basicHttpBinding> <binding name="Integrated"> <security mode="TransportCredentialOnly"> <transport clientCredentialType="Windows"/> </security> </binding> <binding name="Basic"> <security mode="TransportCredentialOnly"> <transport clientCredentialType="Basic"/> </security> </binding> </basicHttpBinding> </bindings> <services> <service name="MyService"> <endpoint address="IntegratedEndpoint" binding="basicHttpBinding" bindingConfiguration="Integrated" contract="IMyContract"/> <endpoint address="BasicEndpoint" binding="basicHttpBinding" bindingConfiguration="Basic" contract="IMyContract"/> </service> </services> </system.serviceModel>
I have defined two bindings to make sure that my service will be able to do Windows integrated security and basic authentication. Each binding is referenced by one endpoint. This way I am able to specify what kind of security mode I would like to use by specifying the right URL.
The problem comes when I deploy this stub to a website which is configured for integrated security and another website which is configured for basic authentication. Before my WCF service will be hosted in IIS there is a validation check on my configuration. When I browse to my service which is hosted within my integrated website I will receive the following error:
“Security settings for this service require ‘Basic’ Authentication but it is not enabled for the IIS application that hosts this service”
So my configuration tells IIS that it will accept Basic authentication, but IIS isn’t supporting Basic authentication. Right now there are three ways to fix this issue:
- Build multiple stubs with there own configuration file
- Build one stub with multiple configuration files
- Build one stub with one configuration file and use xml preprocess
Build multiple stubs with there own configuration file
Well this isn’t a real option, right? to much code redundant so we will skip this one.
Build one stub with multiple configuration files
When you build your installation package you make sure the right configuration file is included in your package. This means you have to manage multiple configuration files
Build one stub with one configuration file and use xml preprocess
Xml preprocess provides the opportunity to write if- else statements in your configuration file. This way you can process your configuration file using parameters to make sure the right configuration file will be produced for the right website.
So all this stuff to deploy a stub which should run in IIS and should support multiple authentication protocols. The problem is the difference between settings in your web.config and IIS. In WCF 4.5 they offer you the possibility to inherit the settings from IIS into your configuration file. So when you website is running integrated security your service will run with integrated security. This way you have one stub, one configuration file which can be deployed to multiple websites with different authentication protocols.
Take a look at a post of Ido Flatow who describes how to configure your configuration file.