WCF and Multiple Security Models - wcf

Question

We're working on a WCF service to house our core API.
We're working on 2 clients to use this API one of which is a WPF desktop app that will most likely authenticate against active directory and reside on the same domain as the API. The other is an ASP.Net web application that will most likely use ASP.Net Membership for security and still reside on the same domain as the WCF service. The plan is for the WCF service to use NetTcp and be hosted inside a Windows Service.
Where possible I would like the WCF service to run as the calling user, I guess this should be fairly straight forward for the desktop app where the user is a domain user. For the web app I guess I will need to create a user for service calls to run under.
Is it possible to get this kind of double approach to security to run over a single WCF service or will I need to make 2 services each with it's own security model?
Also if anyone has any thoughts on best practises/patterns for achieving this that would be great.
Thanks

Answer 1

I've solved the same problem in the following way:
I created two net.tcp binding for every usage.
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="" />
<message clientCredentialType="UserName" />
</security>
</binding>
<binding name="WindowsBinding" >
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="Windows" />
</security>
</binding>
Next, I added two endpoints for every services
<service name="SimplePluginService" behaviorConfiguration="CommonBehavior">
<endpoint binding="netTcpBinding" bindingConfiguration="UserNameBinding" name="SimplePluginServiceUserName" contract="ISimplePluginService">
<identity>
<dns value="WCfServer" />
</identity>
</endpoint>
<endpoint binding="netTcpBinding" bindingConfiguration="WindowsBinding" name="SimplePluginServiceWindows" contract="ISimplePluginService">
<identity>
<dns value="WCfServer" />
</identity>
</endpoint>
</service>
Next, I choosed the appropriate endpoint when I create ChannelFactory (ConnectionManager - class, which contains information about user's creditionals).
private readonly Dictionary<Type, Object> channelFactoryDictionary = new Dictionary<Type, Object>();
private ChannelFactory<T> GetChannelFactory<T>() where T : class
{
if (channelFactoryDictionary.Keys.Contains(typeof(T)))
{
return channelFactoryDictionary[typeof(T)] as ChannelFactory<T>;
}
else
{
string endpointName=typeof(T).ToString();
if (ConnectionManager.IsWindowsAuth) endpointName+="Windows";
else endpointName+="UserName";
ChannelFactory<T> channelFactory = new ChannelFactory<T>(endpointName);
if (!ConnectionManager.IsWindowsAuth){
channelFactory.Credentials.UserName.UserName = ConnectionManager.Password;
channelFactory.Credentials.UserName.Password = ConnectionManager.Password;
}
channelFactoryDictionary.Add(typeof(T), channelFactory);
return channelFactory;
}
}

Answer 2

You're conflating a few different issues here. First, I'd claim that your hosting (Windows service) and transport (here given as netTcp) are mostly unrelated to your choice of authentication/authorization, unless you want to rely on ASP.NET membership, in which case you'll want IIS to host your service.
Impersonation is certainly a decent approach to access control on a desktop or in a carefully-curated LDAP environment; I've tended to find, though, that as my services grow their business requirements deviate from policies that are (or can be) represented in Active Directory. Once that happens, your service begins to require more support to keep Windows impersonation working as you'd wish. This often means dealing with WCF extensibility.
Speaking from years of experience, working with WCF security extension points is roughly as painful as a barely-anesthetized root canal. That said, it's quite powerful once the painful work is completed.
I've found that, generally, less pain is better. I can get the security benefits of impersonation by explicitly modeling access restrictions in my code, e.g. using claims-based security and CAS attributes. Taking that approach, a custom IPrincipal-implementing class can obviate the need for impersonation and, with it, much obscure WCF plumbing.
It isn't quite the answer you were looking for, but these are my two cents' worth nevertheless.