/// <summary>
/// A WCF service client.
/// </summary>
/// <typeparam name="TContract">The type of the service contract.</typeparam>
internal class ServiceClient<TContract> : IDisposable
	where TContract : class
{
	/// <summary>
	/// The service client object.
	/// </summary>
	private TContract client;

	/// <summary>
	/// Initializes a new instance of the ServiceClient class.
	/// </summary>
	/// <param name="endpointName">The name of the endpoint to use.</param>
	public ServiceClient(string endpointName)
	{
		ChannelFactory<TContract> f = new ChannelFactory<TContract>(endpointName);
		this.client = f.CreateChannel();
	}

	/// <summary>
	/// Calls an operation on the service.
	/// </summary>
	/// <typeparam name="TResult">The type of the object returned by the service operation.</typeparam>
	/// <param name="operation">The operation to call.</param>
	/// <returns>The results of the service operation.</returns>
	public TResult ServiceOperation<TResult>(Func<TContract, TResult> operation)
	{
		return operation(this.client);
	}

	/// <summary>
	/// Calls an operation on the service.
	/// </summary>
	/// <param name="operation">The operation to call.</param>
	public void ServiceOperation(Action<TContract> operation)
	{
		operation(this.client);
	}

	/// <summary>
	/// Disposes this object.
	/// </summary>
	public void Dispose()
	{
		try
		{
			if (this.client != null)
			{
				IClientChannel channel = this.client as IClientChannel;
				if (channel.State == CommunicationState.Faulted)
				{
					channel.Abort();
				}
				else
				{
					channel.Close();
				}
			}
		}
		finally
		{
			this.client = null;
			GC.SuppressFinalize(this);
		}
	}
}

With this class, you can call an operation SaveEmployee on a service with an IEmployeeService interface like this:

using (var client = new ServiceClient<IEmployeeService>("EmployeeEndpoint"))
{
	var response = client.ServiceOperation<EmployeeResponse>(
		c => c.SaveEmployee(request));
}

Wrapping the call in a using block means the client object is correctly closed and disposed, using the IDisposable interface. And if you’re calling an operation that doesn’t return anything, you can use the overload of ServiceOperation that takes in an Action.

So, the local Person business class will be something like this:

public class Person
{
    public string Forename { get; set; }

    public string Surname { get; set; }

    public int Age { get; set; }
}

We want to call a WCF service called EmployeeService, which has an operation SaveEmployee(). This operation takes a person to save as a parameter. The type of this parameter is Employee, which svcutil has created for us in the service proxy. This may look something like this:

internal partial class Employee :
    object, System.Runtime.Serialization.IExtensibleDataObject
{
    private string FirstNameField;
    private string LastNameField;
    private int AgeField;

    [System.Runtime.Serialization.DataMemeberAttribute()]
    internal string FirstName
    {
        get { return this.FirstNameField; }
        set { this.FirstNameField = value; }
    }

    [System.Runtime.Serialization.DataMemeberAttribute()]
    internal string LastName
    {
        get { return this.LastNameField; }
        set { this.LastNameField = value; }
    }

    [System.Runtime.Serialization.DataMemeberAttribute()]
    internal int Age
    {
        get { return this.AgeField; }
        set { this.AgeField = value; }
    }
}

As the service operation SaveEmployee needs an Employee and we have a Person, we need to translate from the latter to the former. An extension object can do this for us nicely:

internal static class PersonTranslator
{
    public static Employee TranslateToEmployee(this Person person)
    {
        return new Employee()
        {
            FirstName = person.Forename,
            LastName = person.Surname,
            Age = person.Age
        };
    }
}

Now the call to the service operation is nice and clear:

public SaveEmployee(Person person)
{
    var client = new EmployeeServiceClient();
    client.SaveEmployee(person.TranslateToEmployee());
    client.Close();
}

After all that setup, I could use Internet Explorer to browse to the site fine – integrated Windows Authentication would let me in. However, as the DNS had yet to be set up, and the web server and the website had the same IP address, I was browsing using the machine name, e.g. http://machine.domain/website instead of http://dnsname.co.uk/website.

When the DNS was set up and I tried to browse to the website, I got a Windows user name & password box popping up. After 3 tries I was denied access (a 401 error). Just changing the DNS name to the machine name in the location bar let me in, even though they were both the same IP address!

Using Fiddler, I could see the initial client GET request, and the server’s 401 challenge response, including a WWW-Authenticate header set to “Negotiate”. This occurred in both cases (browsing to the DNS name and to the machine name). However, the client response to this challenge was different in each case. The Negotiate token the client sent to the DNS name was much shorter than the one sent to the machine name. Clearly something was telling the client not to send the proper Kerberos authentication token to the DNS name.

Just looking at the HTTP traffic was not enough here – for cases like these a lower-level tool like Microsoft’s Network Monitor is required, or Wireshark if you’re feeling hardcore. This showed that the client was encountering a Kerberos error. A bit of searching around this and…

