If your organization is anything like mine, you probably have a number of disparate applications, each with a login page for user authentication. If your company's authentication services change, such as with a migration to Active Directory, changing each and every login screen can be a tedious task. Even with a stable enterprise security scheme you may need your own custom authentication services.
One logical solution is to add an authentication proxy service between your authentication servers and your client programs (see Figure 1). With the advent of Web services, implementing such a proxy has become a relatively straightforward task. In this article, I will demonstrate how to create a central authentication Web service for your intranet applications using Visual Studio.Net. Both thick-client applications and Web servers are treated as authentication clients for this service. Thick clients access the authentication service directly, and Web servers act as a proxy themselves for browser applications. Clients need not be implemented with .Net—any environment with Web service plumbing such as Java or C++ will suffice.
| |
 |
Figure 1. Authentication Web Service Architecture | Add an authentication proxy service between your authentication servers and your client programs.
|
You can download the source code from this article and use it as a general-purpose mechanism to enable users to identify themselves as part of your company's NT Domain or Active Directory store. You also can easily plug in your existing custom authentication code if needed.
The sample code relies on a few useful techniques:
Custom SOAP headers for transmitting username/password pairs
XML encryption for SOAP headers
.Net cryptographic classes, such as DES and TripleDES
.Net classes for Active Directory or NTLM authentication
The authentication Web service uses XML encryption to pass username and password information from a client to the service. (I provide a short introduction to XML encryption in a later section.) Despite the encryption, you must use HTTPS to communicate with the service if your users have access from the open Internet. Otherwise, you face potential man-in-the-middle or replay attacks. Without a secure transport like HTTPS, an intranet scenario behind a firewall would be a more appropriate use for the service.
Introduction 
Implement Custom SOAP Headers 
XML Encryption and the .NET Cryptography Classes 
Authenticate Windows Users 
