Authenticating Web Application Users

  • Article

Applies To: Windows Server 2003 with SP1

This section discusses certain characteristics of Web applications emphasize some of the key requirements for Web application authentication protocols.

Web applications can use a variety of protocols to authenticate users. For example, Web applications can use the authentication protocols that are supported by HTTP or Web applications may depend on custom authentication mechanisms that are used with the existing Web server infrastructure (such as form and cookie-based authentication). However, not all of the authentication mechanisms have the same security attributes; some of the authentication mechanisms have stronger security properties than others. For example, Kerberos supports mutual authentication, while cookie-based authentication schemes do not.

Designers of scalable and reliable Web applications often follow design principles that advocate a tiered-application approach. For example, a Web-based line of business (LOB) application may consist of presentation, business logic, and data tiers. Frequently, the tiered approach introduces the delegation requirement that should be supported by the underlying network and operating system security infrastructure. Delegation allows a service to act on another security principles behalf to gain access to resources throughout the network. N-tiered applications may use delegation to satisfy various application requirements (for example, auditing or making authorization decisions in the original users context).

A more specific example is a Web-based bank account withdrawal application with a business component that resides in the business tier. The application verifies whether the Web user has permissions to withdraw the requested amount of $1,000 US from a given bank account. That business component needs to know the identity of the application user to allow the transaction. In the ideal scenario, the authentication protocol would propagate the original user context throughout the end-to-end application flow, even though the flow may cross physical computer boundaries. Application components that are in the respective tiers can then retrieve the original user context and perform authorization accordingly.

At the time that this document was published, Kerberos was the only widely-adopted authentication protocol that was capable of performing delegation. When n-tier applications are not using an authentication protocol that enables delegation, they typically design in user identifiers that are passed through application message bodies. Without further security measures to protect the application message while it is in transit, this approach is susceptible to message modification which could result in the identifier being modified and, subsequently, result in a security breach (such as identity spoofing). In addition to delegation, Kerberos also offers the benefits of mutually-authenticating communicating parties, as well as protecting the application message when it is in transit by using data encryption.

Kerberos is not the default authentication protocol that is used by Web applications because Kerberos uses port 88, a port that is typically blocked by corporate firewalls. Because of this port restriction, it is difficult to successfully deploy Kerberos in an Internet environment.

Note that:

  • Web applications require firewall-friendly authentication at the authentication tiers

  • Delegation is a frequently desired security feature for n-tier Web applications

Ideally, Web applications would use an authentication protocol with all of the desired security attributes of Kerberos, while offering ease of deployment over the Internet. To work around some of these limitations, consider the following engineering approaches:

  • Fix the existing authentication protocols (like Basic, Digest, and SSL) so that they support delegation and mutual authentication. This is not a viable option because of the breadth of design and engineering work that is required for every authentication protocol that is supported.

  • Fix the Kerberos protocol so that it can traverse corporate firewalls. This approach (or at least its functional equivalent) is not available.

  • Do enough engineering work so that the Kerberos protocol becomes the default authentication protocol that is used behind corporate firewalls, independent of the protocol that is used at the Web server authentication tier to authenticate the Internet user. This approach has been adopted in the Windows Server 2003 family to help address delegation issues that Web applications encounter. The new Kerberos protocol extensions provide significant security benefits to Web applications without modifying the functions of Web authentication protocols that are already deployed.