An Overview of Authentication Mechanisms on Windows

Background

With the emergence of Web 2.0, identity management is becoming a core focus. Security in online transactions is gaining attention from all technology vendors including Microsoft. Microsoft's recent release of .NET Framework 3.0 includes Windows CardSpace which provides a solid foundation for identity management of future. Also, the recent announcement from Microsoft to tie-up with OpenID, takes the CardSpace initiative to the next level. The current article gives an overview of various authentication mechanisms on Microsoft Windows platform.

Introduction

A digital identity is a set of characteristics associated with an individual or a device which allows us to address it distinctly from the rest of the world.

Before granting access to a valuable resource, a digital identity is checked to confirm the source of the request. This mechanism is termed as authentication.

Various popular authentication mechanisms are:

1. User name and password
2. Digital certificates
3. Biometrics – fingerprints, Iris/retina scan
4. Dynamic biometrics – signature, voice recognition

Authentication in Windows OS

Microsoft Windows Server 2003 has adopted Kerberos 5 as the default protocol for network authentication. Active Directory is merely the directory that holds all the information. Kerberos protocol implementation is used to protect it and make it function.

Microsoft Windows Server 2000 and beyond use the following as default authentication mechanism:

All the authentication protocols are exposed via SSPI (Security Support Provider Interface).

Windows authentication process using Kerberos KDC (Key Distribution Center) is shown below.

Authentication in .NET Applications

The .NET Framework has a model for managing user or automated agent based on the notion of an Identity. The identity object encapsulates information about the user or entity being validated.

Basic identity objects contain a name and an authentication type. The name can either be a user's name or the name of a Windows account, while the authentication type can be either a supported logon protocol, such as Kerberos V5, or a custom value.

namespace System.Security.Principal
{
    public interface IIdentity
    {
        bool IsAuthenticated { get; }
        string AuthenticationType { get; }
        string Name { get; }
    }
}

IIdentity interface shown above abstracts the authentication part of security context.

The .NET Framework defines a GenericIdentity object that can be used for most custom logon scenarios and a more specialized WindowsIdentity object that can be used when the application relies on Windows authentication. Additionally, own identity class can be defined that encapsulates custom user information.

Web Application Authentication

ASP.NET implements authentication via authentication providers. Providers are basically Classes that contain Public Static methods to help in authenticating requests from Clients.

An ASP.NET application can be configured to use one of the following Authentication Providers:

1. Windows Authentication

The WindowsAuthenticationModule provider relies on IIS to provide authenticated users. The provider module constructs a Windows Identity object. The default implementation constructs a WindowsPrincipal object and attaches it to the application context. One of the major advantages of Windows Authentication is to allow implementation of an impersonation scheme.

2. Forms Authentication

Forms authentication is recommended if the application needs to collect its own user credentials at logon time through HTML forms. All the unauthorized requests are redirected to the logon page using HTTP client-side redirection. Forms authentication provider may implement custom logic for validating username and password against identity store. If the application authenticates the request, the system issues a ticket that contains a key for reestablishing the identity for subsequent requests.

3. Passport Authentication

Passport authentication is Microsoft's centralized authentication service that offers a single logon and core profile services for member sites. Passport uses the Triple DES encryption scheme. When member sites register with Passport, they are granted a site-specific key. The Passport logon server uses this to encrypt and decrypt the query strings passed between sites. Authentication ticket is preserved by client in a cookie and is used for all future requests to the application till the cookie expires.

Web Services Authentication

Authentication of Web Services can be classified into two models as follows:

1. Direct Authentication

In direct authentication model, the client and the service establish a direct trust. Client application sends the credentials directly to the service along with the service request. Service maintains the catalog of the authorized clients and authentication mechanism is built into the service components. This model can be considered similar to the Forms authentication for web applications as both mechanisms do not require any intermediary to build the trust.

2. Brokered Authentication

Brokered authentication has an intermediary called as 'broker' to perform authentication when client and service do not share trust relationship. Credentials are used to authenticate with the broker, which issues a security token. The security token is then used to authenticate with services.

WSE (Web Services Enhancement) provides 3 main security tokens which support brokered authentication.

I. X.509

This requires support for a PKI (Public Key Infrastructure). In cases where a limited number of certificates are needed, an external CA (Certificate Authority) can be used. Most X.509 implementations, such as SSL, exchange a symmetric session key that is used for encryption.

II. KerberosToken

This requires an identity provider that supports the Kerberos protocol, such as Active Directory. Service tickets are session-based tokens that can be used for confidentiality and integrity.

III. STS (Security Token Service)

This requires an STS implementation that issues and manages security tokens. Custom security tokens can be used for session based operations.

CardSpace Authentication

Windows CardSpace is a technology designed to help eliminate the need for usernames and passwords. Instead, it will provide Windows users with digital identities in the form of Cards that users can access in a secure and familiar manner.

CardSpace provides an identity selector and a self-issued identity provider, both of which run on a client machine. CardSpace is a new way of doing strong authentication across trust boundaries. Internet Explorer 7 uses Windows CardSpace, if installed.

Windows CardSpace uses the following interoperable protocols - WS-Security, WS-SecurityPolicy, WS-Trust and WS-MetadataExchange.

Identity Provider provides the card (.crd file) which contains the metadata information. This card is used to obtain the security token from the Identity provider for sending the claim to the relying party.

OpenID Authentication

OpenID uses XRI (eXtensible Resource Identifier) to verify the digital identity. CardSpace can play a role to supplement the OpenID authentication process by establishing a relationship between client and OP using WS-Trust and WS-MetadataExchange. This may help eliminate steps 4 and 5 from the overall authentication process. Also, Card can additionally carry the XRI along with OP token.

Conclusion

SSO (Single sign-on) is a form of software authentication that enables a user to authenticate once with one software system and in turn gain access to multiple software systems. Windows OS authentication being a primary authentication, it is ideal to base the SSO on the same to gain access to all the applications accessed in that Windows session without a need for (re-)entering the credentials. Internet has opened the doors for a very large number of applications accessible to the users typically in B2C scenario with each application requiring user to undergo its own registration and authentication process. Along with the SSO, a demand for secure and reliable as well as generic mechanism to establish a trust persists. With the evolution of technology and the open standards being widely accepted, the vision of 'Trustworthy SSO' across the web will not be too far from getting into reality.

References

1. Web Service Security - guide from Microsoft Patterns & Practices
2. OpenID Authentication 2.0 - Draft 11
3. Microsoft Windows Server 2003 Authentication: Under the hood by Richard Ward

License

This article has no explicit license attached to it, but may contain usage terms in the article text or the download files themselves. If in doubt, please contact the author via the discussion board below.

A list of licenses authors might use can be found here.