Share via

Chapter 1: Authentication Patterns


Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 1: Authentication Patterns

patterns & practices Developer Center

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

Download Download this guide in PDF format
Community Web Service Security Community Workspace [Content link no longer available, original URL:]


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


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

Security Consideration Direct Brokered
What will the service require to prove the client's identity for authentication? Passwords, certificates, or something else? Direct authentication requires the presentation of credentials, which are typically a user name and password. The service uses these credentials to authenticate the request. Credentials are used to authenticate with the broker, which issues a security token. The security token is then used to authenticate with services.
Will the Web service be able to communicate with the authentication service that can validate the client's credentials for authentication? Because authentication is performed, direct access to the authentication service is required. Most implementations of brokered authentication do not require direct access to the authentication service.
Is there existing infrastructure to leverage? Direct authentication works with any infrastructure used to provide credential management. Brokered authentication requires an infrastructure in place that supports the type of security token that is used.
Is single sign on (SSO) support required? Requires authentication for every call. The process of authenticating the client on every call can have a negative impact on performance. Uses a security token that allows access to services after authentication has been performed. This same token could be used to access all services within an organization.
Will your application need to make multiple calls to the same service? In other words, should a security session be established? It is possible to cache the user name and password; however, that is not a recommended procedure. Security tokens can be used to establish a security session. Most tokens have a short lifetime and can safely be cached for multiple calls.
Is Windows impersonation or delegation required? If a user name and password are sent with the message, it is possible to impersonate the client. This works only if the client has a Windows account. The Kerberos protocol provides the ability to implement delegation.

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

Security Consideration X.509 KerberosToken Custom (STS)
Existing infrastructure Requires support for a Public Key Infrastructure (PKI), which can be expensive to set up and maintain. In cases where a limited number of certificates are needed, an external certificate authority (CA) can be used. Requires an identity provider that supports the Kerberos protocol, such as Active Directory. Requires an STS implementation that issues and manages security tokens.
The client and the service reside within the same organizational boundary X.509 certificates can be used across organizational boundaries. Management of certificates can become difficult with a large number of partners. The Kerberos protocol is used to authenticate clients within a domain. Cross-domain trusts can be established but are typically limited within an organization. A custom STS can provide authentication across organizational boundaries if both parties can standardize on the verification and processing of the token.
Support for Windows impersonation or delegation Can be used for impersonation when a certificate is mapped to a client within Active Directory. Supports both impersonation and delegation. Not supported.
Support for security sessions Most X.509 implementations, such as SSL, exchange a symmetric session key that is used for encryption. Service tickets are session-based tokens that can be used for confidentiality and integrity. Custom security tokens can be used for session based operations.
Interoperability with other platforms or technologies Based on industry standards and supported on many platforms. Often used for interoperability with Java. Based on industry standards, with availability on most major platforms; however, adoption is probably not as extensive as X.509. Based on the implementation of the STS.
Support for message protection Can be used to provide confidentiality and data origin authentication at the message layer and transport layer. Supports confidentiality and data origin authentication at the message layer and supports transport layer when used with IPSec. Supports confidentiality and data origin authentication at the message layer only.
Your application has a requirement to support non-repudiation and auditing Signatures created using X.509 certificates can be mapped to a particular participant in a conversation—assuming both participants have unique certificates. The identity of a particular client can be mapped to a certificate. Kerberos tokens can be used for impersonation and delegation, which makes them the ideal choice for auditing. Based on the implementation of the STS.

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 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 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 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":

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:

The design patterns are the following:

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.

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.