A magic SPN setting will solve this, all explained in a handy MSDN article. You will need to run this command (I ran it on the web server itself, however this may not be necessary):

setspn -A HTTP/[dns name of the site] [machine name]

Then a reboot of the web server, and a few hours’ wait for the settings to propagate around the domain. This will allow clients to send complete Kerberos authentication tokens to the website. Problem solved!

The test certificate’s subject looked like this:

CN = TestCertName

Whereas the environment certificate’s subject looked like:

CN = CertName
OU = Company Ltd.
O = Company
L = Town
S = County
C = Country Code

All the examples I’ve seen just cover certificates with the CN part. This is straightforward to reference in the WCF config:

<serviceCredentials>
   <serviceCertificate
            storeLocation="LocalMachine"
            storeName="My"
            findValue="CN=TestCertName"
            x509FindType="FindBySubjectDistinguishedName" />
</serviceCredentials>

However, when the certificate subject has multiple parts (i.e. more than just CN), you need to put all of them in the findValue attribute. But how to separate them? I tried several characters – space, comma, semicolon, colon – none worked. The certificate could not be found! Finally I noticed that in the top part of the certificate’s properties window, the values are separated by a comma and a space. Unbelievably, this also applies to the config! How intuitive. So for the “CertName” certificate above, here’s how to reference it in the WCF config:

<serviceCredentials>
   <serviceCertificate
            storeLocation="LocalMachine"
            storeName="My"
            findValue="CN=TestCertName, OU=Company Ltd., O=Company, L=Town, S=County, C=Country Code"
            x509FindType="FindBySubjectDistinguishedName" />
</serviceCredentials>

It’s fairly simple to set this up once you know what needs doing. Getting to that stage wasn’t the most fun I’ve ever had – the MSDN articles on the subject are useful, but they seem to want to cover at least 3 topics at a time, which can be a little confusing.

The scenario was this: an intranet web application would authenticate users using Windows Authentication, granting access based on their Active Directory roles. The application would access the back-end SQL Server database using Integrated Security, with the credentials of the current user. This gives two main advantages – you don’t have to setup or administer a separate account or accounts for the database, and auditing via SQL triggers is easy. However, this approach is only really suited to an intranet scenario, as database connection pools are used on a per-user basis. Too many users and the database will not be happy.

The setup is in four parts.

ASP.Net

Under the <system.web> section of your web.config, add the following:

<authentication mode="Windows"/>
<identity impersonate="true"/>

Also, make sure you’re using a connection string that uses Integrated Security.

IIS

I’m using IIS7, which has some more detailed settings than IIS6. In the website or virtual directory, ensure that Anonymous Authentication and Forms Authentication are disabled, and ASP.Net Impersonation and Windows Authentication are enabled. IIS should pick this up from web.config.

IIS7 lets you specify “providers” for Windows Authentication. You must use the Negotiate:Kerberos provider. Choosing this provider will mean that “Kernel-mode authentication” cannot be used. This is disabled under the Advanced Settings within the Authentication section.

Active Directory

The web server’s Active Directory properties must be edited to enable Delegation of credentials onto the SQL server. There’s a great explanation with a screen grab of the Active Directory property page in a post from Ken Schaefer.

Windows Server 2003 domains and later support Constrained Delegation, which can constrain the delegation to a specific service on the target machine. This is obviously more secure. To delegate to SQL Server, MSSQLSvc is the service you need.

SQL Server

All you need to do at the database level is grant the relevant permissions for the users or roles you want accessing the database.

Now it should all magically work!

UPDATE: That might not be all! See Part 2.

I realised I’d also employed my anal side to change the names of the private backing fields for the properties. Might as well try out the code plugin here, so… I changed this:

private int SomePropertyField;

public int SomeProperty {
   get { return SomePropertyField; }
   set { SomePropertyField = value; }
}

to this:

private int someProperty;

public int SomeProperty {
   get { return someProperty; }
   set { someProperty = value; }
}

I was under the mad impression that changing private fields was ok. Not so when using binary serialization – the entire oject graph is serialized, including both public and private members.

If you’re going to use binary serialization, it’s probably wise to prevent any private fields from being serialized, like so:

[NonSerialized]
private int someProperty;

If this wasn’t considered though, it’s too late. It seems like using binary serialization is painting yourself into a corner. Once you’re saving and retrieving binary, it’s difficult to change the format, apart from adding fields or changing enumerations. Adding the [NonSerializable] attribute after you’ve started saving stuff away will break compatibility, so you’re pretty stuck. This seems to destroy the whole concept of using public properties with private backing fields – you’re supposed to be able to keep a consistent public interface whilst maintaining control over the internal implementation.

From my brief foray into the world of binary serialization, I’d say it’s best to thoroughly plan out exactly what you need to be serialized, or it will be too late to change anything. Either that or don’t bother and save a big headache.