The context: I have a system that consists of a mix of ASP.NET web applications, ASMX web services, WCF services and a rich client. Servers run Windows Server 2008 R2 and applications are written using .NET 4.0. The web applications and the rich client are used by users in different organizations and the communication protocol is https over the Internet. The system uses a dedicated Active Directory domain, and users log in to this domain using username and password to get access to the web applications and the web services that are consumed by the rich client. The client sends credentials using something similar to this:
var networkCredential = new NetworkCredential(userName, password, domain);
var credentialCache = new CredentialCache();
credentialCache.Add(new Uri(uri), “NTLM”, networkCredential);
webServiceProxy.Credentials = credentialCache;
Authorization is a mixture. In one web.config, we have for example
<authentication mode="Windows" />
<authorization>
<allow roles="gALLUsers" />
<deny users="*" />
</authorization>
Some services also have code that uses Authorization Manager (AzMan) to check if the user (Thread.CurrentPrincipal.Identity.Name) is permitted to perform certain tasks.
There is also code that uses AD queries to look up the user’s organization etc.
The challenge: We want to strengthen the security by using personal client certificate (smart card) authentication. These certificates are issued by a third party. I am not sure which route to take. To minimize code changes we might map client certificates by using active directory mapping (http://technet.microsoft.com/en-us/library/cc770480(v=ws.10).aspx), but that requires us to get access to all certificates to do the mapping. Perhaps we could write a web application to automate this process.
Another way could perhaps be to change the web applications and services to use part of the subject in the certificate as user name (there is a unique field we can use), i.e. Request.ClientCertificate.Subject instead of Thread.CurrentPrincipal.Identity.Name. About the declarative authorization part (<allow roles=… />), could that still work if we implement a custom role provider? I mean, authentication is already taken care of by SSL, but we must check the incoming authenticated subject against registered users (still in AD).
Any thoughts are appreciated.