Chapter 1: Authentication Patterns

Chapter 1: Authentication Patterns

Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0

Microsoft Corporation

patterns & practices Developer Center
Web Service Security: Home
December 2005

Contents

Introduction
Important Concepts
Direct Authentication vs. Brokered Authentication
Authorization Methods
More Information

Introduction

As computer systems have increased in complexity, the challenge of authenticating users has also increased. As a result, there are a variety of models for authentication. For example, clients accessing a Web application may directly provide credentials, such as a user name and password for authentication. However, a third-party broker, such as a Kerberos domain controller, may be used to provide a security token for authentication. These two models are referred to as direct authentication and brokered authentication.

This chapter provides architectural patterns for direct authentication and brokered authentication, along with three brokered authentication design patterns that illustrate authentication using the Kerberos protocol, X.509, and a Security Token Service (STS). Figure 1 is a pattern map that illustrates how these patterns are related to one another.

Figure 1. Authentication patterns

Authentication is considered to be a primary security feature because mechanisms used for authentication often influence mechanisms used for enabling other security features, such as data confidentiality and data origin authentication. For example, consider a case where the Kerberos protocol is used for message layer authentication. After a Kerberos session is set up between the client and service, it is possible to derive encryption keys from the Kerberos session key to encrypt application messages. From an architecture perspective, this is an advantage because you do not have to consider another security mechanism and infrastructure just to satisfy the data confidentiality needs.

**Note   **This introduction also discusses authorization, a concept that is intrinsically linked to authentication. However, the subject of authorization is already extensively documented, so the content in this chapter is intended to be only an introduction to the subject. An update to this guide is scheduled to coincide with the release of the Windows Communication Foundation (WCF). The update will incorporate patterns associated with distributed authorization.

Important Concepts

To fully understand authentication and authorization, it is important to understand the following concepts:

• Authentication. Authentication is the process of identifying an individual using the credentials of that individual. For example; with the driver's license example, a bank teller may be required to authenticate who you are by examining your driver's license. Authentication typically occurs immediately after identification.
• Authorization. Authorization is the process of determining whether an authenticated client is allowed to access a resource or perform a task within a security domain. Authorization uses information about a client's identity and/or roles to determine the resources or tasks that a client can perform.
• Credentials. A set of claims used to prove the identity of a client. They contain an identifier for the client and a proof of the client's identity such as a password. They may also include information, such as a signature, to indicate that the issuer certifies the claims in the credential. A driver's license is an example of a credential in the real world. It contains data representing your identity and capabilities. It contains proof of possession in the form of your picture ID. It is issued by a trusted authority, such as your state department of licensing.
• Identification. Represents the use of an identifier that allows a system to recognize a particular subject and distinguish it from other users of the system.

Direct Authentication vs. Brokered Authentication

Both the Direct Authentication pattern and the Brokered Authentication pattern focus on the relationships that exist between a client and service participating in a Web service interaction. When both the client and service participate in a trust relationship that allows them to exchange and validate credentials including passwords, direct authentication can be performed, as shown in Figure 2.

Figure 2. Direct authentication when a client and service share a trust relationship

An example of when this might be appropriate is where client applications and the service are able to establish credentials prior to the client using the Web service's capabilities. For example, before accessing a company's stock tracking service, you first establish an ID and password with the provider that you can then use to call its Web service. Another example is where the Web service wraps a legacy application that incorporates a custom authentication implementation that requires a user name and password to authenticate the client using information from a database.

In a situation where the client and service do not share a direct trust relationship, you can use a broker to perform authentication, as shown in Figure 3.

Figure 3. Using a broker to perform authentication when client and service do not share trust relationship

The broker authenticates the client and then issues a security token that the service can use to authenticate the client. The security token is always verified, but typically, the service does not need to interact with the broker to perform the verification. This is because the token itself can contain proof of a relationship with the broker, which can be used by the service to verify the token.

In addition to the different relationships, there are other security considerations that may support one approach over the other. For example, message protection requirements may dictate the use of brokered authentication when direct authentication is available. The support for different security infrastructures also has an influence on the authentication method used. Table 1 represents a decision matrix that lists security considerations related to authentication and how each one is supported by direct authentication methods or brokered authentication methods.

Table 1. Authentication Decision Matrix

One thing to keep in mind is that these are just some of the security considerations that need to be examined. Other considerations related to security policies and threats identified during a security analysis should also be examined.

Brokered Authentication Options

The three main security tokens provided by WSE support brokered authentication. These tokens are X.509, KerberosToken, and a custom security token issued by a Security Token Service (STS).

Table 2 represents a decision matrix that lists security considerations related to authentication and how each one is supported by different security tokens.

Table 2. Security Token Decision Matrix

