Export (0) Print
Expand All

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

DownloadDownload this guide in PDF format
CommunityWeb Service Security Community Workspace [Content link no longer available, original URL:http://go.microsoft.com/fwlink/?LinkId=57044]

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

Security ConsiderationImpersonation and Constrained DelegationTrusted Subsystem
Client is authenticated using Windows authentication with Kerberos.Both impersonation and constrained delegation can be used with a Windows account; this allows resources to be accessed using the client's identity.Can be implemented using a trusted business identity or the service account to authenticate with the resource.
Client is authenticated using a non-Windows authentication protocol.Impersonation and constrained delegation can be implemented using protocol transition; however, the service account must have trusted computing base (TCB) privileges.Can be implemented using a trusted business identity or the service account to authenticate with the resource.
A service is accessing local resources and the resources are secured using ACLs based on the identity of individual clients.Impersonation is required to access local resources using the client's identity.Not applicable.
A service is accessing remote resources and security policy prohibits clients from directly accessing the resources. Not applicable.Can be implemented using a trusted business identity or the service account to authenticate with the resource.
The client's identity must be passed to resources so they can perform auditing or data entitlement.When using impersonation or constrained delegation, the client's identity is passed using operating system capabilities to downstream resources.The client's identity would need to be passed as part of the message header or body.
Remote resources cannot validate client credentials because the originating client does have an account in Active Directory.Not applicable.Can be implemented using a trusted business identity or the service account to authenticate with the resource.
The application or Web service must use resource sharing optimization techniques.Not applicable. Most resource sharing techniques require the use of a common identity.Using a common identity with trusted subsystem supports optimization techniques.
A client is authenticated by sending the user name and password of the client in the Web service message.The user name and password can be used to authenticate the client with Windows authentication to support both impersonation and constrained delegation.Can be implemented using a trusted business identity or the service account to authenticate with the resource.
The client's identity must be passed to resources.When using impersonation or constrained delegation, the client's identity is passed using operating system capabilities to downstream resources.The client's identity would need to be passed as part of the message header or body.
Remote resources need to access another resource using the original client's credentials.Constrained delegation must be used to flow the client's credentials to a remote resource.Not applicable.
Resources need to perform actions based on the identity of the client.If only the identity is required, impersonation can be used; otherwise, constrained delegation must be used.If only the identity is required, it can be passed as part of the message header or body; otherwise, this is not an option.

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

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.

Show:
© 2014 Microsoft