Chapter 4: Resource Access Patterns

Chapter 4: Resource Access 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
Resource Access Methods

Introduction

Web services represent a programmable interface that applications often use to access resources, such as the local file system, databases, or other Web services. Distributed applications can consist of multiple interacting Web services, so you have to consider the needs and constraints of the entire application instead of focusing on a single point of interaction. Authentication, authorization, and auditing, along with other environmental and operational requirements (such as scalability requirements at each resource access interface), should combine to influence the security solution that you use to help secure access to resources.

Each of the following resource access issues involves questions you should consider:

• Authentication credentials:
  • Is the client authenticated and what protocol was used?
  • Does access to the resource need to be protected from direct access by authenticated clients?
• Auditing requirements for resources:
  • Is it sufficient to just pass the client's identity to a resource or should the client's credentials be used to access the resource?"
• Location of the resource:
  • Is the resource located on the same computer, another computer in the same security domain, or a computer located in a different security domain?
  • Are there multiple hops involved that require the client's credentials at each interface?
• Scalability requirements for the Web service:
  • Does the Web service need to take advantage of resource sharing techniques such as connection pooling?

Sorting through these factors to make a decision can sometimes be a difficult task, particularly because many of them have dependencies on each other.

This chapter includes a design pattern that discusses trusted subsystem, where a trusted identity is used to access resources on behalf of a client. It also includes a technical supplement that discusses protocol transition and constrained delegation.

Important Concepts

There are some important concepts you should understand before looking at the different resource access methods. These include:

• Credentials. These are 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.
• Identity. This term is used throughout the discussion of resource access to represent an account associated with Active Directory.
• Service account. This is the Windows account that the operating system process uses when it hosts a service. Web services are usually hosted in a process managed by an application server, such as Internet Information Services (IIS) that performs operations using the identity of a service account.
• Security context. This is the information about an identity that allows the application of policy and rights assignment. In Windows, this translates into security roles and identifiers used for authorization.
• Security tokens. These are sets 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. Most security tokens also contain additional information that is specific to the broker that issued the token.

Resource Access Methods

The following methods can be used to access resources:

• Impersonation. Impersonation is the act of assuming a different identity on a temporary basis so that a different security context or set of credentials can be used to access a resource. When accessing local resources, such as a file in the local file system, you need only the security context. However, when accessing resources that require authentication, such as a Web service or database, credentials are required.

• Delegation. Delegation is not the same as impersonation; however, it requires impersonation to work. This is a process where the service account is allowed to access a remote resource on behalf of another Windows account, which is typically the client accessing a service. Impersonation is required so that the service account can access the credentials of the account being delegated and send those credentials to the remote resource. For delegation to work, the account being delegated must also be configured to allow delegation, which is the default setting in Active Directory.

  Windows supports two types of delegation:

  • Constrained. This type of delegation is supported only on Windows Server 2003. This is an implementation where a service account can access only remote resources that it has been configured to access.

  • Unconstrained. This type of delegation is supported on Windows 2000 and Windows Server 2003. This is an implementation where a service account can use delegation to access any remote resource.

    **Note   **The use of unconstrained delegation is not recommended.

• Protocol transition. Protocol transition is a process where the service account transitions an identity that was authenticated using a non-Windows protocol into a Windows security context. This works only on Windows Server 2003 and the transitioned identity must have a valid Active Directory account. This can also be used to implement a trusted subsystem by using the service account's identity instead of the client's identity to access resources.

• Trusted subsystem. This is a process where a trusted business identity is used to access a resource on behalf of the client. The identity could belong to the service account or it could be the identity of an application account created specifically for access to remote resources. There are many different reasons for using a trusted subsystem, but the most common reason is to take advantage of resource sharing techniques, such as connection pooling associated with database connections.

For a detailed explanation of these resource access methods, see the "Trusted Subsystem" pattern and the "Protocol Transition and Constrained Delegation Technical Supplement" in this chapter.

There are many different protocols and techniques that can be used to authenticate with a Web service. However, from the client's standpoint, there are two distinct methods. These two methods are presenting credentials, such as the user name and password, or presenting a security token issued from a trusted source. Each of these methods has an impact on the ability to use impersonation, constrained delegation, or trusted subsystem.

There are also other security considerations that influence a decision to use impersonation, constrained delegation, or trusted subsystem, such as auditing, resource location, and scalability requirements. Impersonation is commonly used by itself; however, constrained delegation requires the use of impersonation. Typically, trusted subsystem is not used with impersonation or constrained delegation.

Table 1 shows how impersonation, constrained delegation, and trusted subsystem can be used based on different security considerations.

Table 1. Resource Access Decision Matrix

The remainder of this chapter focuses on the following design pattern and technical supplement:

• Trusted Subsystem
• Protocol Transition and Constrained Delegation Technical Supplement