Keep in mind that these are some of the main security considerations. Other considerations related to security policies or a threat analysis will also influence your choice.

Authorization Methods

The .NET Framework currently supports two different methods for performing authorization, role-based authorization and resource-based authorization.

Role-Based Authorization

Role-based authorization is used to associate clients and groups with the permissions that they need to perform particular functions or access resources. When a user or group is added to a role, the user or group automatically inherits the various security permissions. Role-based authorization can be declarative or imperative.

**Note   **Authorization can be based on any attribute of a security principal. However, the majority of non-resource–based authorization methods use roles for authorization purposes.

Declarative

Declarative role-based authorization can be added to application code at design time. Required access for a particular method or class is declared as an attribute in code. Attribute metadata is discoverable using reflection; this makes it easier to track at design time the security principals that are allowed to access the method. The following code is an example of declarative security in .NET that uses an attribute on a method to require that the current principal on the thread belongs to the Administrators group.

using System.Security.Permissions;
...
 [PrincipalPermissionAttribute(SecurityAction.Demand, Role = "Administrators")]
 public static void PrivateInfo()
 {   
    //Print secret data.
    Console.WriteLine("\n\nYou have access to the private data!");
 }

Imperative

Imperative role-based authorization is written into the application code to make authorization decisions at run time. Imperative security is useful when the resource to be accessed or action to be performed is not known until run time or when finer-grained access control beyond the level of a code method is required. The following code is an example of imperative security in .NET that checks role membership at run time.

using System.Security.Principal;
using System.Threading;  
...

WindowsPrincipal MyPrincipal = (Thread.CurrentPrincipal as WindowsPrincipal);
if (MyPrincipal.IsInRole("Administrator")) 
{
    // Permit access to some code.
}

Unlike declarative security, role checking when using imperative security does not have to be performed on the application thread's current principal. A reference to a security principal can be obtained at run time to check roles for a user that may not be currently logged into the application.

Resource-based Authorization

Resource-based authorization is performed declaratively on a resource, depending on the type of the resource and the mechanism used to perform authorization. Resource-based authorization can be based on access control lists (ACLs) or URLs.

Access Control List (ACL)

Individual resources, such as files, are secured using Windows ACLs that specify the type of operation a particular security principal or group to which a security principal belongs can perform on the object. The application impersonates the caller prior to accessing resources; because of this, the operating system can perform standard access checks. All resource access is performed using the original caller's security context.

URL Authorization

URLs are declared with permissions for the URL to define who is authorized to access the URL in question. Typically, this approach is linked to an authorization store such as Authorization Manager (AzMan), which defines access entitlements for a specific URL and maps those entitlements to user logons.

Policy

Policy provides a means to declaratively enforce security on SOAP request and response messages through policy assertions. The policy implementations in WSE are based on the WS-SecurityPolicy and WS-PolicyAssertions specifications. Policies for an application are stored in a cache file that is referenced in the WSE configuration section of the application's configuration file. A policy consists of one or more assertions that express a security requirement, capability, or preference for an inbound or outbound SOAP message. Required claims on a security token attached to a message can be used to authorize access to a Web service or a specific operation on a Web service.

WSE policy is used to provide confidentiality, integrity, and data origin authentication, as shown in the following patterns in Chapter 3, "Implementing Transport and Message Layer Security":

• Implementing Direct Authentication with UsernameToken in WSE 3.0
• Implementing Message Layer Security with X.509 Certificates in WSE 3.0
• Implementing Message Layer Security with Kerberos in WSE 3.0

Authorization in Windows Communication Foundation

Windows Communication Foundation (WCF) will integrate seamlessly with the role-based security features that are built into the .NET Framework. WCF will communicate the sender's credentials to the receiving code using the usual Thread.CurrentPrincipal property. Because of this, you can perform authorization either declaratively using PrincipalPermissionAttribute or imperatively using IPrincipal.IsInRole.

WCF will also incorporate a sophisticated claims-based authorization infrastructure exposed through an object named "authorization context." This allows more complex authorization decisions to be made based on additional claims provided in tokens within an incoming message.

Guidance for authorization using WCF will be incorporated in an updated version of this guidance that will also incorporate implementations using WCF.

For a complete description of authorization on the .NET Framework, see Authentication and Authorization on MSDN.

The remainder of this chapter contains the architecture and design patterns related to authentication. The architecture patterns are the following:

• Direct Authentication
• Brokered Authentication

The design patterns are the following:

• Brokered Authentication: Kerberos
• Brokered Authentication: X.509 PKI
• Brokered Authentication: Security Token Service (STS)

More Information

For more information about authorization on the .NET Framework, see "Authentication and Authorization" in Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication on MSDN.