Web Service Security Patterns

This page uses frames, but your browser doesn't support them.


Web Service Security Patterns

Community Technology Preview: June 2005

Welcome to the Community Technology Preview (CTP) of Web Service Security Patterns! This is an early and scope-limited release of a Microsoft patterns & practices deliverable planned for release later in 2005. This CTP release provides the community with early insight into this deliverable, and allows you to provide feedback that the patterns & practices team will use to improve the full release.

This release is provided in two formats to simplify the review process. These are a collection of Microsoft Word documents and an HTML Help (.chm) file. While both formats contain the same content, the HTML Help version includes additional hyperlinks and an integrated Table of Contents to facilitate simple reading and navigation. The Word format can be easily printed and allows for reviewing through inline editing and comments.

There are several ways that you can provide feedback on this CTP release:

1. Post comments to the message boards on the Service Orientation Patterns Community at http://practices.gotdotnet.com/projects/sopatterns

2. Provide edits and comments in the Word version of the documents, and upload your edits to the Service Orientation Community.

3. E-mail comments or annotated Word documents to passo@microsoft.com

The final deliverable is expected to include updated versions of all content in the CTP, as well as additional content focusing on implementation using WSE 3.0 and .NET Framework 2.0. Furthermore, we plan to provide guidance on new topics such as SAML and Message Reply Protection. If there are any specific topics which you believe should be covered in the final release, please provide this feedback via the community site or e-mail.

Thank you for taking the time to review this deliverable and for helping to improve Microsoft patterns & practices!

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Documentation License

This page uses frames, but your browser doesn't support them.


Documentation License

Microsoft Corporation Technical Documentation License Agreement (Standard)
READ THIS! THIS IS A LEGAL AGREEMENT BETWEEN MICROSOFT CORPORATION ("MICROSOFT") AND THE RECIPIENT OF THESE MATERIALS, WHETHER AN INDIVIDUAL OR AN ENTITY ("YOU"). IF YOU HAVE ACCESSED THIS AGREEMENT IN THE PROCESS OF DOWNLOADING MATERIALS ("MATERIALS") FROM A MICROSOFT WEB SITE, BY CLICKING "I ACCEPT", DOWNLOADING, USING OR PROVIDING FEEDBACK ON THE MATERIALS, YOU AGREE TO THESE TERMS. IF THIS AGREEMENT IS ATTACHED TO MATERIALS, BY ACCESSING, USING OR PROVIDING FEEDBACK ON THE ATTACHED MATERIALS, YOU AGREE TO THESE TERMS.

1. For good and valuable consideration, the receipt and sufficiency of which are acknowledged, You and Microsoft agree as follows:

(a) If You are an authorized representative of the corporation or other entity designated below ("Company"), and such Company has executed a Microsoft Corporation Non-Disclosure Agreement that is not limited to a specific subject matter or event ("Microsoft NDA"), You represent that You have authority to act on behalf of Company and agree that the Confidential Information, as defined in the Microsoft NDA, is subject to the terms and conditions of the Microsoft NDA and that Company will treat the Confidential Information accordingly;

(b) If You are an individual, and have executed a Microsoft NDA, You agree that the Confidential Information, as defined in the Microsoft NDA, is subject to the terms and conditions of the Microsoft NDA and that You will treat the Confidential Information accordingly; or

(c)If a Microsoft NDA has not been executed, You (if You are an individual), or Company (if You are an authorized representative of Company), as applicable, agrees: (a) to refrain from disclosing or distributing the Confidential Information to any third party for five (5) years from the date of disclosure of the Confidential Information by Microsoft to Company/You; (b) to refrain from reproducing or summarizing the Confidential Information; and (c) to take reasonable security precautions, at least as great as the precautions it takes to protect its own confidential information, but no less than reasonable care, to keep confidential the Confidential Information. You/Company, however, may disclose Confidential Information in accordance with a judicial or other governmental order, provided You/Company either (i) gives Microsoft reasonable notice prior to such disclosure and to allow Microsoft a reasonable opportunity to seek a protective order or equivalent, or (ii) obtains written assurance from the applicable judicial or governmental entity that it will afford the Confidential Information the highest level of protection afforded under applicable law or regulation. Confidential Information shall not include any information, however designated, that: (i) is or subsequently becomes publicly available without Your/Company’s breach of any obligation owed to Microsoft; (ii) became known to You/Company prior to Microsoft’s disclosure of such information to You/Company pursuant to the terms of this Agreement; (iii) became known to You/Company from a source other than Microsoft other than by the breach of an obligation of confidentiality owed to Microsoft; or (iv) is independently developed by You/Company. For purposes of this paragraph, "Confidential Information" means nonpublic information that Microsoft designates as being confidential or which, under the circumstances surrounding disclosure ought to be treated as confidential by Recipient. "Confidential Information" includes, without limitation, information in tangible or intangible form relating to and/or including released or unreleased Microsoft software or hardware products, the marketing or promotion of any Microsoft product, Microsoft's business policies or practices, and information received from others that Microsoft is obligated to treat as confidential.

2. You may review these Materials only (a) as a reference to assist You in planning and designing Your product, service or technology ("Product") to interface with a Microsoft Product as described in these Materials; and (b) to provide feedback on these Materials to Microsoft. All other rights are retained by Microsoft; this agreement does not give You rights under any Microsoft patents. You may not (i) duplicate any part of these Materials, (ii) remove this agreement or any notices from these Materials, or (iii) give any part of these Materials, or assign or otherwise provide Your rights under this agreement, to anyone else.

3. These Materials may contain preliminary information or inaccuracies, and may not correctly represent any associated Microsoft Product as commercially released. All Materials are provided entirely "AS IS." To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.

4. If You are an entity and (a) merge into another entity or (b) a controlling ownership interest in You changes, Your right to use these Materials automatically terminates and You must destroy them.

5. You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to these Materials. However, any Feedback you voluntarily provide may be used in Microsoft Products and related specifications or other documentation (collectively, "Microsoft Offerings") which in turn may be relied upon by other third parties to develop their own Products. Accordingly, if You do give Microsoft Feedback on any version of these Materials or the Microsoft Offerings to which they apply, You agree: (a) Microsoft may freely use, reproduce, license, distribute, and otherwise commercialize Your Feedback in any Microsoft Offering; (b) You also grant third parties, without charge, only those patent rights necessary to enable other Products to use or interface with any specific parts of a Microsoft Product that incorporate Your Feedback; and (c) You will not give Microsoft any Feedback (i) that You have reason to believe is subject to any patent, copyright or other intellectual property claim or right of any third party; or (ii) subject to license terms which seek to require any Microsoft Offering incorporating or derived from such Feedback, or other Microsoft intellectual property, to be licensed to or otherwise shared with any third party.

6. Microsoft has no obligation to maintain confidentiality of any Microsoft Offering, but otherwise the confidentiality of Your Feedback, including Your identity as the source of such Feedback, is governed by Your NDA.

7. This agreement is governed by the laws of the State of Washington. Any dispute involving it must be brought in the federal or state superior courts located in King County, Washington, and You waive any defenses allowing the dispute to be litigated elsewhere. If there is litigation, the losing party must pay the other party’s reasonable attorneys’ fees, costs and other expenses. If any part of this agreement is unenforceable, it will be considered modified to the extent necessary to make it enforceable, and the remainder shall continue in effect. This agreement is the entire agreement between You and Microsoft concerning these Materials; it may be changed only by a written document signed by both You and Microsoft.


Pattern Navigation and Scenarios

This page uses frames, but your browser doesn't support them.


Pattern Navigation and Scenarios

This topic guides you through the process of identifying appropriate patterns and solutions for securing Web services. There are many different factors to consider such as the deployment environment, security requirements, and security threats. The Patterns, Pattlets, Security Primers, and Threat Modeling topics will help you decide on a solution to securing your Web services. Instead of trying to duplicate this information, this document provides a high-level map to the patterns and pattlets along with scenarios that describe how these patterns were applied to real world solutions.

One of the challenges with providing this type of navigation is that the decision process for identifying a solution is based on factors related to the application and environment. The following list provides some examples of how the application and/or environment have an effect:

  • If you have a .NET Web service that needs to talk to a Java Web service your first concern will be interoperability.
  • If you have a Web service that needs to support a high volume of requests, performance will be a primary consideration.
  • Security policies may specify security standards, such as authentication, while leaving other security decisions up to the application team.
  • Privacy requirements may specify that non-repudiation must be implemented.

The goal of this document is to support these different viewpoints, while providing enough structure to give guidance regardless of where you start. In other words, if you are concerned with data confidentiality, and authentication standards are in place, you can jump right to the message protection patterns and see how they relate to various authentication options. The following outline describes the content of each section below:

  • Introduction. Provides an overview of the pattern maps used for pattern navigation.
  • Pattern Navigation. Discusses common decisions that you would need to consider when navigating through the various Web service security patterns. These decisions are organized into the following categories:
    • Direct vs. Brokered Authentication. Provides information about Direct versus Brokered authentication and includes a decision matrix that identifies the primary factors you should consider.
    • Brokered Authentication Options. Identifies common security tokens related to Brokered authentication and provides a decision matrix that examines how requirements and the environment influence the choice of token.
    • Message Protection. Identifies security features related to message protection and provides a decision matrix that examines how requirements map to message protection features.
    • Transport Layer vs. Message Layer Security. Discusses the differences between transport layer and message layer security and includes a decision matrix that examines factors you should consider.
  • Example Scenarios. The examples in this section represent common scenarios and solutions that were applied to those scenarios. Each scenario contains a "Solution Approach" and "Solution Description" section. The "Solution Approach" section describes factors that were considered. The "Solution Description" section identifies the design that was used for the solution. Each scenario also starts with a list of the patterns that are used in the design and implementation of the solution. The scenarios described in this section are the following:
    • Intranet. Describes the decision criteria used to choose Message Layer Kerberos for an internal banking solution and provides a high level description of the Kerberos design.
    • Internet. Describes the decision criteria used to choose a Security Token Service (STS) for a travel agency application that is accessible from the Internet. This section also describes how both Direct authentication and Brokered authentication are used to implement the solution.
    • B2B Intranet. Describes a B2B solution that uses Message Layer Kerberos within the organization and X.509 between businesses.

Finally, before using this navigation guide you should have an understanding of different security concepts such as message layer versus transport layer security. To learn more about this, and other topics such as X.509, please see the "Primers" section.

Note: There is also a Security Terminology Primer that describes a basic Web service security scenario and explains the use of terms such as: Subject, Credentials, and Identity Provider.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Introduction

This page uses frames, but your browser doesn't support them.


Introduction

Pattern maps have been created to show how architecture, design, and implementation patterns are related. Each pattern map represents a security feature or collection of security features that can logically be grouped together. Currently there are two sets of patterns related to authentication and message protection that have been grouped into pattern maps.

Authentication

Figure 1 shows the architecture and design patterns related to authentication.

Figure 1

Authentication Pattern Map

The reason that authentication is discussed as the primary security feature is that mechanisms used for authentication often influence mechanisms used for enabling other security features such as data confidentiality and Data Origin authentication. As an example, consider a case where the Kerberos protocol is used for Message Level authentication. Once a Kerberos session is setup 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 since we do not have to consider another security mechanism and infrastructure just to satisfy the data confidentiality needs.

Message Protection

Figure 2 shows architecture and design patterns related to message protection.

Figure 2

Message Protection Pattern Map

The Data Confidentiality pattern represents the ability to encrypt message data so that any entity, other than the Sender and Recipient, can not see it. The Data Origin Authentication pattern represents a security feature used to identify and validate the entity who actually sent a message. The Message Replay Detection pattern provides the ability to prevent repeated attempts to call a service with the same message.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Pattern Navigation

This page uses frames, but your browser doesn't support them.


Pattern Navigation

This section examines some of the major decisions that influence Web service security solutions. Some of the areas covered include a look at how trust relationships drive authentication methods and how requirements and the environment influence the choice of security tokens. Different factors that should be considered when using transport or message layer security are also examined.

See the following sections for more information.

  • Direct vs. Brokered Authentication. Provides information about Direct versus Brokered authentication and includes a decision matrix that identifies the primary factors you should consider.
  • Brokered Authentication Options. Identifies common security tokens related to Brokered authentication and provides a decision matrix that examines how requirements and the environment influence the choice of token.
  • Message Protection. Identifies security features related to message protection and provides a decision matrix that examines how requirements map to message protection features.
  • Transport Layer vs. Message Layer Security. Discusses the differences between transport layer and message layer security and includes a decision matrix that examines factors you should consider.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Direct vs. Brokered Authentication

This page uses frames, but your browser doesn't support them.


Direct vs. Brokered Authentication

The authentication pattern map identifies two architectural approaches for implementing authentication: Direct and Brokered. These patterns focus on the relationships that exist between a requestor and service who participate in a Web service interaction. When both the Requestor and Service participate in a trust relationship that allows them to share and validate credentials, then Direct authentication can be performed as shown below:

Examples where this is appropriate would be an Intranet application where all of the users belong to the same Active Directory domain. Another example would be a custom authentication implementation that requires a username and password to authenticate the requestor using information from a database.

In a situation where the Requestor and Service do not share a direct trust relationship, you can use a broker to perform authentication as shown below:

It is important to note that this diagram represents a high-level view of Brokered authentication. For instance, while the security token is always verified, the service typically does not need to interact with the broker to perform the verification. The reason for this is that 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 factors that may support one approach over the other. For instance, 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 provides a list of factors to consider and how those factors are supported by different authentication methods.

Table 1: Authentication Decision Matrix

Factor to Consider | Direct | Brokered
What will the Service require to prove the requestor’s identity for authentication? Passwords, certificates, or something else? | Direct authentication requires the presentation of credentials, which are typically a username and password. 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 identity provider that can validate the subject's credentials for authentication? | Since authentication is performed, direct access to the identity provider is required. | Most implementations of Brokered authentication do not require direct access to the Identity Provider.
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 user on every call can have a negative impact on performance when multiple services are involved. | 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 would be possible to cache the credentials, 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 username and password were sent with the message it would be possible to impersonate the user. This would only work if the user had a Windows User Account. | Kerberos provides the ability to implement delegation.

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

Implementation patterns have been created to provide examples of Direct and Brokered authentication. The pattern map in Figure 1 shows the implementation patterns and pattlets related to Direct authentication.

Figure 1

Direct Authentication Pattern Map

As you can see from this diagram, message layer implementations of Direct authentication use the UsernameToken security token in Microsoft Web Services Enhancements (WSE). When it comes to Brokered authentication, you can use message layer tokens supported by WSE or transport layer versions that use the same security infrastructure that WSE uses for some of its security tokens.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Brokered Authentication Options

This page uses frames, but your browser doesn't support them.


Brokered Authentication Options

This section looks at three of the main security tokens provided by WSE that also support Brokered authentication. These tokens are X.509, Kerberos, and a Custom security token that would be issued by a Security Token Service (STS). The focus here is to look at how requirements and the environment would influence the choice of security token used.

Table 1 represents a decision matrix that provides a list of factors to consider and how those factors are supported by different security tokens.

Table 1: Security Token Decision Matrix

Factor to Consider | X.509 | Kerberos | Custom (STS)
Existing Infrastructure | Requires support for a Public Key Infrastructure, which can be expensive to set up and maintain. For limited usage an external Certificate Authority (CA) can be used. | Requires an identity provider that supports Kerberos such as Active Directory. | Requires an STS implementation that issues and manages security tokens.
The requestor 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. | Kerberos authenticates users 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 user. | Supports both impersonation and delegation. | Not Supported.
Support for security sessions. | Most implementations exchange a 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 such as Java. | Based on industry standards and supported on many platforms. Typically used for interoperability with Java. | Based on industry standards, however, support is not as extensive as X.509. | Based on the implementation of the Security Token Service.
Support for Message Protection. | Can be used to provide confidentiality and DOA at the message and transport layers. | Supports confidentiality and DOA at the message layer and transport layer when used with IPSec. | Supports confidentiality and DOA at the message layer only.
Your application has a requirement for non-repudiation and auditing. | The identity of a user 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 Security Token Service

Once again, these are some of the main factors that should be considered. Other factors related to security policies or a threat analysis will also influence your choice. The pattern map in Figure 1 shows design and implementation patterns related to Brokered authentication:

Figure 1

Brokered Authentication Pattern Map

Here you can see that there are both message layer and transport layer implementations of X.509 and Kerberos. When it comes to SAML/STS the only choice available is to use message layer security. For more information on the use of Message Layer versus Transport Layer please see the Transport Layer vs. Message Layer Security topic.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Message Protection

This page uses frames, but your browser doesn't support them.


Message Protection

When it comes to Web service interactions, data confidentiality is an important feature that must be considered. In addition, the integrity of the message and ability to validate the origin of the message are also important topics to consider. Data Confidentiality represents the ability to encrypt message data so that any entity, other than the requestor and service, can not see it. Data Origin Authentication (DOA) supports both data integrity and the ability to verify the origin of a message. Finally, there are other features related to message protection such as Replay Detection, which supports the ability to prevent duplicate requests. The main factors that drive the amount of message protection required are usually related to security policies and threat analysis.

Table 1 represents a decision matrix that provides a list of factors to consider and describes how those factors are supported by transport or message layer security.

Table 1: Message Protection Decision Matrix

Factor to Consider | Confidentiality | Data Integrity | DOA
You are implementing Direct authentication with UsernameToken. | Encryption of the credentials used for authentication is strongly recommended. Typically this is done with HTTPS at the transport layer | Integrity of the data is also strongly recommended and supported by HTTPS. | The WSE UsernameToken does not support DOA. While HTTPS provides integrity it does not authenticate the origin of the message.
You have sensitive data that must be protected. | Encryption is the best way to protect the data. | Integrity is not required but is recommended. | Can be implemented using X.509 or Kerberos at the message layer.
Your Web service has requirements to support a high load and performance is a concern. | Encryption adds a lot of overhead. Consider using a message layer protocol and only encrypting data that must be protected. | XML Signatures are not as expensive to create. They also represent a good way to authenticate messages with little overhead. | The verification process may add some overhead based on the security infrastructure in place.

From the decision matrix above you can see that Data Confidentiality is recommended during authentication and anytime sensitive data is sent in a message. There are also many other factors to consider such as performance and privacy requirements.

The pattern map in Figure 1 identifies implementation patterns and pattlets that include Data Confidentiality.

Figure 1

Data Confidentiality Pattern Map

As you can see, Data Confidentiality is supported by message layer and transport layer protocols. When it comes to Data Origin authentication, however, the common approach is to use message layer security as shown in Figure 2.

Figure 2

Data Origin Authentication Pattern Map

Transport layer security is not typically related to Data Origin authentication because it only protects the message between two servers. While many of the transport layer protocols provide confidentiality and integrity, they have no information about the origin of the actual message. With message layer security it is possible to authenticate the origin of a message. For more information on message layer versus transport layer, please see the next topic.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Transport Layer vs. Message Layer Security

This page uses frames, but your browser doesn't support them.


Transport Layer vs. Message Layer Security

Transport Layer security represents an approach where the underlying operating system or application servers are used to handle security features. Windows Integrated authentication is an example of Transport Layer authentication. For Data Confidentiality, SSL is a common Transport Layer approach used to provide encryption.

Figure 1

Transport Layer Security

If a message needs to go through multiple points to reach its destination, each intermediate point must forward the message over a new SSL connection. In this model, the original message from the client is not cryptographically protected as it traverses intermediate servers and additional computationally expensive cryptographic operations are performed for every new SSL connection that is established.

Message Layer security represents an approach where all of the information related to security is encapsulated in the message. In other words, with Message Layer authentication the credentials are passed in the message. In addition, with Message Layer confidentiality, the encrypted data is passed in the message.

Figure 2

Message Layer Security

Securing the message instead of using the transport protocol has several advantages. First, it is more flexible because parts of the message can be signed or encrypted rather than the entire message. This means that intermediaries are able to view parts of the message intended for them. An example of this is a Web service that routes SOAP message being able to inspect unencrypted parts of the message to determine where to send the message, while other parts of the message remain encrypted. Secondly, intermediaries can add their own headers to the message and sign them for the purpose of audit logging. Finally, it means that the secured message can be sent over many different protocols such as SMTP, FTP, and TCP without having to rely on the protocol for security.

Table 1 represents a decision matrix that provides a list of factors to consider and how those factors are supported by transport or message layer security.

Table 1: Message Layer versus Transport Layer Decision Matrix

Factor to Consider | Transport Layer | Message Layer
Your application interacts directly with the Web service. | Transport layer HTTPS provides full message protection. | Message layer message protection usually requires more work and overhead than transport layer.
Web services are hosted on a system that does not support integrated authentication. | Basic over HTTPS could be implemented, however, it would require manipulation of message headers. | Authentication can be performed by passing credentials in the message.
Your company has a firewall in place between applications and Web services. | Ports could be opened to support HTTPS. | Message layer security is not affected by standard firewalls.
You have non-repudiation requirements | Does not support digital signatures. | Supports Digital signatures, which represents the standard approach for implementing non-repudiation.
A Web service request can pass through message queues or routing servers. | The message data is not protected as it passes through the server, which leaves it vulnerable to attack. | Message data will be protected as it passes through intermediate servers.
The Web service you are designing will handle a high concurrent load. | Hardware appliances can be used to improve performance with Transport Layer message protection such as SSL. | Security tokens can be used to establish a session, however, message protection has a high computational load.

As with previous decision matrices, the factors in this table represent some of the major factors you should consider when making decisions.

As you can see, there are many different factors to consider when putting together a security solution for Web services. Rather than attempting to walk through all of these different factors, the next section looks at scenarios and describes the solution that was implemented for each one.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Scenarios

This page uses frames, but your browser doesn't support them.


Scenarios

Three different scenarios will be used to provide examples of common Web service interactions. The first one is an Intranet-based scenario with a Windows application accessing a Web service within the same organization. The second is an Internet scenario that shows how security should be implemented between a public web application and internal Web services. The last scenario demonstrates how multiple security features can be used to support B2B interactions over the Internet. The scenarios described in this section are the following:

  • Intranet. Describes the decision criteria used to choose Message Layer Kerberos for an internal banking solution and provides a high level description of the Kerberos design.
  • Internet. Describes the decision criteria used to choose a Security Token Service (STS) for a travel agency application that is accessible from the Internet. This section also describes how both Direct authentication and Brokered authentication are used to implement the solution.
  • B2B Intranet. Describes a B2B solution that uses Message Layer Kerberos within the organization and X.509 between businesses.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Intranet Scenario

This page uses frames, but your browser doesn't support them.


Intranet Scenario

This scenario represents an Intranet application that makes substantial use of the following patterns. You may find it useful to consider this scenario while reading these patterns.

● Brokered Authentication

● Brokered Authentication – Kerberos

● Data Confidentiality

● Data Origin Authentication

● Implementing Message Layer Security with Kerberos in WSE 2.0

Note: Implementing Message Layer Security with Kerberos in WSE 2.0 is currently under development.

A national bank uses Web services to provide operations that are accessed by an internal banking application. The following diagram shows how the banking application accesses the Web service:

Figure 1

Intranet Banking Application

The banking application is a Windows client that directly access a Web service. The Web services access an account database for information. The following list provides an overview of the banking application requirements.

Banking Application Profile:

● A banking application used in bank branches.

● The user of the application is a customer service representative (CSR).

● The CSR must be authenticated as a valid user in order to use the banking application.

● Banking regulations require that the account activities carried out by the CSR be audited.

Solution Approach

After having considered application requirements along with other factors such as the environment, security policies and threat analysis, it was determined that Message Layer security with Kerberos would provide the best solution.

In order to determine that Message Layer security with Kerberos was the best solution, the following security factors were considered:

● Environment:

● Active Directory implemented on Windows Server 2003.

● CSR users are located in the Active Directory.

● Security Policies:

● Mutual authentication is required for all Web service interactions.

● Applications must support single sign on capabilities.

● Threat Analysis:

● Message data is sensitive and must be protected against unauthorized access.

● The message must not be tampered with during transit.

Once this information is collected, the first step is to determine what authentication methods are supported. The next step is to determine which one provides the message protection features required by the application. In addition, it is also important to consider other factors such as performance and interoperability requirements. Rather than walk through the decision process, Table 1 describes how Message Layer Kerberos supports the application.

Table 1: Intranet Banking Application Considerations for Message Layer Kerberos

Consideration | Comments
Authentication | Active Directory supports the use of Kerberos. Kerberos provides support for single sign on capabilities.
Message data is sensitive and must be protected against unauthorized access. | The Kerberos security token can be used to encrypt a message.
The message must not be tampered with during transit. | The Kerberos security token can be used to sign a message, which provides data integrity and data origin authentication.
Account activities carried out by the CSR must be audited. | Kerberos also supports impersonation and delegation, which means that auditing can be performed.
Mutual authentication is required. | Since the Kerberos security token contains both requestor and service information it can be used for mutual authentication.

Solution Description

The following diagram shows the Banking Application security solution:

Figure 2

Security Solution for Intranet Banking Application

The following list describes how Message Layer Kerberos is implemented:

● The user's credentials are used to obtain a security token from the Key Distribution Center implemented in Active Directory.

● The Security Token is used to sign and encrypt messages sent to the service.

● The Security Token is used to obtain additional information about the user from Active Directory.

● Impersonation is used to access the database.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Internet Scenario

This page uses frames, but your browser doesn't support them.


Internet Scenario

This scenario represents an Internet application that makes substantial use of the following patterns. You may find it useful to consider this scenario while reading these patterns.

● Direct Authentication

● Brokered Authentication

● Data Confidentiality

● Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

● Brokered Authentication – SAML/STS

● Implementing Message Layer Authentication with UsernameToken in WSE 2.0

Note: The last two topics are under development.

A Travel Booking franchise provides a Web application that travel agents can use to search for and book travel packages. The Web application uses several Web services to perform the operations of searching for and booking packages. Figure 11 provides a high level view of the configuration.

Figure 11

Internet Travel Booking Application

The Travel Booking Web application is accessible from the Internet, however, the Web services that the application calls are not accessible from the Internet. Each Web service has an independent data store. The following list provides an overview of the Travel Booking application requirements.

Travel Booking Application Profile

● Travel agents for travel franchise help customers book tour packages.

● Two Web services are used: Travel Packages Web Service and Online Booking Web Service.

● Travel Packages Web Service provides travel product catalog information such as tour dates, itinerary, and prices.

● Online Booking Web Service allows the travel agent to book tour packages on behalf of the customers.

● Identity propagation is needed for the online booking Web service as the database needs to keep record of the travel agent that made the travel requests. Customers can go to any travel agent in the franchise to book a tour.

● During peak travel seasons, user activity is high. This means that performance must be considered.

Solutions Approach

After having considered application requirements along with other factors such as the environment, security policies, and threat analysis, it was determined that the best solution was a combination of Direct authentication and Brokered authentication. Direct authentication would be used to access a Security Token Service (STS) using WSE 2.0. The security token returned would then be used for Brokered authentication against the Web services. The security token can also be used to provide Data Confidentiality and Data Origin authentication support as needed.

In order to determine that Message Layer security with a Security Token Service was the best solution the following factors were considered:

● Environment:

● Travel agent user accounts are stored in a database.

● Servers used to host the Web services sit behind a firewall.

● The travel agent franchise does not have a Public Key Infrastructure.

● Security Policies:

● Mutual authentication is required for all Web service interactions.

● Applications must support single sign on capabilities.

● Threat Analysis:

● The online booking service handles sensitive data that must be protected against unauthorized access.

Once this information is collected, the first step is to determine what authentication methods are supported. The next step is to determine which one provides the message protection features required by the application. In addition, it is also important to consider other factors such as performance and interoperability requirements. Rather than walk through the decision process, Table 6 describes how message layer STS supports the application.

Table 6: Internet Travel Booking Application Considerations for Message Layer STS

Consideration | Comments
Authentication | When user credentials are stored in a database, Direct authentication is used to authenticate the user. In order to support single sign on capabilities, Direct authentication can be combined with Brokered authentication using a Security Token Service.
Web services sit behind a firewall. | Message layer protocols are easier to implement when passing through firewalls.
Mutual authentication is required. | The use of a shared symmetric key with STS provides Mutual authentication.
Sensitive data must be protected against unauthorized access. | The security token issued by an STS can be used to provide Data Confidentiality and Data Origin authentication.
Single sign on support is required. | The security token issued by a STS can be used to access multiple Web services.
Performance must be considered. | Brokered authentication speeds up operations when multiple Web services are accessed. In other words, authentication is only performed once. Encryption with a shared symmetric key is much faster than asymmetric methods. Only one of the Web services requires encryption.

Solutions Description

The following diagram shows the security solution developed for the Travel Booking Application:

Figure 12

Security Solution for Internet Travel Booking Application

To implement message layer STS, the first step is to obtain a security token using Direct authentication. Specifically, the implementation of UsernameToken in WSE 2.0 can be used to access a Security Token Service.

When using the SecurityContextToken with WSE 2.0 you are also required to sign the message that is used to request a security token. Although the UsernameToken security token can be used to sign a message in WSE, it is not recommended. Instead X.509 certificates should be used if they are available. This can be accomplished without setting up an X.509 PKI. All that you would need is a certificate issued to the Travel Booking Application that can be used for signing. The SecurityContextToken implementation pattern provides further information on signing the request. (Note: this pattern is under development.)

Once the agent has logged on and a security token has been issued, the next step is to use the security token to access both of the Web services.

● When accessing the travel package Web service, encryption is not required. The message should be signed with the STS security token in order to provide authentication.

● Access to the data source uses a trusted subsystem approach, which means that impersonation is not required.

● When accessing the online booking Web service the message should be signed and encrypted in order to protect the data against unauthorized access.

● Access to the data source uses trusted subsystem, however, the travel agent identity is also required. This still does not require impersonation. Instead, the agent's ID is retrieved from the security token and passed to the data source as part of the request.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Internet B2B Scenario

This page uses frames, but your browser doesn't support them.


Internet B2B Scenario

This scenario represents an Internet B2B application that makes substantial use of the following patterns. You may find it useful to consider this scenario while reading these patterns.

● Brokered Authentication

● Brokered Authentication – Kerberos

● Brokered Authentication – X.509 PKI

● Data Confidentiality

● Data Origin Authentication

● Implementing Message Layer Security with X.509 Certificates in WSE 2.0

● Implementing Message Layer Security with Kerberos in WSE 2.0

Note: Implementing Message Layer Security with Kerberos in WSE 2.0 is currently under development.

A supply chain application uses internal Web services to perform operations. The internal Web services may need to access external Web services provided by another company. Figure 1 provides a high level snapshot of a procurement operation:

Figure 1

Internet B2B Supply Chain Management Application

The example above shows an operation where the supply chain application interacts with the procurement Web service. The procurement Web service accesses an external ordering Web service over the Internet. The following list provides an overview of the Supply Chain application requirements.

Supply Chain Management Application Profile

● The manufacturing company gets parts from a business partner.

● Parts are ordered through an internal line of business (LOB) Supply Chain Management application.

● Factory floor supervisors are the users of the application.

● The application communicates with a Procurement Web service that places the order with an Ordering Web service hosted by the supplier. This way, only the two Web services have to agree on the external service contract.

● The Procurement Web service is one of a few other internal Web services that the Supply Chain Management Application uses. Maintaining a single sign on user experience is an important requirement.

Solution Approach

There are actually two parts to analyze: the Intranet communication between the supply chain application and the Procurement Web service and the Internet communication between the Procurement Web service and the Ordering Web service.

After having considered application requirements along with other factors such as the environment, security policies and threat analysis it was determined that the best solution was to use Message Layer Kerberos within the Intranet environment and Message Layer X.509 between the Procurement Web service and the Ordering Web service.

In addition to the application requirements above, the following factors were considered:

● Environment:

● Active Directory implemented on Windows Server 2003.

● Application users are located in the Active Directory.

● External Web service is hosted in an unknown environment.

● Security Policies:

● Mutual authentication is required for all Web service interactions.

● Applications must support single sign on capabilities.

● Threat Analysis:

● Factory parts and associated pricing information is sensitive. As a result, the data must be protected against unauthorized access.

Once this information is collected, the first step is to determine what authentication methods are supported. The next step is to determine which one provides the message protection features required by the application. In addition, it is also important to consider other factors such as performance and interoperability requirements. With this scenario, there were two different decisions to make: security within the Intranet and security with the external company via the Internet.

Rather than walk through the decision process, Table 1 describes how the decisions were made.

Table 1: Supply Chain Management Application Considerations for Message Layer Kerberos (Intranet) and Message Layer X.509 (Internet)

Consideration

Description

Authentication

Within the Intranet, Kerberos is supported and it provides single sign on capability, which is a security requirement.

Interaction between the internal and external Web service does not require the credentials of the user. As a result, an alternate form of authentication can be used such as Message Layer X.509.

External Web service is hosted in an unknown environment.

X.509 certificates represent a well-known protocol that supports interoperability with other platforms.

Data must be protected against unauthorized access.

Message layer Kerberos supports both Data Confidentiality and Data Origin Authentication.

Message layer X.509 also supports Data Confidentiality and Data Origin Authentication.

Mutual authentication is required.

Both Message Layer Kerberos and Message Layer X.509 support mutual authentication.

Solution Description

The following diagram shows the security solution that was developed for the Supply Chain Management Application:

Figure 2

Security Solution for the Supply Chain Management Application

The following list describes how Message Layer Kerberos is implemented:

● The user's credentials are used to obtain a security token from the Key Distribution Center implemented in Active Directory.

● The Security Token is used to sign and encrypt messages sent to the service

In order to implement Message Layer security with X.509, the first step is to issue security tokens and import them into appropriate certificate stores. For information on configuring X.509, please see the X.509 Security Primer.

Once X.509 is configured it can be used to provide mutual authentication, Data Confidentiality, and Data Origin authentication for interactions between the Procurement Web service and the Ordering Web service.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Direct Authentication

This page uses frames, but your browser doesn't support them.


Direct Authentication

Context

An online application needs to access a Web service. The Web service requires that the application presents credentials for authentication so that additional controls such as authorization and auditing can be implemented.

Problem

How does the Web service verify the credentials presented by the requesting application?

Forces

  • The credentials that the online application presents to the Web service are based on shared secrets such as passwords. Authentication of individual users is often performed using passwords. Computers and applications will often use higher quality secrets that are more secure than passwords. The online application and the Web service must exchange the shared secrets securely before interaction is possible. Exchange of shared secrets must occur through an out-of-band mechanism.
  • T he Web service can validate the credentials from the online application against an identity provider. The Web service must have direct access to the identity provider, including appropriate permissions for accessing identity information.
  • T he Web service has access control requirements that do not justify the full capabilities of the infrastructure provided by an Authentication Broker. If the environment is relatively simple, and does not require single sign on or non-repudiation, an effective, lower cost solution may be required that does not use an Authentication Broker.
  • The online application and the Web service trust one another to manage credentials securely. Both parties should consider the credentials as equal in value to the information and services they protect. If either the Web service or the online application manage the credentials in an insecure manner, neither party can be sure that the mishandled credentials prove the identity of the user or application.

Solution

Use Direct Authentication, where the Web service validates credentials from the online application. The credentials, which are based on shared secrets, are verified against an Identity Provider.

Security Concepts

Proof-of-possession is a value that a subject presents to demonstrate knowledge of a shared secret in order to prove his/her identity. Proof-of-possession can be the actual shared secret, such as a user's password, or a password equivalent, which can be created in a number of ways, including the following:

● [image] A digest of the shared secret, which is typically created using a hash of the shared secret and a salt value

● A signature for the message that was generated with the shared secret.

Proof-of-authentication is verifiable proof that a subject has successfully authenticated with an authentication broker. Proof of authentication takes the form of a token that is issued by the authentication broker and can be presented to another party that trusts the authentication broker

For more information on the use of proof of authentication, see Brokered Authentication.

Participants

The following participants take part in Direct Authentication:

  • Subject - A user, application, or computer that needs to be authenticated with the Web service.
  • Requestor – the online application needing to access the Web service. The Requestor acts on the subjects behalf, providing the Subject's credentials for authentication during the request to the Web service. In some cases the Subject and the Requestor may be the same application.
  • Service - The Web service that requires authentication of a Subject prior in order to making access control decisions
  • Identity Provider – The entity that has authoritative control over a Subject's unique identifier and identity secret for a given Identity Domain.

The relationship between the participants is shown in Figure 1.

Figure 1

Relationship between participants in Direct Authentication

Process

The following diagram identifies the tasks that are performed with direct authentication:

Figure 2

The Direct Authentication Process

There are two main tasks that need to be accomplished for a subject to be authenticated.

1. The Requestor generates a Web service request and attaches the Subject's credentials to the request message.

2. The Service contacts the Identity Provider to validate the credentials of the subject.

The service can then make authorization decisions based on the authenticated Subject's identity and may send a response to the Requestor.

Resulting Context

The following benefits, liabilities, and security considerations are associated with the use of Direct Authentication.

Benefits

  • Represents an uncomplicated model for authenticating Subjects without the need for an Authentication Broker
  • If the shared secret between a requester and service is compromised, only the relationship between those two parties is compromised and not the entire model.

Liabilities

  • The decentralized nature of Direct Authentication requires that the trust relationship is managed between each point in the communication, as shown in Figure 3.

Figure 3

Direct Authentication with multiple points of communication

Each line in the diagram represents a discreet trust relationship established by authentication with a shared secret. As the number of discreet relationships between requestors and services increases, each with potentially different identity providers, the challenges of managing and distributing secrets becomes more complicated.

  • If a requestor calls a Web service frequently then the use of Direct Authentication can cause a significant performance overhead, as the Web service must authenticate using the Identity provider for each new request.
  • Data ownership and synchronization issues can occur if several Services each have their own Identity Provider to authenticate the same Subject. This is because the Subject's credentials may need to be duplicated across multiple Identity Providers.

Security Considerations

  • An attacker can impersonate the Subject if he or she intercepts the subject’s identity secret. The identity secret may be obtained if it is unprotected in transit, or successfully guessed offline. You should use Data Confidentiality to encrypt this data. For more details see the Data Confidentiality pattern.
  • A shared secret is sensitive data and must be secured whenever it is persisted – even if will only be held for a short time in a message queue. You should use Data Confidentiality to encrypt the shared secret. For more details see the Data Confidentiality pattern.
  • Shared secrets must be protected when stored by an identity provider in its identity store. If an attacker gains unauthorized access to an identity store that stores passwords in plaintext, all passwords in the identity store are immediately compromised, allowing the attacker to impersonate any user. Most identity providers such as Active Directory and LDAP-enabled directory services store passwords either hashed, encrypted or both. However, if you implement a custom identity provider such as a database, you must ensure that the passwords are protected. Hashing the passwords in the database will protect them from immediate disclosure in the event that an attacker gains access to them. For more information on how to hash passwords in a database, see Implementing Direct Authentication with UsernameToken using a Database.

Related Patterns

There are three different types of patterns associated with Direct Authentication: Child patterns, dependent patterns, and alternate patterns.

Child Patterns

  • Implementing Direct Authentication with UsernameToken using a Database - Implementation pattern that focuses on using Direct Authentication at the message layer using a database as a custom identity provider.
  • Implementing Direct Authentication with UsernameToken using a Directory Service - Implementation pattern that focuses on using Direct Authentication at the message layer with an LDAP directory service as the identity provider.
  • Implementing Direct Authentication with UsernameToken using Windows User Accounts - Implementation pattern that focuses on using Direct Authentication at the message layer with an Active Directory domain as the identity provider.
  • Pattlet – Transport Layer Security using HTTP Basic over HTTPS – Pattlet that provides information for implementing Direct Authentication using IIS at the transport layer.

Dependent Pat terns

Brokered Authentication - Uses variations of Direct Authentication to prove a Subject’s identity to an Authentication Broker for issuance of a security token.

Alternate Patterns

Brokered Authentication – An alternative to direct authentication where authentication occurs based on credentials issued by a trusted Authentication Broker.

References

  • OASIS Standards and Other Approved Work (including WS-Security) at http://www.oasis-open.org/specs/index.php#wssv1.0

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Implementing Direct Authentication with UsernameToken using a Database

This page uses frames, but your browser doesn't support them.


Implementing Direct Authentication with UsernameToken using a Database

Context

You are implementing Direct Authentication for an online application consuming a Web Service that uses Web Service Enhancements (WSE) 2.0. You are using Message layer authentication. The credentials, used to prove the identity of the calling application or user, are located in a database.

Implementation Strategy

The WSE implementation of UsernameToken is used to implement Direct Authentication at the message layer. The requestor passes the subject's credentials as part of a signed and encrypted Web service request message.

A password is not sent across the network – instead proof-of-possession is established by verifying an XML Signature within the message, which is generated using the password equivalent as a signing key. The service authenticates the subject by recognizing the subject’s unique identifier, and verifying the proof-of-possession associated with the identifier with the Identity Provider. The Web service then sends an encrypted response back to the requestor.

Approach

Two tasks must be performed to implement Direct Authentication with Username Token using a database.

1. Requestor generates Web service request.

2. Service authenticates Subject and returns a response.

Each task is divided into specific steps. While you are strongly encouraged to follow the recommendations, the steps contain enough information to allow you to tailor a solution to your specific needs.

Requestor Generates Web Service Request

This task has three steps that are recommended:

1. Initialize the UsernameToken

2. Sign the Message

3. Encrypt the Message

Each step is discussed in more detail below:

Step One: Initialize UsernameToken

This pattern implements a UsernameToken with the SendNone password option. Proof-of-possession and Data Origin Authenticity are provided by using a SHA-1 HMAC XML Signature (for more information, see the Data Origin Authentication pattern). No password is sent in the UsernameToken, as proof-of-possession is provided by the XML Signature.

Note: For more information on UsernameToken, see UsernameToken Primer .

You should use policy in WSE 2.0 to ensure that messages are encrypted and signed. The location of the policy cache file must be specified in the Requestors configuration file under the <configuration> element, as shown in the following code example:

<microsoft.web.services2>

  <policy>

       <cachename="../../Configuration/PolicyCache.config"/>

  </policy>

</microsoft.web.services2>

Note: The identity under which an application is running must have read/execute permissions on the policy cache file; otherwise, the Requestor will not be able to access the cache properly.

Although the password is not sent in the UsernameToken for authentication, the Requestor uses the password value of the initialized UsernameToken as the signing key for the XML Signature. A password equivalent, rather than the password itself, is used as the key to create the XML signature. This is because the signing key is stored in the database, and you should not store passwords in a database as plaintext. If passwords are stored in this way, they could be compromised immediately if an attacker gains access to the database. The password equivalent is a salted hash value that uses the Subject’s password plus other values to make it more difficult for an attacker to guess the Subject’s password offline

The following formula is recommended to create the password equivalent: SHA1 (password + username + URI). The URI is unique to the service that the requestor is accessing. This means that if the database is compromised, the password in only good for a specific application and not all applications that the subject uses the same password to access.

The code example shows how to implement the password hashing formula described above:

private string GetSaltedHash( string userName, string password, string url )

{

HashAlgorithm algorithm = new SHA1Managed();

byte[] userNameBytes = UTF8Encoding.UTF8.GetBytes( userName.ToLower( CultureInfo.InvariantCulture ) );

byte[] passwordBytes = UTF8Encoding.UTF8.GetBytes( password );

byte[] urlBytes = UTF8Encoding.UTF8.GetBytes( url.ToLower( CultureInfo.InvariantCulture ) );

byte[] value = new byte[ userNameBytes.Length + passwordBytes.Length + urlBytes.Length ];

userNameBytes.CopyTo( value, 0 );

passwordBytes.CopyTo( value, userNameBytes.Length );

urlBytes.CopyTo( value, userNameBytes.Length + passwordBytes.Length );

byte[] hash = algorithm.ComputeHash( value );

return Convert.ToBase64String( hash );

}

The following code example shows how to initialize a UsernameToken and add it to the policy cache:

string signatureKey = GetSaltedHash(userName, password, url);

UsernameToken token = new UsernameToken( userName, signatureKey, PasswordOption.SendNone );

PolicyEnforcementSecurityTokenCache.GlobalCache.Clear();

PolicyEnforcementSecurityTokenCache.GlobalCache.Add( token );

The username and password values passed in the example above are strings assigned with the appropriate values. The password argument specified in the UsernameToken constructor is the password equivalent created using the custom hashing function shown above. This is used to sign the message even though the password is not being sent over the wire. The UsernameToken is added to the PolicyEnforcementSecurityTokenCache allowing the outgoing policy assertions to use the security token.

Step Two: Sign the Message

A password or password equivalent is not included in the UsernameToken to provide proof-of-possession, and so the message must be signed. One advantage of this approach is that XML Signatures provide a more efficient means of providing multiple security capabilities. The Subject can be authenticated and both the origin and integrity of message content can be verified using the XML Signature.

While using an XML Signature as proof-of-possession rather than a password or digest provides additional protection against unauthorized disclosure of the password, the XML signature is still susceptible to offline cryptanalysis to obtain the signing key. It must therefore be protected using data encryption. SSL and Message layer protection each provide data confidentiality to protect the XML Signature from offline cryptanalysis. If you choose to adopt message layer protection, and are encrypting selected parts of the message, the XML Signature should be considered a sensitive piece of message data to be encrypted.

The following Integrity policy assertion uses the UsernameToken previously initialized and added to the policy cache to sign outgoing messages. The policy ensures that the signing UsernameToken cannot be sent with a password. If the UsernameToken used to sign the message does not have the password option set to PasswordOption.SendNone, the policy will not be satisfied and the message will not be sent.

…

<wssp:Integrity wsp:Usage="wsp:Required">

<wssp:TokenInfo>

<SecurityToken xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext">

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken</wssp:TokenType>

<wssp:Claims>

<wssp:UsePassword wsp:Usage="wsp:Rejected" />

</wssp:Claims>

</SecurityToken>

</wssp:TokenInfo>

<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">

wsp:Body() wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From) wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo) wsp:Header(wsa:To) wse:Timestamp()

</wssp:MessageParts>

</wssp:Integrity>

<wsp: MessagePredicate wsp:Usage="wsp:Required" Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">

wsp:Body()wse:Timestamp()

</wsp:MessagePredicate>

…

Step Three: Encrypt the Message

You should encrypt the message from the requestor to the service to provide data confidentiality, and to ensure that only the intended recipient of the message is capable of processing it.

There are two possible approaches to encrypt the message:

  • SSL
  • Message Layer Security

SSL encrypts the request message from the Requestor so that only the Service can decrypt it. It is a well-established protocol and is easy to implement on the Windows platform. It can also provide improved performance over message layer security. For details on implementing SSL, see “Pattlet –Transport Layer Security using X.509 Certificates and HTTPS.”

SSL provides good performance, and is easy to configure. However, there are circumstances when SSL is not an appropriate choice. If you need to persist messages, or if the messages must be handled by intermediaries, then you should use Message Layer Security. This approach uses the server’s X.509 certificate to encrypt the request message. Unlike SSL, sensitive parts of the message may be selectively encrypted rather than the entire communication at the transport layer. For more information on implementing the alternate approach to SSL with message layer X.509 security, see Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

If SSL is used to encrypt the message, no code is required. If message layer X.509 encryption is being used, then code must be implemented to encrypt the message. For more information, and code examples that demonstrate how to encrypt the message, see Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

Service Authenticates Subject and Returns a Response

This task has four steps that are recommended:

1.Decrypt the request message

2.Obtain the Signing Key

3.Verify the Message Signature

4.Encrypt the response

Each step is discussed in more detail below:

Step One: Decrypt the request message

The option chosen to encrypt the request message determines how the request message is decrypted by the Service. Both SSL and WSE 2.0 will decrypt the message automatically, and require no additional coding.

Step Two: Obtain the Signing Key

Once the message is received by the service the information in UsernameToken is verified by WSE using the UsernameTokenManager class.

By default, the AuthenticateToken method of the UsernameTokenManager class is used by WSE to validate the information in the UsernameToken against Active Directory. However, because you are using a custom database, and using the SendNone option for passwords on the UsernameToken, you need to create a sub-class of the UsernameTokenManager class, and then override the AuthenticateToken method. As no password is sent, this custom manager is used to return the password equivalent, used as the signing key to verify the XML signature.

An entry must be included in the Service’s web.config file under the <configuration> element to specify the location of the policy cache file that contains policy assertions. Also, you should use the <securityTokenManager> element to designate the CustomUsernameTokenManager as the handler for incoming UsernameTokens:

<microsoft.web.services2>

<security>

<securityTokenManager type="DirectTrustWithUsernameToken.UsernameTokenWithCustomIdentityProvider.CustomUsernameTokenManager, DirectTrustWithUsernameToken.UsernameTokenWithCustomIdentityProvider.Service" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" qname="wsse:UsernameToken" />

</security>

<policy>

<cache name="Configuration/PolicyCache.config" />

</policy>

</microsoft.web.services2>

You must make sure that the identity under which the Service is running has read/execute permissions on the policy cache file. If it does not have these permissions, the Service will not be able to access the cache properly.

The code below is an example of the overridden AuthenticateToken method in a CustomUsernameTokenManager implementation. It authenticates the Subject, then creates and attaches a GenericPrincipal to the security token so that the Service can make authorization decisions about the Subject:

using System;

using System.Xml;

using System.Security.Permissions;

using System.Runtime.InteropServices;

using System.Security.Principal;

using System.Data;

using Microsoft.Practices.EnterpriseLibrary.Data;

using Microsoft.Web.Services2.Security;

using Microsoft.Web.Services2.Security.Tokens;

namespace DirectTrustWithUsernameToken.UsernameTokenWithCustomIdentityProvider

{

...

public class CustomUsernameTokenManager : UsernameTokenManager

{

...

protected override string AuthenticateToken( UsernameToken token )

{

string password = GetUserPassword( token.Username );

if( password != null )

{

GenericIdentity identity = new GenericIdentity( token.Username, "SQL Server" );

GenericPrincipal principal = new GenericPrincipal( identity, null );

token.Principal = principal;

}

return password;

}

...

}

...

}

In this code example, GetUserPassword is user defined function that retrieves the Subject’s password stored in the Identity Provider database.

Note: Guidance on how to communicate securely with a database can be found at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch12.asp

Step Three: Verify the Message Signature

The method used when the message was signed by the Requestor also defines the method used by the Service to verify the signature.

You should create a policy for the service that is used to ensure that incoming messages are signed with a UsernameToken. The key returned from the CustomUsernameTokenManager is used by the policy assertion to compute the signature, and this signature is then compared to the signature attached to the message. The following example policy assertion requires all incoming messages to be signed with a UsernameToken. The policy is also configured to reject requests with UsernameTokens that contain a value in the password attribute.

<wssp:Integrity wsp:Usage="wsp:Required" >

<wssp:TokenInfo>

<SecurityToken xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext">

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken</wssp:TokenType>

<wssp:Claims>

<wssp:UsePassword wsp:Usage="wsp:Rejected" />

</wssp:Claims>

</SecurityToken>

</wssp:TokenInfo>

<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">

wsp:Body() wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From) wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo) wsp:Header(wsa:To) wse:Timestamp()

</wssp:MessageParts>

</wssp:Integrity>

<wsp:MessagePredicate wsp:Usage="wsp:Required" Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">

wsp:Body() wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID) wse:Timestamp()

</wsp:MessagePredicate>

Step Four: Encrypt the Response

The method used to encrypt the request message, is also used to encrypt the response message is encrypted by the Service. Both SSL and WSE 2.0 will encrypt the response automatically, and require no additional coding.

Resulting Context

A number of benefits, liabilities, and security considerations are associated with the implementation of UsernameToken.

Benefits

  • Flexible support for different Identity providers that use databases as Identity Stores.
  • Does not require the use of Integrated Security on a Web server.

Liabilities

UsernameTokens in WSE prevent replay attacks under the covers by using a nonce and timestamp with a replay cache on the server. However, the replay cache is not shared across a server farm. Approaches to mitigate this issue include:

  • Configuring a network load balancing device to allow session affinity, so that calling applications communicate with the same Web service throughout the duration of a session or replay cache lifetime. This is a relatively simple solution to the problem but sacrifices system availability. If the server hosting the Web service goes offline during a session, any state maintained by the Web service will be dropped, forcing the client to re-establish state on the server farm with a different server.
  • Creating a common server-side state mechanism such as a central database cache to share the replay cache information across the server farm. While this solution minimally impacts availability of the server farm to calling applications, it is a more complex solution to implement, requiring extension of existing WSE classes to use the common state mechanism. One of the inherent problems with centralized state mechanisms is performance—since the state mechanism is farther away from the code implementation, it may affect performance. A database state mechanism is durable and sharable across multiple servers, but it is also much slower than an in-memory cache used by each server maintaining its own state.

Security Considerations

The following subjects represent security aspects that should be considered when using this implementation of Direct Trust.

  • The signature used to sign the message should also be encrypted using either message layer security or transport layer security such as SSL. Unencrypted signatures also can be the target of offline guessing attacks. WSE 2.0 does not support encrypting message signatures using Policy. A custom policy assertion to provide this capability can be found in the Microsoft WS-I BSP Sample Application (http://msdn.microsoft.com/practices/default.aspx?pull=/library/en-us/dnpag2/html/MSWSIBSP.asp)
  • SSL does not guarantee message integrity and confidentiality in a chain of Web service interactions. If SSL is implemented between several intermediaries providing point-to-point security, the environment is vulnerable to man-in-the-middle and XML attacks. Certificate mismanagement, could also compromise the security of the implementation.

While passwords are considered one of the weakest forms of identity used for proof of possession, they are also the most common. As a result, it's important to understand threats and vulnerabilities associated with passwords.

  • Passwords are often based on words and phrases that can be remembered, making it easier to discover passwords through the use of brute force attacks that try thousands of common passwords and word combinations. This vulnerability can be mitigated by using complex passwords or password phrases, although user passwords should still be memorable, or they are likely to be written down.
  • You should ensure that the password stored in the database is protected, because plaintext passwords stored in a database can be immediately compromised by an attacker that has gained unauthorized access to the password database. To protect the password, it should be combined with a salt and then hashed. The hashed value represents a password equivalent, which is then stored in the database and used for authentication.

The following formula is recommended to create the password equivalent: SHA1( password + username + URI). The URI is unique to the service that the requestor is accessing. This means that if the database is compromised, the password is only good for a specific application and not all applications that the subject uses the same password to access.

The code example shows how to implement the password hashing formula described above:

private string GetSaltedHash( string userName, string password, string url )

{

HashAlgorithm algorithm = new SHA1Managed();

byte[] userNameBytes = UTF8Encoding.UTF8.GetBytes( userName.ToLower( CultureInfo.InvariantCulture ) );

byte[] passwordBytes = UTF8Encoding.UTF8.GetBytes( password );

byte[] urlBytes = UTF8Encoding.UTF8.GetBytes( url.ToLower( CultureInfo.InvariantCulture ) );

byte[] value = new byte[ userNameBytes.Length + passwordBytes.Length + urlBytes.Length ];

userNameBytes.CopyTo( value, 0 );

passwordBytes.CopyTo( value, userNameBytes.Length );

urlBytes.CopyTo( value, userNameBytes.Length + passwordBytes.Length );

byte[] hash = algorithm.ComputeHash( value );

return Convert.ToBase64String( hash );

}

  • An XML signature created with a password equivalent is less susceptible to offline cryptanalysis than an XML signature created using a plaintext password. However, this type of XML signature can still be vulnerable to offline attack, if it is intercepted over the network. To mitigate this problem, you should encrypt the message over the network. However, if you cannot encrypt the message, you should at least hash the password equivalent again to ensure that the signing key is different to the password equivalent stored in the database. This can be done in the following ways:
    • When the requestor initializes and sends a request, hash the derived signing key a second time using the UsernameToken timestamp as a salt, and then sign the message
    • When the service verifies the message signature, use the CustomUsernameTokenManager to retrieve the Subject’s password value in the AuthenticateToken method, hash it with the UsernameToken nonce and Timestamp and return the result as the password value. WSE uses this password value as the key to validate the signature.
  • Creating a hash for the signing key at the requestor may introduce unwanted complexity for online applications calling the Web service. An alternative approach is to send the password as a plaintext password in the UsernameToken instead of using an XML signature, and relying on encryption at the transport layer (HTTPS) for protection against eavesdropping and tampering. The service would then hash the password and use that hashed password to compare with the value in the database. For more information, see Implementing Direct Authentication with UsernameToken using a Directory Service.

References

  • Securing the Username Token with WSE 2.0 at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/securusernametoken.asp
  • WS-Security at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
  • Microsoft WS-I BSP Sample Application at http://msdn.microsoft.com/practices/default.aspx?pull=/library/en-us/dnpag2/html/MSWSIBSP.asp

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Implementing Direct Authentication with UsernameToken using a Directory Service

This page uses frames, but your browser doesn't support them.


Implementing Direct Authentication with UsernameToken using a Directory Service

Context

You are implementing Direct Authentication for an online application consuming a Web Service that uses Web Service Enhancements (WSE) 2.0. You are using Message layer authentication. The credentials, used to prove the identity of the calling application or user, are located in an instance of a Directory Service

Note: In this pattern, Active Directory Application Mode (ADAM) is used as an example for the purposes of demonstrating how to authenticate a Subject against an LDAP directory service, though the examples should be applicable for most LDAP directory services.

Implementation Strategy

The WSE implementation of UsernameToken is used to implement Direct Authentication at the message layer. The requestor passes the subject's credentials, to the Web service as part of a secure message exchange. The Web service decrypts the message, validates the credentials with the Directory Service, verifies the message signature, and sends an encrypted response that indicates whether the subject is authenticated or not.

Approach

Two tasks must be performed to implement Direct Authentication with UsernameToken using a Directory Service.

1. Requestor generates Web service request.

2. Service authenticates Subject and returns a response.

Each task is divided into a number of steps. While you are strongly encouraged to follow the recommendations, the steps contain enough information to allow you to tailor a solution to your specific needs.

Requestor Generates Web Service Request

This task has three steps that are recommended:

1. Initialize the UsernameToken

2. Establish Message Integrity

3. Encrypt the Message

Each step is discussed in more detail below:

Step One: Initialize UsernameToken

This pattern implements a UsernameToken with the SendPlainText password option, which sends the password over the network as plaintext. The “plaintext” value may be the actual password or a password equivalent. This option, used with the Default implementation of UsernameTokenManager, is similar to Basic Authentication over SSL.

If the subject’s password is being sent in plaintext the session should always be encrypted. Where possible, you should also store the passwords themselves in a hashed form. For more information on this, see Security Considerations.

Note: If you are not familiar with UsernameToken, refer to the UsernameToken Primer for more information.

The following code shows how to obtain a reference to the SOAP request context, initialize a UsernameToken and add it to the security tokens collection of the request context:

// SOAP request context is obtained from the WSE Web service proxy

SoapContext requestContext = serviceProxy.RequestSoapContext;

UsernameToken token = new UsernameToken( txtUsername.Text, password, PasswordOption.SendPlainText );

requestContext.Security.Tokens.Add( token );

Step Two: Establish Message Integrity

An XML signature could be created to sign the request message to provide data integrity implicitly through Data Origin Authentication, but in this pattern, an XML signature is of no value. This is because the password used as the signing key must be included in the message. An attacker could tamper with the message and then create a new signature using the password as the signing key.

As the XML signature cannot be used to provide Data Origin Authentication, another approach must be used. In many cases, full DOA is not required, only data integrity. However, two approaches are available that can provide DOA to the requester (though not to the subject). These are:

  • HTTPS
  • WSE 2.0 using X509SecurityToken

HTTPS provides data confidentiality and data integrity when server certificates are used. If you require DOA to the requestor, you should also use a client certificate for the requestor. For more information, see Pattlet –Transport Layer Security using X.509 Certificates and HTTPS.

WSE 2.0 using X509SecurityToken provides confidentiality without data integrity when server certificates are used. If you require DOA to the requestor, you should also implement client certificates. For more information, see Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

Step Three: Encrypt the Message

You should encrypt the message from the requestor to the service to ensure that only the intended recipient of the message is capable of processing it. The same method chosen to provide DOA in the previous step should be used for Data Encryption.

HTTPS encrypts the request message from the Requestor so that only the Service can decrypt it. For details on implementing HTTPS, see “Pattlet –Transport Layer Security using X.509 Certificates and HTTPS”.

WSE 2.0 using X509SecurityToken uses the server’s X.509 certificate to encrypt the request message. Unlike SSL, parts of the message may be encrypted rather than the entire communication at the transport layer. For more information on implementing the alternate approach to SSL with message layer X.509 security, see Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

If message layer X.509 encryption is being used, then code must be implemented to encrypt the message. For more information, and code examples that demonstrate how to encrypt the message, see Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

Choosing Between HTTPS and WSE 2.0 using X509SecurityToken

When you implement Direct Authentication with UsernameToken using a Directory Service, you will need to ensure that you provide Data Confidentiality, and possibly DOA to the requestor.

HTTPSis a well-established protocol and is easy to implement on the Windows platform, requiring no additional code. However, there are circumstances when HTTPS is not an appropriate choice. If you need to persist messages, or if the messages must be handled by intermediaries, then you should use WSE 2.0 using X.509SecurityToken. Unlike HTTPS, parts of the message may be encrypted at the message layer rather than the entire communication at the transport layer.

Service Authenticates Subject and Returns a Response

This task has four steps that are recommended:

1. Decrypt the request message

2. Verify Message Integrity

3. Validate the password

4. Encrypt the response

Each step is discussed in more detail below:

Step One: Decrypt the request message

The option chosen to encrypt the request message determines how the request message is decrypted by the Service. Both SSL and WSE 2.0 will decrypt the message automatically, and require no additional coding.

Step Two: Verify Message Integrity

The method used when message integrity was established by the Requestor also defines the method used by the Service to verify message integrity. Both SSL and WSE (using an Integrity policy assertion) will verify the message integrity automatically, and require no additional coding.

Step Three: Validate the password

Once the message is received by the service the information in UsernameToken is verified by WSE using the UsernameTokenManager class.

By default, the AuthenticateToken method of the UsernameTokenManager class, is used by WSE to validate the information in the UsernameToken. However, when you are using an Identity Provider other than Active Directory, you need to create a sub-class of the UsernameTokenManager class, and then override the AuthenticateToken method.

An entry must be included in the Service’s web.config file with the <securityTokenManager> element to designate the CustomUsernameTokenManager as the handler for incoming UsernameTokens:

<microsoft.web.services2>

<security>

<securityTokenManager type="DirectTrustWithUsernameToken. UsernameTokenWithAlternativeDirectory.CustomUsernameTokenManager, DirectTrustWithUsernameToken. UsernameTokenWithAlternativeDirectory.Service" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" qname="wsse:UsernameToken" />

</security>

</microsoft.web.services2>

The code below is an example of the overridden AuthenticateToken method in a CustomUsernameTokenManager implementation:

       using System;

using System.Xml;

using System.Security.Permissions;

using System.Runtime.InteropServices;

using System.DirectoryServices;

using System.Security.Principal;

using System.Configuration;

using Microsoft.Web.Services2.Security;

using Microsoft.Web.Services2.Security.Tokens;

namespace DirectTrustWithUsernameToken.UsernameTokenWithAlternativeDirectory

{

...

    public class CustomUsernameTokenManager : UsernameTokenManager

    {

   ...

protected override string AuthenticateToken( UsernameToken token )

{

if (token.PasswordOption == PasswordOption.SendPlainText)

{

this.AuthenticateUser(token);

return token.Password;

}

return null;

}

...

}

...

}

AuthenticateUser is a user defined function that binds to ADAM and uses System.DirectoryServices to authenticate the Subject, as shown in the following code example:

private void AuthenticateUser( UsernameToken token )

{

string rootPath = ConfigurationSettings.AppSettings[ "LDAPRootPath" ];

if( rootPath == null )

{

throw new ConfigurationException( RS.LDAPPathRequired );

}

try

{

DirectoryEntry root = new DirectoryEntry(rootPath);

root.Username = token.Username;

root.Password = token.Password;

root.AuthenticationType = AuthenticationTypes.None;

root.RefreshCache();

}

catch( Exception e )

{

throw new System.Security.SecurityException( RS.AuthenticationError, e );

}

}

In the above code sample, RS is a user-defined resource string manager that provides text for output and exception messages and should be replaced with whatever means you are using to provide resource strings for exception messages.

Another action commonly performed in the AuthenticateToken method, but not demonstrated in the code samples above, is obtaining principal information about the authenticated subject and attaching it to the token so that the service can make authorization decisions about the Subject. This can be done by creating a GenericPrincipal instance, adding role information to the instance, and then assigning the instance to the UsernameToken’s Principal property.

Step Four: Encrypt the Response

The method used to encrypt the request message, is also used to encrypt the response message is encrypted by the Service. Both SSL and WSE 2.0 will encrypt the message response automatically, and require no additional coding.

Resulting Context

The following benefits, liabilities, and security considerations are associated with the implementation of UsernameToken.

Benefits

  • Supports any type of Identity Provider that authenticates Subjects with username and plaintext password via LDAP.
  • Does not require the use of Integrated Security on a Web server.

Liabilities

The UsernameToken Digest setting should not be used, as it is only intended to protect the data on the wire. This can lead people to store passwords in clear text in the identity store. Also, hashed passwords transmitted without encryption are vulnerable to offline guessing attacks.

Directories are typically optimized for certain read / write characteristics and also for certain search paths. A directory service may not be the optimal solution for an Identity Provider that requires heavy updates to identity information or that have complex queries against the Identity Provider.

UsernameTokens in WSE prevent replay attacks under the covers by using a nonce and timestamp with a replay cache on the server. However, the replay cache is not shared across a server farm. Approaches to mitigate this issue include:

  • Configuring a network load balancing device to allow session affinity, so that calling applications communicate with the same Web service throughout the duration of a session or replay cache lifetime. This is a relatively simple solution to the problem but sacrifices system availability. If the server hosting the Web service goes offline during a session, any state maintained by the Web service will be dropped, forcing the client to re-establish state on the server farm with a different server.
  • Creating a common server-side state mechanism such as a central database cache to share the replay cache information across the server farm. While this solution minimally impacts availability of the server farm to calling applications, it is a more complex solution to implement, requiring extension of existing WSE classes to use the common state mechanism. One of the inherent problems with centralized state mechanisms is performance—since the state mechanism is farther away from the code implementation, it may affect performance. A database state mechanism is durable and sharable across multiple servers, but it is also much slower than an in-memory cache used by each server maintaining its own state.

Security Considerations

The following subjects represent security aspects that should be considered when using this implementation of Direct Trust.

  • The password in a UsernameToken should always be encrypted, using either message layer security, or transport layer security such as SSL. This mitigates the threat of an offline guessing attack against the UsernameToken.
  • If a UsernameToken was used to sign the message, the signature used to sign the message should also be encrypted using either message layer security or transport layer security such as SSL. Unencrypted signatures also can be the target of offline guessing attacks.
  • SSL does not guarantee message integrity and confidentiality in a chain of Web service interactions. If SSL is implemented between several intermediaries providing point-to-point security, the environment is vulnerable to man-in-the-middle and XML attacks. Certificate mismanagement, could also compromise the security of the implementation.

While passwords are considered one of the weakest forms of identity used for proof of possession, they are also the most common. As a result, it's important to understand threats and vulnerabilities associated with passwords.

  • Passwords are often based on words and phrases that can be remembered, making it easier to discover passwords through the use of brute force attacks that try thousands of common passwords and word combinations. This vulnerability can be mitigated by using complex passwords or password phrases, although user passwords should still be memorable, or they are likely to be written down.
  • If your Directory Service Identity Store replicates with Active Directory, then you cannot hash the passwords, as it is not possible to manipulate how passwords are handled in Active Directory.
  • Your Directory Service Identity store should store hashed passwords, as this prevents easy disclosure of passwords if the directory service’s identity store is compromised by an attacker. For more information on hashing passwords, see Implementing Direct Authentication with UsernameToken using a Database.
  • Most directory services that store their passwords as hash values still require credential validation to be done using plaintext passwords. Some directory services do not support the ability to store hashed passwords at all without a custom solution. In such cases, you may be able to implement a custom hash to reduce the risk of disclosing the passwords in the event of the directory service’s identity store being compromised by an attacker.

References

  • Securing the Username Token with WSE 2.0 at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/securusernametoken.asp
  • WS-Security at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Implementing Direct Authentication with UsernameToken using Windows User Accounts

This page uses frames, but your browser doesn't support them.


Implementing Direct Authentication with UsernameToken using Windows User Accounts

Context

You are implementing Direct Authentication for an online application consuming a Web Service that uses Web Service Enhancements (WSE) 2.0. You are using Message layer authentication. The credentials, used to prove the identity of the calling application or user, are located in Active Directory or the Local Users identity store on the server.

Implementation Strategy

The WSE implementation of UsernameToken is used to implement Direct Authentication at the message layer. The requestor passes the subject's credentials to the Web service as part of a secure message exchange. A password is sent across the network, sent within the message as plaintext, because Active Directory requires that passwords are provided in plaintext format. The Web service decrypts the message, validates the credentials, verifies the message signature, and sends an encrypted response back to the requestor.

Approach

Two tasks must be performed to implement Direct Authentication with UsernameToken using Windows User Accounts.

1. Requestor generates Web service request.

2. Service authenticates Subject and returns a response.

Each task is divided into specific steps. While you are strongly encouraged to follow the recommendations, the steps contain enough information to allow you to tailor a solution to your specific needs.

Requestor Generates Web Service Request

This task has three steps that are recommended:

1. Initialize the UsernameToken

2. Establish message integrity

3. Encrypt the Message

Each step is discussed in more detail below:

Step One: Initialize UsernameToken

This pattern implements a UsernameToken with the SendPlainText password option, which sends the password over the network as plaintext. The “plaintext” value is the actual password because Active Directory requires plaintext passwords for credential validation. This option, used with the Default implementation of UsernameTokenManager, is similar to Basic Authentication over HTTP and as such should always be accompanied with SSL.

If the subject’s password is being sent in plaintext the session should always be encrypted.

Note: If you are not familiar with UsernameToken, refer to the UsernameToken Primer for more information.

The following code shows how to obtain a reference to the SOAP request context, initialize a UsernameToken and add it to the security tokens collection of the request context:

// obtain SOAP request context from Web service proxy

SoapContext requestContext = serviceProxy.RequestSoapContext;

UsernameToken token = new UsernameToken( txtUsername.Text, password, PasswordOption.SendPlainText );

requestContext.Security.Tokens.Add( token );

Step Two: Establish Message Integrity

An XML signature could be created to sign the request message to provide data integrity implicitly using Data Origin Authentication, but in this pattern, an XML signature is of no value. This is because the password used as the signing key must be included in the message. An attacker could tamper with the message and then create a new signature using the password as the signing key.

As the XML signature cannot be used to provide Data Origin Authentication, another approach must be used. In many cases, full DOA is not required, only data integrity. However, two approaches are available that can provide DOA to the requester (though not to the subject). These are:

  • HTTPS
  • WSE 2.0 using X509SecurityToken

HTTPS provides data confidentiality and data integrity when server certificates are used. If you require DOA to the requestor, you should also use a client certificate for the requestor. For more information, see Pattlet –Transport Layer Security using X.509 Certificates and HTTPS.

WSE 2.0 using X509SecurityToken only provides confidentiality without data integrity when server certificates are used. If you require DOA to the requestor, you should also implement client certificates. For more information, see Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

Step Three: Encrypt the Message

You should encrypt the message from the requestor to the service to ensure that only the intended recipient of the message is capable of processing it. The same method chosen to provide DOA in the previous step should be used for Data Encryption.

HTTPS encrypts the request message from the Requestor so that only the Service can decrypt it. For details on implementing HTTPS, see “Pattlet –Transport Layer Security using X.509 Certificates and HTTPS”.

WSE 2.0 using X509SecurityToken uses the server’s X.509 certificate to encrypt the request message. Unlike SSL, parts of the message may be encrypted rather than the entire communication at the transport layer. For more information on implementing the alternate approach to SSL with message layer X.509 security, see Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

If message layer X.509 encryption is being used, then code must be implemented to encrypt the message. For more information, and code examples that demonstrate how to encrypt the message, see Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

Choosing Between HTTPS and WSE 2.0 using X509SecurityToken

When you implement Direct Authentication with UsernameToken using a Directory Service, you will need to ensure that you provide Data Confidentiality, and possibly DOA to the requestor.

HTTPSis a well-established protocol and is easy to implement on the Windows platform, requiring no additional code. However, there are circumstances when HTTPS is not an appropriate choice. If you need to persist messages, or if the messages must be handled by intermediaries, then you should use WSE 2.0 using X.509SecurityToken. Unlike HTTPS, parts of the message may be encrypted at the message layer, rather than the entire communication at the transport layer.

Service Authenticates Subject and Returns a Response

This task has four steps that are recommended:

1. Decrypt the request message

2. Verify message integrity

3. Validate the password

4. Encrypt the response

Each step is discussed in more detail below:

Step One: Decrypt the request message

The option chosen to encrypt the request message determines how the request message is decrypted by the Service. Both SSL and WSE 2.0 will encrypt the request message automatically, and require no additional coding.

Step Two: Verify Message Integrity

The method used when message integrity was established by the Requestor also defines the method used by the Service to verify message integrity. Both SSL and WSE (using an Integrity policy assertion) verify the message integrity automatically, and require no additional coding.

Step Three: UsernameToken manager validates password

Once the message is received by the service the information in UsernameToken is verified by WSE using the UsernameTokenManager class. The AuthenticateToken method of the UsernameTokenManager class, is used by WSE to validate the information in the UsernameToken.

Note: WSE 2.0 uses the UsernameTokenManager class to validate credentials presented in a UsernameToken by calling the winlogon API function. In Windows XP and Windows 2000, the service account, under which the web application validating the credentials is running, can only call the winlogon API if it has Log on Locally permissions to the server hosting the service.

The return value of AuthenticateToken is a password. This is used by WSE to verify the UsernameToken information by comparing it to the password that was sent in the message. The default UsernameTokenManager also establishes a WindowsPrincipal instance for the authenticated Subject and attaches it to the token’s Principal property.

Step Four: Encrypt the Response

The method used to encrypt the request message, is also used to encrypt the response message is encrypted by the Service. Both SSL and WSE 2.0 will encrypt the message response automatically, and require no additional coding.

Resulting Context

A number of benefits, liabilities, and security considerations are associated with this implementation of Direct Authentication, and are detailed in this section.

Benefits

WSE 2.0 authentication occurs against a Windows domain controller by default, without the need for Integrated Security on a Web server.

By using the existing Active Directory Infrastructure, you can minimize extra costs in establishing and migrating to a new authentication infrastructure. You also avoid having to synchronize Active Directory with another Identity Provider.

Liabilities

UsernameTokens in WSE prevent replay attacks under the covers by using a nonce and timestamp with a replay cache on the server. However, the replay cache is not shared across a server farm. Approaches to mitigate this issue include:

  • Configuring a network load balancing device to allow session affinity, so that calling applications communicate with the same Web service throughout the duration of a session or replay cache lifetime. This is a relatively simple solution to the problem but sacrifices system availability. If the server hosting the Web service goes offline during a session, any state maintained by the Web service will be dropped, forcing the client to re-establish state on the server farm with a different server.
  • Creating a common server-side state mechanism such as a central database cache to share the replay cache information across the server farm. While this solution minimally impacts availability of the server farm to calling applications, it is a more complex solution to implement, requiring extension of existing WSE classes to use the common state mechanism. One of the inherent problems with centralized state mechanisms is performance—since the state mechanism is farther away from the code implementation, it may affect performance. A database state mechanism is durable and sharable across multiple servers, but it is also much slower than an in-memory cache used by each server maintaining its own state.

Security Considerations

The following subjects represent security aspects that should be considered when using this implementation of Direct Authentication.

  • The password in a UsernameToken should always be encrypted, using either message layer security, or transport layer security such as SSL. This mitigates the threat of an offline guessing attack against the UsernameToken.
  • If SSL is implemented between several intermediaries providing point-to-point security, the environment is vulnerable to man-in-the-middle and XML attacks.

While passwords are considered one of the weakest forms of identity used for proof of possession, they are also the most common. As a result, it's important to understand threats and vulnerabilities associated with passwords.

  • Passwords are often based on words and phrases that can be remembered, making it easier to discover passwords through the use of brute force attacks that try thousands of common passwords and word combinations. This vulnerability can be mitigated by using complex passwords or password phrases, although user passwords should still be memorable, or they are likely to be written down.

References

  • Securing the Username Token with WSE 2.0 at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/securusernametoken.asp
  • WS-Security at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Brokered Authentication

This page uses frames, but your browser doesn't support them.


Brokered Authentication

Context

An online application needs to access one or more Web services. The Web service requires that the application presents credentials for authentication, so that additional controls such as authorization and auditing can be implemented.

Problem

How does the Web service verify the credentials presented by the requesting application?

Forces

● An organization requires online applications and Web services to share a standard access control infrastructure - The organization can simplify the development of new Web services by standardizing and centralizing the issuance and verification of credentials. You can also centralize the management of subject data associated with credentials, reducing the costs associated with identity management.

● An online application must access multiple services, resulting in the need for a Single Sign-On solution. Without a single sign on solution the online application may be forced to authenticate the user prior to every Web service call, or cache the user's credentials within the application. If the user's credentials include a password then caching the password is not recommended, because it may pose a security risk.

● The online application and the Web service do not have a direct relationship. The online application and the Web service may not trust one another to manage or exchange shared secrets securely.

● The Web service and the Identity Provider do not have a direct relationship - The Web service may be unable to communicate with the identity provider directly, due to access control restrictions, or network restrictions, or organizational policy.

Solution

Use Brokered authentication, where the Web service validates the credentials presented by the online application, without the need for a direct relationship between the two parties. An authentication broker, that both parties trust independently, issues a proof of authentication token to the online application. The online application can then present credentials, including the proof of authentication token to the Web service.

Security Concepts

Proof-of-possession is a value that a subject presents to demonstrate knowledge of a shared secret in order to prove his/her identity. Proof-of-possession can be the actual shared secret, such as a user's password, or a password equivalent, which can be created in a number of ways, including the following:

● [image] A digest of the shared secret, which is typically created using a hash of the shared secret and a salt value

● A signature for the message that was generated with the shared secret.

For more information on the use of proof of possession, see Direct Authentication.

Proof-of-authentication is verifiable proof that a subject has successfully authenticated with an authentication broker. Proof of authentication takes the form of a token that is issued by the authentication broker and can be presented to another party that trusts the authentication broker.

Participants

  • Subject - A user, application, or computer that needs to be authenticated with the Web service.
  • Requestor – the online application needing to access the Web service. The Requestor acts on the subjects behalf, providing the Subject's credentials for authentication during the request to the Web service. In some cases the Subject and the Requestor may be the same application.
  • Service - The Web service that requires authentication of a Subject prior in order to making access control decisions
  • Authentication Broker - Authenticates subjects and maintains authoritative control over security tokens. Vouches for the subject by issuing a security token to the Requestor.
  • Identity Provider – Has authoritative control over a Subject's unique identifier and proof of identity for a given Identity Domain (such as Active Directory).

The relationship between the participants is shown in Figure 1. The shaded areas of the diagram represent the trust relationships between parties:

Figure 1

Relationship between participants.

Process

Figure 2 depicts the interactions performed during Brokered Authentication.

Figure 2

Brokered Authentication Process.

The steps in this process are described below:

1. The Requestor submits an authentication request to the Authentication Broker

2. The Authentication Broker contacts the Identity Provider, which validates the subject's credentials against its identity store, and returns a response to the Authentication Broker

3. The Authentication Broker responds to the Requestor, and, if authentication was successful, issues a proof of authentication token, that the requestor can use to authenticate with the service. The proof of authentication token can be used by the requestor for a period of time defined by the authentication broker. The requestor can then use the issued security token to authenticate requests to the service, throughout the lifetime of the token.

4. A Request message is sent to the service, containing the security token issued by the Authentication Broker.

5. The Service authenticates the request by validating the Security Token that was sent with the message. It may validate the Security Token by checking against locally persisted information, or by calling the Authentication Broker directly.

6. The Service returns the response to the Requestor.

There are different types of Authentication Brokers, each utilizing different mechanisms for brokering authentication between a requestor and a service. Common examples of Authentication Broker include:

  • X509 PKI
  • Kerberos
  • Web Service Security Token Service (STS)

Resulting Context

The following benefits, liabilities, and security considerations are associated with the use of Brokered Authentication.

Benefits

● The Authentication Broker manages trust centrally, eliminating the need for each requestor and service to independently manage their own trust relationships, as shown in Figure 3:

Figure 3

An Authentication Broker managing trust centrally.

  • Solutions built around brokered authentication with a centralized identity provider are often easier to maintain than Direct Authentication solutions. When new subjects requiring access to any of the online applications or Web services are added to the identity store, their credentials are maintained in one central point.
  • Two parties partcipating in Brokered Authentication do not require prior knowledge of one another in order to communicate. If an online application is modified to call a Web service it has never used before, the Web service requires no changes to its configuration or data in order to authenticate credentials presented by the online application.

Liabilities

  • The centralized trust model used by Brokered Authentication can sometimes create a single point of failure. Some types of authentication brokers, such as a Kerberos KDC, must be online and available to issue a security token to a requestor. If the Authentication Broker somehow becomes unavailable, none of the parties that rely on the Authentication Broker to issue security tokens can communicate with each other. This problem of a single point of failure can be mitigated by implementing redundant or back-up Authentication Brokers, although this increases the complexity of the solution.
  • Services that directly validate proof of authentication with the issuing Authentication Broker may be susceptible to performance bottlenecks.

Security Considerations

  • Proof-of-authentication tokens must be signed by the issuing Authentication Broker or else their integrity cannot be verified. This could result in attackers trying to issue false tokens.
  • A Time Of Change/Time Of Use vulnerability may exist if the Subject’s account status, identity attributes, or authorization attributes are modified by the Subject’s Identity Provider. If these changes are not reflected by the Proof-of-Authentication Token, it creates a vulnerability that may lead to invalid Subjects interacting with the Service with elevated privileges.

Related Patterns

There are three different types of patterns associated with Brokered Authentication: child patterns, alternate patterns and additional patterns.

Child Patterns

Brokered Authentication – X509 PKI

Brokered Authentication – Kerberos

Alternate Patterns

Direct Authentication

Additional Patterns

Broker

References

Kaufman, C., Perlman, R., and Speciner, M. Network Security – PRIVATE Communication in a PUBLIC World. Upper Saddle River, NJ: Prentice Hall PTR., 2002.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Brokered Authentication - X.509 PKI

This page uses frames, but your browser doesn't support them.


Brokered Authentication – X.509 PKI

Context

An online application needs to access one or more Web services. The Web service requires that the application presents proof of authentication, so that additional controls such as authorization and auditing can be implemented. The organization needs to use an Authentication Broker to issue signed security tokens that can be used for authentication.

Problem

How does the Web service verify the credentials presented by the requesting application?

Forces

  • Authentication must be portable across organizational boundaries. The authentication broker must issue security tokens that can traverse security domains and other organizational boundaries.
  • Authentication cannot use shared secrets. The environment may not be sufficiently trusted for exchange of shared secrets between subjects and the Identity provider, or the overhead of managing distribution of shared secrets may be considered too high.
  • The online application and the Web service must be able to validate authentication credentials when the Authentication Broker is offline or unavailable. The Web service must be able to obtain information used for credential validation from the identity provider out-of-band, ensuring that the Web service can continue to process requests if the Authentication Broker becomes unavailable.
  • Authentication must be based on industry standards and extensively implemented on a variety of platforms. Adopting a standards-based mechanism for authentication reduces interoperability issues, and ensures that the authentication mechanism will be widely scrutinized to mitigate security vulnerabilities.
  • The Authentication mechanism must provide support for non-repudiation. The organization requires a mechanism that can be used to attribute the identity of a particular party to a specific action or data change. The mechanism must ensure that others are not capable of performing an action or making a data change and making it appear as though another party had performed it.

Solution

Use Brokered Authentication with X.509 certificates issued by a Certificate Authority (CA) in a Public Key Infrastructure (PKI) to verify the credentials presented by the requesting application.

The client application attaches credentials (or a reference to the credentials) to the request message and digitally signs the message using the subject's private key. When a service receives the message it uses the public key, included with the X.509 certificate, to validate the signature. Additional validation may also be required to ensure that the X.509 certificate was issued by a CA that the service trusts.

Participants

  • Certificate Authority (CA) – Authentication Broker that is responsible for authenticating Subjects and issuing valid X.509 certificates.
  • Certificate Repository – Location where X.509 certificates are stored.
  • Subject - A user, application, or computer that needs to be authenticated with the Web service.
  • Requestor – The online application needing to access the Web service. The Requestor acts on the subject's behalf, providing the Subject's credentials for authentication during the request to the Web service. In some cases the Subject and the Requestor may be the same application.
  • Service - The Web service that requires authentication of a Subject prior in order to making access control decisions.

Process

A mutually trusted Certificate Authority must issue an X.509 certificate before brokered authentication using an X.509 can complete. There are several options that can be used to obtain an X.509 certificate:

  • Purchase an X.509 certificate from a public Certificate Authority.
  • Configure a public key infrastructure (PKI) server, such as Windows Certificate Services, to create an X.509 certificate and then use the PKI Certificate Authority to sign the certificate.
  • Create a self-signed certificate using a tool such as MakeCert (this is not suitable for production purposes).

Once an X.509 certificate has been issued, local repositories, such as a machine certificate store, are used to store information about the X.509 certificate. The actual process of issuing and distributing X.509 certificates is beyond the scope of this pattern. For detailed information see X.509 Security Primer .

The process of using an X.509 certificate for authentication is shown in Figure 1.

Figure 1

Authentication using an X.509 Certificate

1. The Requestor attaches the Subject’s credentials to the request message. The request message is signed with the private key that is paired with the public key in the Subject’s X.509 certificate. The Requestor can also attach the subject’s X.509 Certificate to the message, if the Service does not store or have access to the X.509 certificates out-of-band. If the X.509 Certificate is not attached, the Requestor instead attaches information to the request message, so that the Service may retrieve the Subject’s X.509 certificate from a certificate repository to verify the message signature.

2. Requestor sends the message to the Service.

3. Service authenticates the Subject by performing the following steps:

3.1. Verifying the issuing CA of the subject’s X.509 certificate. This is done by verifying the issuer signature on the Subject’s X.509 certificate against the issuing CA’s X.509 certificate. In order for this step to be of any value to either party, the CA that issued the Subject’s X.509 certificate must be trusted by both the Requestor and Service.

3.2. The X.509 Certificate is checked to see if it valid. An X.509 certificate is considered to be valid if the issuing CA has not revoked it. The Service checks to see if an X.509 certificate is valid by making sure that the X.509 certificate does not appear on a Certificate Revocation List (CRL) published by the issuing CA.) The Service can check the CRL by directly accessing it from the CA or by checking against a CRL that was downloaded out-of-band from the issuing CA to the certificate repository used by the Service to look up X.509 Certificates.

3.3. Verifying the Subject's signature by using the public key in the Subject’s X.509 certificate. This enables the Service not only to authenticate the Subject, but to ensure that the signed data has not been tampered with after the message was signed.

Note: Checking the validity of the X.509 certificate is optional, however it is highly recommended. For more information on X.509 certificate revocation, see X.509 Security Primer.

4. The Service may send a response back to the Requestor (a response is not always required).

One of the strong points of Brokered Authentication is the ability for a Service to authenticate a Subject even though it has no prior relationship through the Authentication Broker. However, in some cases a Service must be able to authorize subjects based on their identity. The Service must be able to either recognize the Subject individually or verify that the Subject belongs to a limited population of Subjects. There are two different ways that the Service can accomplish this:

  • Define a policy that will only allow requests to be processed that are signed by specific X.509 certificates.
  • Verify the Subject’s X.509 certificate against a very restricted trust chain. The trust anchor for the trust chain must be defined for the purpose of defining the population of Subjects from which the Service is allowed to process requests. For more information on X.509 certificate trust chains and trust anchors, see X.509 Security Primer.

Resulting Context

The following benefits, liabilities, and security considerations are associated with the use of the X.509 CA as an Authentication Broker.

Benefits

The following benefits are associated with Brokered Authentication using an X.509 PKI:

  • Authentication can occur over well-known Internet firewall friendly ports using well-known protocols (e.g., HTTP/HTTPS over port 80/443).
  • X.509 Certificates can be used to authenticate subjects and protect messages across organizational boundaries and security domains, because the X.509 certificates are based on a broadly accepted standard.
  • The X.509 CA supports renewal and revocation of X.509 certificates.
    • X.509 certificates may be renewed by an Agent on the Subject's behalf to extend their lifetime. When an X.509 certificate is renewed, a new copy of the certificate is generated with a new expiration date, along with a corresponding new public/private key pair.
    • X.509 certificates may be revoked if any of the Subject's information in the X.509 certificate has changed or if the X.509 certificate's private key has been compromised.
  • X.509 certificates can be distributed openly and used by anyone to encrypt messages to the corresponding subject, or to verify the digital signature of the subject. For more information on protecting confidential data, see the Data Confidentiality pattern.
  • Digital Signatures provide a means of supporting Non-repudiation. This is because access to the private key is usually restricted to the owner of the key, which makes it easier to verify proof-of-ownership. For more information on non-repudiation, see the Data Origin Authentication pattern.
  • Authentication does not require a direct relationship between every requestor and service.

Liabilities

The following liabilities are associated with using Brokered Authentication with an X.509 PKI:

  • Private keys need to be stored somewhere securely (for example on a smart card, or on your computer) and as such are not as portable as passwords. An attacker could use a private key to impersonate the subject, and so you must ensure that the private key is not compromised.
  • The generation and verification of digital signatures using the encryption keys employed in X.509 is computationally intensive and may cause performance and/or scalability issues. If the Requestor sends frequent request messages to the Service during the course of a normal interaction, a means to optimize communication between the two parties (such as Secure Conversation) should be considered.
  • Certificate Authorities do not do service authorization, thus requiring a means external to the CA such as an LDAP directory or AD with certificate mapping enabled to control access to services.
  • The cost of implementing an X.509 PKI should be considered by an organization, as it may require a significant investment in its infrastructure to support an X.509 PKI.The benefits gained from using an X.509 PKI infrastructure must be weighed with the investment required to use it.

Security Considerations

The following Security Considerations should be examined for this pattern:

  • The lifetime of an X.509 certificate is considerably greater than that of other Authentication Broker Proof-of-Authentication Token types. Most Proof-of-Authentication Tokens expire minutes or hours from their time of issue, whereas an X.509 certificate can be valid for several months. It is therefore critical to safeguard the private key associated to the X.509 certificate. If the private key is compromised, the integrity of the corresponding X.509 certificate is violated, because another entity besides the Subject is capable of generating digital signatures representing the Subject's identity. If a private key is compromised, the CA can revoke the X.509 certificate, causing it to become unusable for encryption and digital signatures.
  • Regardless of whether an X.509 certificate is renewed or revoked and a new X.509 certificate is re-issued, the X.509 certificate should use a newly generated public/private key pair. For existing X.509 certificates that are being renewed, this is known as re-keying the X.509 certificate.
  • When used to implement non-repudiation through digital signatures, only one copy of the X.509 certificates private key should exist that is accessible only to the Subject.
  • If private keys are centrally managed for Subjects such as a key escrow, the credibility of digital signatures for non-repudiation may be reduced or nonexistent and the escrow mechanism itself may cause the disclosure all private keys held if it is compromised.

Related Patterns

There are two different types of patterns associated with X.509 PKI Authentication: Child patterns and alternate patterns.

Child Patterns

Implementing Message Layer Security with X.509 Certificates using WSE 2.0 - Composite pattern that focuses on using Brokered Authentication at the message layer with X.509 certificates in WSE 2.0.

Pattlet – Transport Layer Security using X.509 Certificates and HTTPS - Pattlet that provides concise reference on how to use SSL for data confidentiality and data integrity and how to use SSL client certificates for brokered authentication and data origin authentication.

Dependent Pat terns

Brokered Authentication - Architectural pattern that describes how to prove a Subject’s identity to an Authentication Broker for issuance of a security token.

Alternate Patterns

Brokered Authentication - Kerberos – Kerberos provides an alternative to X.509 for brokered authentication.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Implementing Message Layer Security with X.509 Certificates in WSE 2.0

This page uses frames, but your browser doesn't support them.


Implementing Message Layer Security with X.509 Certificates in WSE 2.0

Context

You are implementing Brokered Authentication in an application deployed on a Microsoft Windows platform, with security implemented at the message layer. A Web Service using Web Services Enhancements (WSE) is processing requests from requestors. Requestors and services must use a standards-based security token that is portable across organizations and security boundaries. The solution chosen must be able to provide a complete set of security features, including Mutual Authentication, Data Origin Authentication and Confidentiality.

Implementation Strategy

Use the X509SecurityToken with WSE 2.0 policy to access certificates and use them for signing and encryption. The X509SecurityToken object accesses the subject's private key, which is used to sign the message. The message is then encrypted using the service's public key, found in its X.509 certificate. The service decrypts the message using its private key, and verifies the XML signature using the public key of the subject, which is found in the subjects X.509 certificate, included with the message.

Note:

For an overview of WSE policy, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wse/html/748c1b28-b6b8-483e-97dc-c726ef5a01c5.asp

This pattern assumes that the Service's certificate has already been obtained by the client out of band, so that both the Sender and Recipient can access the certificate from a local certificate store.

Approach

The process section of the "Brokered Authentication - X.509 PKI" pattern describes how a certificate can be used for authentication. The following tasks represent a recommended approach for implementing message layer authentication using X.509 certificates:

  • Initialize and send a message with X.509 certificate information.
  • Authenticate the subject using the X.509 certificate and XML Signature.

Each task is divided into specific steps. While you are strongly encouraged to follow the recommendations, the steps contain enough information to allow you to tailor a solution to your specific needs.

Initialize and Send a Message with X.509 Certificate Information

This task has six steps that are recommended:

1. Retrieve the Service’s certificate.

2. Retrieve the Subject's certificate.

3. Attach the certificate to a message.

4. Sign the message.

5. Encrypt the message.

6. Send the message to the Service.

The steps are summarized in Figure 1 below:

Figure 1

Initializing and sending a message with X.509 certificate information

Each step is discussed in more detail below:

Step One: Retrieve the Service’s certificate

The Requestor needs to access the X.509 certificate of the service to encrypt the request message. The requestor can retrieve the Service's certificate from a local certificate store without the need for code, by using policy. If a confidentiality assertion is defined to use the Service's certificate, WSE policy retrieves the certificate from the certificate store automatically.

You can use either the Key Identifier or the Subject Name to identify the certificate. However, you should avoid using the Subject Name, because a Subject can have several certificates with the same Subject Name. The WSE policy engine will throw an application exception when more than one certificate is found with the same subject name in the certificate store.

Note: Certificate information such as the subject name or KeyIdentifier can be obtained using the WSE X.509 Certificate Tool. You can also use the MMC snap-in to obtain the subject name. However, when a subject name is fully canonicalized, it must be reversed when is specified as a subject name in a WSE policy assertion. For example, a subject name obtained from the MMC Snap-In as “CN=bob, DC=Microsoft, DC=com” must be reversed when specified in policy, to read as “DC=com, DC=Microsoft, CN=bob.” The WSE X.509 Certificate Tool reverses the order automatically.

Step Two: Retrieve the Subject's X.509 certificate and Private Key

The Requestor needs to access the X.509 certificate and private key of the Subject. The private key is to sign the message, while the X.509 certificate is used to provide the public key, which is used to verify the signature at the service. The service account used by the application sending the request must have appropriate rights to access the private key, and is used to sign the message.

Note: The WSE X.509 Certificate Tool can be used to view private key file properties and set access permissions for the service account .

The X.509 certificate is retrieved automatically by the X509SecurityTokenManager class when policy assertions are either being enforced for outbound messages or verified for incoming messages. For more information on accessing the certificate store, see Security Considerations.

The X509SecurityToken object accesses the subject's private key.

Step Three: Attach the Subject's Certificate to the message

Policy is used to sign the message, and so WSE automatically attaches the Subject’s certificate to the request message.

Step Four: Sign the Message

The message is signed using the Subject’s private key. You can choose to sign one or more portions of the message, such as the address header, or the entire message. An XML signature is created using a signature algorithm that computes a checksum from the data to be signed and encrypts the checksum with the private key of the Subject. When the XML signature is validated, the data used to create the signature is also validated, providing Data Origin Authentication.

To use policy assertions in WSE 2.0, the location of a policy cache file must be specified in the application’s configuration file. The following configuration file lines provide an example of specifying a name and location for the application’s policy cache file:

<configuration>

<microsoft.web.services2>

<policy>

<cache name="Configuration/PolicyCache.config" />

</policy>

</microsoft.web.services2>

</configuration>

The example below shows a sample Integrity policy assertion from an application’s policy cache that is used to sign various parts of a request message:

…

<wssp:Integrity wsp:Usage="wsp:Required">

<wssp:TokenInfo>

<wssp:SecurityToken wse:IdentityToken="true">

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>

<wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>

<wssp:Claims>

<wssp:X509Extension OID= "2.5.29.14"MatchType="wssp:Exact">gBfo0147lM6cKnTbbMSuMVvmFY4=</wssp:X509Extension>

</wssp:Claims>

</wssp:SecurityToken>

</wssp:TokenInfo>

<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body() wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From) wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo) wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>

</wssp:Integrity>

<!-MessagePredicate Assertion verifies that all message parts are present on message -->

<wsp:MessagePredicate wsp:Usage="wsp:Required" Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">

wsp:Body() wse:Timestamp()

</wsp:MessagePredicate>

…

Step Five: Encrypt the Message

The entire message or portions of the message can be encrypted using the public key from the Service's X.509 certificate. At a minimum, the XML signature should be encrypted to help protect against offline attacks. The Confidentiality policy assertion in WSE 2.0 only encrypts a message body, and so a custom policy assertion (ConfidentialityEx) must also be used to encrypt the message signature.

When message data is encrypted in WSE using an X509SecurityToken, asymmetric encryption is used to encrypt a one-time symmetric key which in turn is used to encrypt the data. When message data is encrypted using the Service's certificate information the SubjectKeyIdentifier of the certificate is also added to the message by WSE. The Service owns the certificate, and so this is all the information that is necessary for the Service to access the appropriate private key and decrypt the message.

Encrypting the request in this way protects sensitive data, if the requestor is deceived into calling an illegitimate service. As the intended message recipient, only the correct Web service is capable of decrypting the message with its private key.

The following policy example encrypts a message using a Confidentiality assertion and encrypts the message signature using a custom policy assertion:

<wssp:Confidentiality wsp:Usage="wsp:Required">

<wssp:KeyInfo>

<!--The SecurityToken element within the KeyInfo element describes which token type must be used for Encryption.-->

<wssp:SecurityToken>

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>

<wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>

<wssp:Claims>

<wssp:SubjectNameMatchType="wssp:Exact">CN=MySerivce</wssp:SubjectName>

<wssp:X509Extension OID= "2.5.29.14"MatchType="wssp:Exact">4sCW7DkUpO0spxinO6DEUS9fRVk=</wssp:X509Extension>

</wssp:Claims>

</wssp:SecurityToken>

</wssp:KeyInfo>

<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts>

</wssp:Confidentiality>

<wsisa:ConfidentialityEx wsp:Usage="wsp:Required">

<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">

wsp:Signature()

</wssp:MessageParts>

</wsisa:ConfidentialityEx>

A custom policy assertion enforces encryption of signatures, by implementing the IPolicyEnforcer interface, using the Enforce() method. The details of implementing a custom policy assertion are beyond the scope of this document, but an example can be found on the Microsoft Patterns & Practices website:

http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnpag2/html/MSWSIBSP.asp

Step Six: Send the Message to the Service

After the message has been signed and encrypted, it is sent to the Service.

Authenticate the Subject Using the X.509 Certificate and XML Signature

This task has five recommended steps:

1. Verify the Certificate Trust Chain

2. Check the Certificate Revocation Status

3. Decrypt the Message

4. Verify the XML Signature.

5. Initialize and send a response to the requestor

The steps are summarized in Figure 2 below:

Figure 2

Authenticating a subject using an X.509 certificate and digital signature

Step One: Verify the Certificate Trust Chain

WSE 2.0 verifies the trust chain of certificates by default. The setting to control this behavior is controlled by the verifyTrust attribute of the <x509> element in the application’s configuration file, under WSE security.

The following XML example shows WSE 2.0 X.509 security configuration settings in an application configuration file:

<microsoft.web.services2>

<security>

<x509 storeLocation="LocalMachine" verifyTrust="true" />

</security>

</microsoft.web.services2>

WSE must be able to recognize an issuing CA as trusted, to verify the certificate trust chain for a Subject’s X.509 certificate. WSE trusts recognizes an issuing CA as trusted based on the X.509 certificate used to endorse the Subject's certificate. WSE will recognize the issuing CA’s certificate as a trusted root for a certificate chain if the CA’s X.509 certificate is installed into the machine certificate store under the “Trusted Root Certification Authorities” folder.

The high level steps for installing a certificate chain are as follows:

1. Export the certificate chain from the CA. This is dependant on the type of CA used.

2. Import the certificate chain into a local certificate store.

Note: For more information on managing certificates and trust chains, see the X.509 Security Primer.

Step Two: Check the Certificate Revocation Status

While this step is optional it is also strongly recommended. As discussed in the "Brokered Authentication - X.509 PKI" pattern there are two types of checks. One is to validate the certificate itself and the other is to make sure the certificate came from an expected source.

WSE policy checks the revocation status of the certificate by checking if the certificate is on a Certificate Revocation List (CRL) published by the CA. The CRL can be obtained out-of-band by downloading it from a CA and importing it into a local certificate store, where it is accessible from WSE. You can also check the validity of the certificate by accessing the CA directly. However, this approach relies on the CA being online and accessible by the Web service. There is also a performance cost associated with accessing the CA directly on every call, so you should download the CRL instead of accessing it directly from the CA. By default, WSE verifies the revocation status of X.509 certificates.

Note: For more information about CRLs see the X.509 Security Primer.

Step Three : Decrypt the Message

To decrypt messages with WSE you should define a confidentiality assertion in WSE policy for incoming messages that identifies the token used to encrypt the messages, and rejects messages that do not have specific message parts encrypted with the correct token.

When WSE receives a message that has been encrypted WSE policy automatically decrypts the message using the following steps:

1. The Certificate's SubjectKeyIdentifier that was included in the message is used to access the private key of the certificate.

2. The private key is used to decrypt the asymmetrically encrypted, one-time symmetric key, that was sent with the message.

3. The symmetric key is then used to decrypt the message data using a Symmetric decryption algorithm.

The following XML example shows a confidentiality assertion that would be included in Service’s incoming request policy, to require that only messages that have been encrypted using the public key from the specified X.509 certificate will be accepted. The custom policy assertion used by the requestor to encrypt the signature for the request message is also used by the service to decrypt the message signature on incoming messages.

<wssp:Confidentiality wsp:Usage="wsp:Required">

<wssp:KeyInfo>

<!--The SecurityToken element within the KeyInfo element describes which token type must be used for Encryption.-->

<wssp:SecurityToken>

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>

<wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>

<wssp:Claims>

<wssp:SubjectNameMatchType="wssp:Exact">CN=My Service</wssp:SubjectName>

<wssp:X509Extension OID= "2.5.29.14"MatchType="wssp:Exact">4sCW7DkUpO0spxinO6DEUS9fRVk=</wssp:X509Extension>

</wssp:Claims>

</wssp:SecurityToken>

</wssp:KeyInfo>

<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts>

</wssp:Confidentiality>

<wsisa:ConfidentialityEx wsp:Usage="wsp:Required">

<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Signature()

</wssp:MessageParts>

</wsisa:ConfidentialityEx>

Note: Policy alone will not stop someone from sending an unencrypted message. However, it will reject a message at the server if it is not encrypted. A sender can also implement a policy assertion to require outbound messages to be encrypted when a requestor encrypts a request message.

Step Four: Verify the XML Signature

Once the message is received by a Service, the XML signature is verified automatically by WSE policy, which validates it using the public key that was sent with the message. If the message data had been signed this step also validates the origin of that data, providing Data Origin Authentication.

X.509 by itself does not provide a means to establish a security principal for a Subject represented in an X.509 certificate. Unless you intend to accept requests from every holder of a valid X.509 certificate, that can be verified through a trust chain to a trusted root certificate, you must somehow limit the population down to those from whom you would expect to receive messages. There are several approaches that can be used to accomplish this task:

  • Define a policy that will only allow signed messages attributable to specific certificates.
  • Implement code that accesses the signing token and compares attributes of the token with information that uniquely identifies the certificate. The following attributes can be used to identify a certificate:
    • The certificates "Thumbprint", accessible from the GetCertHashString property.
    • The certificate's KeyIdentifier.
  • Examine claims in the signing token to check for information unique to a Subject accessing the Service.

To use policy assertions in an application, you must specify the name and location of the policy cache file that the application will use in the application’s configuration file, as shown in the following code example:

<configuration>

<microsoft.web.services2>

<policy>

<cache name="Configuration/PolicyCache.config"/>

</policy>

</microsoft.web.services2>

</configuration>

The following Integrity assertion requires that an incoming request is signed by a subject identified by their X.509 certificate base 64 Key identifier:

<wssp:Integrity wsp:Usage="wsp:Required">

<wssp:TokenInfo>

<!--The SecurityToken element within the TokenInfo element describes which token type must be used for Signing.-->

<wssp:SecurityToken wse:IdentityToken="true">

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>

<wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>

<wssp:Claims>

<wssp:SubjectNameMatchType="wssp:Exact">CN=My Client</wssp:SubjectName>

<wssp:X509Extension OID= "2.5.29.14"MatchType="wssp:Exact">gBfo0147lM6cKnTbbMSuMVvmFY4=</wssp:X509Extension>

</wssp:Claims>

</wssp:SecurityToken>

</wssp:TokenInfo>

<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body() wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From) wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo) wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>

</wssp:Integrity>

In the above example, the Subject’s X.509 certificate is identified by the integrity policy assertion, using the certificate’s base 64 key identifier specified in the <wssp:X509Extension>element as an Object ID (OID). The X.509 extension that allows use of the Key identifier OID in the above example is the only X.509 extension supported by WSE 2.0 by default. The base 64 key identifier for an X.509 certificate can be obtained using the X.509 Certificate Tool included in the WSE 2.0 SDK.

Step Five: Intialize and send a response to the requestor (optional)

If the Service returns a secure response to the requestor, the same process described in the previous steps is used for the response message between the service and the requestor, with the roles of the requestor and service reversed. The service initiates and sends the response, signing the response with the service’s private key and encrypting with the subject’s X.509 certificate public key. The requestor processes the response in the same manner as the service processed the request, decrypting the response with the subject’s private key and verifying the service’s signature with the service’s X.509 certificate.

Resulting Context

The following benefits, liabilities, and security considerations are associated with the use of the X.509 CA as an Authentication Broker.

Benefits

  • Authentication, data confidentiality and data origin authentication are provided using a single security mechanism.
  • Authentication can occur over well-known Internet firewall friendly ports using well-known protocols (e.g., HTTP/HTTPS over port 80/443).
  • Authentication and message protection can occur across organizational boundaries and security domains, because the private key does not need to be propagated.

Liabilities

  • Private keys need to be stored somewhere securely (for example in a smart card, or on your computer) and as such are not as portable as passwords.
  • The use of asymmetric cryptography is computationally intensive and may cause performance issues, even though WSE optimizes asymmetric cryptography for performance. Most of the time, this issue can be mitigated by deploying servers with more processors or by adding more servers to a load balancing cluster.
  • Signature verification using test certificates generated using the MakeCert utility can cause serious performance issues. Use certificates issued by a Certificate Authority instead to mitigate this issue. For more information on generating certificates, see the X.509 Security Primer.

Security Considerations

  • Web services are susceptible to man-in-the-middle attacks, where an attacker could replace the signature and certificate information. To mitigate this attack, the Service must be able to limit the population of potential requestors to a trusted group, either individually based on the Subject’s X.509 certificate or as a group through a limited population of Subjects, defined by a certificate trust chain. For more information on X.509 authorization and trust chains, see the X.509 Security Primer.
  • Access to the Certificate Store. The WSE X509CertificateStore class provides operations that can be used to open a certificate store and retrieve certificates. You should ensure that the identity of the process accessing the certificate store has appropriate rights to access the private key files used for decryption and signing. For more information on managing certificates see the X.509 Security Primer.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Brokered Authentication – Kerberos

This page uses frames, but your browser doesn't support them.


Brokered Authentication – Kerberos

Context

An online application needs access to one or more Web services. The Web services require that the application presents proof of authentication, so that additional controls such as authorization and auditing can be implemented. The organization needs to use an Authentication Broker to issue security tokens that can be used for authentication.

Problem

How does the Web service verify the credentials presented by the requesting application?

Forces

  • The organization must implement Enterprise Single Sign on capabilities. Enterprise users must be able to access multiple online applications that call Web services, without needing to enter their username and login several times.
  • C entralized authentication of Subjects is required. Users and applications must be able to access multiple resources using a single set of credentials per user or application.
  • The authentication mechanism must be closely integrated with the Operating System. An application may be designed to take advantage of some of the extended capabilities associated with the Windows implementation of Kerberos, such as impersonation, and integration with Active Directory.
  • A uthentication must be based on industry standards and widely implemented on a variety of platforms. Interoperability may be required between different platforms that are capable of using a standard authentication mechanism.
  • Authentication must take place in an untrusted Network environment You may not be able to guarantee the security of the computers on the network. or of the network itself.

Solution

Use the Kerberos protocol to broker authentication between online applications and Web services. The requestor first authenticates the subject with the Kerberos Authentication Service, which issues a Ticket Granting Ticket (TGT). The TGT is used for all requests by the requestor to the Ticket Granting Service (TGS). The requestor can then use the TGT to obtain a service granting ticket (SGT) from the TGS. The request message and SGT are sent to the Service Host. The Service Host receives the message and authenticates the Subject using the SGT.

Participants

  • Requestor – the online application needing to access the Web service. Provides the Subject's credentials for authentication during the service request to the Service.
  • Subject - A user, application, or server that needs to be authenticated prior to accessing a service.
  • Service - The Web service that requires authentication of a Subject prior to making access control decisions.
  • Key distribution center (KDC) - The Authentication Broker responsible for authenticating Subjects and issuing security tokens. One or more KDC's operate in a Kerberos realm, defined by a population of Subjects that share an Identity Provider.
  • Authentication Service (AS) - a component of the KDC responsible for authenticating subjects and issuing a Ticket Granting Ticket (TGT) to be used as proof of authentication. As Kerberos relates back to Trust Broker, a TGT is a type of Proof-of-Authentication Token (For more information, see Security Tokens in the Glossary)
  • Ticket Granting Service (TGS) - a component of the KDC responsible for issuing a Service Granting Ticket (SGT) used to negotiate trust between and authenticate Subject and a resource. Subjects obtain an SGT from the TGS by presenting a valid TGT, obtained from the Authentication Service.

Kerberos is an Authentication protocol that requires the following additional components.

  • Account database – An Identity Store with which the Kerberos KDC checks Subject credentials presented for authentication. For Kerberos operating on a Domain Controller running on Windows Server 2000 or 2003 this function is provided through the use of Active Directory.
  • Kerberos policy - Security policy to restrict user logon restrictions, service ticket lifetimes, user ticket lifetimes, clock synchronization, delegation etc

Process

The process of using Kerberos for authentication is shown in Figure 1.

Figure 1

Requestor Process of Kerberos Authentication

The steps of the authentication process depicted in the above diagram are described below:

1. The Requestor presents the subject's credentials to the KDC's Authenication Service (AS) for authentication. The requestor creates a digest as a password equivalent for the shared secret, to protect it during transmission

2. The Requestor receives a Ticket Granting Ticket (TGT) from the KDC's Authentication service that provides proof that the subject has successfully authenticated (proof of authentication).

3. Requestor sends a message to the Ticket Granting Service (TGS), requesting access to the ServiceHost. The requestor presents the subject's TGT as proof of authentication.

4. The TGS responds to the requestor, returning a Service Granting Ticket (SGT). The SGT is a type of session token that represents that trust has been negotiated between the Subject and Service Host by the KDC.

5. A Request message is sent to service host, along with the SGT.

6. The Service Host verifies that the session token has not been tampered with in transit and was issued by a trusted KDC. If so, then the Service Host allows the request to be processed by the Service

7. The Subject's identity information within the SGT enables the Service Host or Service to establish a security context that will make authorization decisions about the Subject

8. The Service returns a response to the Requestor.

Kerberos follows the basic pattern of Brokered Authentication, but has properties that differentiate it from other types of brokered authentication, including:

  • The Kerberos protocol supports the notion of token renewal; but it does not support token revocation. By default, Kerberos security tokens are of a fixed lifetime of 10 hours and are not renewable, though the token lifetime and the ability to renew tokens are both configurable through Kerberos policy.
  • Kerberos does not typically terminate a security token when an authenticated Subject is finished communicating during a session. Instead, it lets the security token expire at the end of its normal lifetime.

Kerberos can be used for brokering authentication at either the transport or message layer. Some implementations of Kerberos include:

  • Transport-layer Kerberos
    • Windows Integrated Security
    • IPSec
  • Message-layer Kerberos
    • WSE 2.0 KerberosToken2

Resulting Context

The following benefits, liabilities, and security considerations are associated with the use of Kerberos as an Authentication Broker.

Benefits

  • Kerberos provides single on capabilities, requiring a user to authenticate only once per session.
  • Kerberos has broad acceptance as a brokered authentication protocol and is in use in the majority of large organizations that have centralized their authentication management infrastructure.
  • Kerberos is closely integrated with the Microsoft Windows Operating System (Windows 2000 and above). This enables the operating system to provide security capabilities such as user impersonation, authorization and auditing.

Liabilities

  • The centralized nature of Kerberos requires a KDC acting as a Trust Broker to be available at all times. If the KDC fails, Requestors and Services cannot establish new trust relationships, or validate existing trust relationships. You should consider using redundant KDCs or providing an alternative mechanism for authentication, such as X.509 Certificates, if the availability of the Trust Broker cannot be guaranteed. In the Kerberos implementation provided in Active Directory, KDC availability can be improved by establishing secondary domain controllers. This creates a redundant set of Kerberos KDCs.
  • Mutual authentication occurs between the Subject and the Host Service through a trusted session, established by the Kerberos KDC. However, the Host Server does not positively identify itself to the Subject. The subject only knows that the Service Host is a valid object within the Kerberos realm. If the Subject's shared identity secret is ever compromised, a man-in-the-middle attack between the Requestor and KDC is possible.
  • Kerberos does not implement authorization, although it is typically coupled with an Identity Provider that may store role information for a Subject. Resources can control access based on role information obtained from an external directory service from the Subject's unique identifier contained in the SGT.

Note: Active Directory provides authorization services that complement its Kerberos implementation.

  • Kerberos security is only useful for authentication and secure communication. Kerberos is not useful for long term-persistence, due to the limited lifespan of the shared secret.
  • Proof-of-Authentication for a Subject cannot be established outside of the security domain, unless trust is explicitly established with the other security domain attempting to verify the Subject’s Proof-of-Authentication.
  • Each host on the network must have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. The degree of "looseness" can be configured on a per-server basis. If the clocks are synchronized over the network, the clock synchronization protocol must itself be secured from network attackers.

Security Considerations

  • Subjects must keep their secret keys secret. If an intruder somehow steals a Subject's key, it will be able to masquerade as that Subject or impersonate any server to the legitimate Subject.
  • "Password guessing" attacks can occur with Kerberos against messages encrypted with a password equivalent, derived from the user's shared secret. Kerberos uses a derived key created from the subject's password to encrypt data in the authentication request. An attacker could mount an offline dictionary attack by repeatedly attempting to decrypt the data in the authentication request sent to the KDC in order to discover the subject's password.
  • Kerberos cannot be used for non-repudiation, because the Subject's identity secret is shared with the KDC.

Related Patterns

Child Patterns

  • Pattlet – Transport Layer Security using Windows Integrated Security with Kerberos on IIS
  • Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

Alternative Patterns

  • X509 PKI

Dependent Patterns

  • Federation using Kerberos - KerberosCrossRealmTrust - Establishing trust across KerberosRealms (TBD if in scope)

References

  • RFC 1510: The Kerberos Network Authentication Service (V5) at http://www.ietf.org/rfc/rfc1510.txt
  • Kerberos Authentication Technical Reference at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/792ed95d-6f13-4181-a218-e4eaab361c1b.mspx

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Data Confidentiality

This page uses frames, but your browser doesn't support them.


Data Confidentiality

Context

Data passes between an online application and a Web service, sometimes through one or more intermediaries. Messages may also be kept in repositories, such as message queues or databases. Some of the data within the messages is considered to be sensitive in nature. There is a risk that an attacker can gain access to sensitive data, either by eavesdropping on the network or accessing a repository.

Problem

How do you protect data within a message from information disclosure to unintended parties?

Forces

  • B usiness data contains sensitive information that must be protected from unauthorized users. Disclosure of sensitive data could result in loss or damage such as Identity theft, lawsuits, loss of business, or regulatory fines.
  • S ensitive data must be protected from disclosure in transit. An eavesdropper could gain access to sensitive data, whenever it leaves a secure area (such as a protected memory space) or crosses a non-secure communication line (such as a public network).
  • S ensitive data must be protected from disclosure when persisted. Applications may persist data for short periods of time such as in a message queue, or over longer periods of time in a database or a file.

Solution

Use encryption to protect sensitive data contained in a message. Unencrypted data, known as plaintext, is converted to encrypted data, known as ciphertext. Encryption occurs using an algorithm and cryptographic key. Ciphertext is then converted back to plaintext at its destination.

Participants

  • Sender – Originator of a message. An online application can send a request message to a Web service, and a Web service can send a response message back to an application that has sent a request message.
  • Recipient – Entity receiving a message from the sender. A Web service is the recipient of a request message sent by an online application, and an online application is the recipient of a response message it receives from a Web service.

Process

Applying data confidentiality can be broken into two steps:

1. Encrypting the data –Plaintext is rendered unintelligible to parties other than the intended recipient when the sender converts it into ciphertext.

2. Decrypting the data –Ciphertext is rendered intelligible to the intended recipient by converting it back into plaintext.

Two types of cryptography can be used to provide Data Confidentiality - Symmetric and Asymmetric. While both symmetric and asymmetric cryptography follow the same basic process, they each have their own unique characteristics.

Symmetric Cryptography

With symmetric cryptography, both the sender and recipient share a key that is used to perform both encryption and decryption. Symmetric cryptography is commonly used to perform encryption, and to provide data integrity.

Figure 1 shows the process of encrypting and decrypting data with a shared secret key:

Figure 1

The Process of Symmetric Encryption

1. Sender creates ciphertext message by encrypting the plaintext message using a symmetric encryption algorithm and a shared key.

2. Sender sends ciphertext message to recipient.

3. Recipient decrypts ciphertext message back into plaintext with shared key.

There are numerous symmetric algorithms in use. Some of the more common algorithms are RC5, RC6, Rijndael (AES), and Triple DES (3DES). These algorithms are all designed to perform efficiently on common hardware architectures.

Symmetric cryptography is comparatively simple in nature, because the secret key used for both encryption and decryption is shared between the sender and the recipient. However, before communication can occur, the sender and recipient must exchange a shared secret key. In some cases (such as SSL), asymmetric cryptography may be used to ensure that they initial key exchange occurs over a secure channel.

Asymmetric Cryptography

With Asymmetric cryptography (also known as Public Key cryptography) the sender encrypts data with one key, and recipient uses a different key to decrypt ciphertext. The encryption key and its matching decryption key are often referred to as a public/private key pair. As well as providing encryption, Public Key cryptography is commonly used to provide digital signatures, facilitating non-repudiation, and for key management purposes.

The public key of the recipient is used to encrypt data. It can be openly distributed to those wishing to encrypt a message to the recipient. The private key of the recipient is used to decrypt messages, and only the recipient must be able to access it.

Figure 2 demonstrates how asymmetric encryption and decryption take place:

Figure 2

The Process of Asymmetric Encryption

1. Sender creates ciphertext message by encrypting the plaintext message using an asymmetric encryption algorithm and the recipients public key

2. Sender sends ciphertext message to recipient

3. Recipient decrypts ciphertext message back into plaintext using the private key matched with the public key that was used to encrypt the message

There are few asymmetric algorithms in use. The most commonly used asymmetric algorithm is the RSA algorithm.

Asymmetric encryption requires more processing resources than Symmetric encryption. For this reason, asymmetric encryption is often used to exchange a shared key, which is then used for symmetric encryption. This is particularly useful when a sender and recipient need to send multiple messages back and forth within the same session.

Example

A Web service is published by a bank to provide business customers with the ability to upload payroll account transfers. Direct deposit account information is considered very sensitive for both the business customer, as compromise of this information could result in unauthorized account activity or disclosure of employee salary information.

Resulting Context

The following benefits, liabilities and security considerations are associated with the use of Data Confidentiality.

Benefits

Preventing unauthorized parties from viewing messages can prevent financial loss and legal liability, due to disclosure of sensitive information.

Liabilities

  • Cryptography Operations are computationally intensive and impact system resource usage, affecting the scalability and performance of the application.
  • There is an administrative overhead associated with Key management, which safeguards encryption keys from being compromised. Factors that affect the administrative complexity of key management include:
    • The number and type of keys used.
    • The type of encryption used (symmetric or asymmetric).
    • The Key Management Infrastructure in use.

Security Considerations

  • Encryption does not prevent against data tampering. For example, a man-in-the-middle attack can replace the bits on the wire causing the receiver to decrypt the data to something other than the original plaintext. The receiver has no way to verify that decrypted ciphertext is the same as the original plaintext without Data Origin Authentication protection.
  • If a message is being signed and then encrypted care you should ensure that signature within the message is also encrypted, If the signature is not encrypted, it can be the target of a plaintext cryptographic attack.
  • If too much data is encrypted with the same symmetric key, an attacker can intercept several messages and attempt to cryptographically attack the encrypted messages, with the aim of obtaining the symmetric key. To minimize the risk of such an attack, you should consider generating session-based encryption keys with a relatively short lifespan. These session keys are typically derived from a master symmetric key such as a shared identity secret. The session key is normally exchanged using asymmetric encryption, during the initial interaction between a Sender and Recipient. Session keys should be discarded and replaced at regular intervals, based on the amount of data or number of messages that they are used to encrypt.
  • Symmetric encryption algorithms gain much of their strength through the randomness of their encryption keys. If keys originate from a source that is not sufficiently random, attackers may narrow down number of possible values for the encryption key. This can allow a brute force attack to discover the key value from encrypted messages that have been intercepted. For example, if a user password is used as an encryption key, it can be very easy to attack, because user passwords are typically a non-random value of relatively small size, in order to allow a user to remember it without writing it down.
  • You should use published, well-known encryption algorithms that have withstood years of rigorous attacks and scrutiny. Use of encryption algorithms that have not been subjected to rigorous review by trained cryptologists may contain undiscovered flaws that are easily exploited by an attacker.
  • Each country may recognize different standards for data privacy/protection. For example, In the U.S., regulations such as Sarbanes-Oxley, HIPAA, Privacy Act of 1974 require measures to be taken to prevent disclosure of sensitive personal information or require accountability for the management of sensitive data. In the EU, regulations such as the Data Protection Directive enforce stringent standards for data privacy.

Related Patterns

There are three different types of patterns associated with Data Confidentiality: child patterns, dependent patterns, and alternate patterns.

Child Patterns

  • Implementing Message Layer Authentication with UsernameToken in WSE 2.0 - Composite pattern that uses X.509 certificates for data confidentiality
  • Implementing Message Layer Security with KerberosToken2 in WSE 2.0 - Composite pattern that uses Kerberos for data confidentiality
  • Pattlet – Transport Layer Data Confidentiality using HTTPS - Pattlet that provides references for implementing data confidentiality with SSL.
  • Pattlet – Transport Layer Security using X.509 Certificates and HTTPS - Pattlet that provides references for implementing SSL with Transport Layer X.509.

References

  • OASIS Standards and Other Approved Work (including WS-Security) at http://www.oasis-open.org/specs/index.php#wssv1.0

Acknowledgments

Improving Web Application Security: Threats & Countermeasures - Chapter 2 athttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh02.asp?frame=true

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Data Origin Authentication

This page uses frames, but your browser doesn't support them.


Data Origin Authentication

Context

Data passes between an online application and a Web service, sometimes through one or more intermediaries. The data contained in the request message from the online application influences the Web service's behavior. There is a risk that an attacker could manipulate messages in transit between the online application and the Web service to maliciously alter the behavior of the Web service. Message manipulation can take the form of data modification within the message, or even substitution of credentials, to change the apparent source of the request message.

Problem

How do you prevent an attacker from manipulating messages in transit between an online application and a Web service?

Forces

  • The message recipient must verify that an incoming message has not been tampered with. If an attacker alters a message, he or she can make the message recipient behave in an unintended and undesired way.
  • The message recipient must verify that an incoming message originated from the expected sender. If messages are not verified, an attacker can pose as a legitimate sender and send falsified messages.
  • The m essage recipients must prove that the incoming message came from a specific source. If a message originator denies that they have performed a particular action, you must be able to produce evidence that refutes the message originators claim

Solution

Use Data Origin Authentication, enabling the recipient to verify that messages have not been tampered with in transit (Data Integrity) and that they originate from the expected sender (Authenticity).

You can also use Digital Signatures to provide evidence that a subject has performed a particular action related to data, in cases where the subject denies performing the action (non-repudiation).

Note: While digital signatures can be used for Non-repudiation purposes, they may not be sufficient to provide legal proof of Non-repudiation. By itself, a Digital Signature is just a mechanism to capture a subject’s association to data. In cases where data has been digitally signed, the degree to which an individual or organization can be held accountable is established in an agreement between the party requiring digital signatures, and the owner of the digital signature.

Participants

  • Sender – Originator of a message. An online application can send a request message to a Web service, and a Web service can send a response message back to an application that has sent a request message.
  • Recipient – Entity receiving a message from the sender. A Web service is the recipient of a request message sent by an online application, and an online application is the recipient of a response message it receives from a Web service.

Process

Two types of signatures can be used to sign a message: Symmetric and Asymmetric.

Note: The following discussion refers to both XML signatures and digital signatures. XML signatures are used for SOAP message security, using either a symmetric or asymmetric algorithm, whereas digital signatures refer are created explicitly using an asymmetric algorithm, and may or may not be used for SOAP message security.

Symmetric Signatures

A symmetric signature is created by using a shared secret to sign and verify the message. A symmetric signature is commonly known as a Message Authentication Code (MAC). A MAC is created by computing a checksum using the message content and shared secret. A MAC can only be verified by a party that has both the shared secret and the original message content used to create the MAC.

The most common type of MAC is a Hashed Message Authentication Code (HMAC). The HMAC protocol uses a shared secret and a hashing algorithm (such as MD5, SHA-1 or SHA-256) to create the signature, which is added to the message. The message recipient uses the shared secret and the message content to verify the signature, by recreating the HMAC and comparing it to the HMAC sent in the message.

If security is the primary consideration to choose a hashing algorithm for an HMAC, you should use SHA-256 where possible for the hashing algorithm to create an HMAC, as it is the least likely to produce collisions (when two different pieces of data produce the same hash value). If performance is the main consideration, then MD5 is the best choice. SHA1 is currently the most widely adopted algorithm, and so may be required for interoperability reasons.

The shared key and algorithm used to encrypt the hash may depend on the symmetric algorithm used to encrypt sensitive data (see the Data Confidentiality pattern.) When used to create an HMAC, the name of these algorithms are preceded by the term “HMAC” (for example, HMAC SHA-1 or HMAC MD5).

Figure 1 shows the process of using a MAC to sign a message:

Figure 1

Signing a message using a symmetric signature

1. Sender creates a MAC using a shared secret key and attaches it to the message.

2. Sender sends message and MAC to recipient.

3. Recipient Verifies the MAC that was sent with the message using the same shared secret key used to create the MAC.

By signing with a shared secret, both Data Integrity and Data Origin Authenticity are provided for the signed message content. However, symmetric signatures are not normally used to provide non-repudiation, because shared secrets are known by multiple parties. This makes it more difficult to provide evidence that a specific party used the shared secret to sign the message.

Asymmetric Signatures

An asymmetric signature is processed using two different keys, one to create the signature and the other verify it. The two keys are related to one another and are commonly referred to as a public/private key pair. The public key is generally available and can be distributed with the message while the private key is kept secret by the owner and never sent in a message. A signature created and verified using an asymmetric public/private key pair is called a Digital Signature.

The following diagram depicts the process of using asymmetric keys to sign a message:

Figure 2

Signing a message using an asymmetric signature

1. Sender signs message content using the sender’s private key and attaches it to the message.

2. Sender sends message and digital signature to the recipient.

3. Recipient verifies the digital signature using the sender's public key matched with the private key that was used to sign the message.

The most commonly used algorithm to create digital signature is the Digital Signature Algorithm (DSA). DSA uses the public/private key pairs created for use with the RSA algorithm (as described in the Data Confidentiality pattern) to create and verify signatures.

For both signing and encryption purposes, asymmetric keys are often managed through a Public Key Infrastructure (PKI.) X.509 is the most common PKI standard in use. Information describing the subject is bound to their public key through endorsement from a trusted party to form a certificate. Certificates allow a message recipient to verify a signature created by a subject with their private key against the public key in the subject’s certificate. For more information on X.509, see X.509 Security Primer .

Digital signatures are typically used to support requirements for non-repudiation. This is because access to the private key is usually restricted to the owner of the key, which makes it easier to verify proof-of-ownership.

Example

When using message layer authentication it is often necessary to include Data Origin Authentication (DOA) as part of the authentication process. One such example is the use of X.509 certificates to perform message layer authentication. Since X.509 is based on public key cryptography, the type of DOA used would be an asymmetric signature.

For example, a business customer for a bank would sign their payroll transfers using his or her certificate private key. The bank would then verify that the payroll transfer request came from the correct business customer, and that the message had not been tampered with in transit between the business customer and the bank.

Resulting Context

The following benefits, liabilities, and security considerations are associated with the use of Data Origin Authentication.

Benefits

Tampering of message can be detected by the recipient. Also, the origin of the message can be traced to an identifiable source.

Liabilities

  • Cryptographic operations such as data signing and verification are computationally intensive processes that impact system resource usage, affecting the scalability and performance of the application.
  • There is an administrative overhead associated with Key management, which is responsible for maintaining the integrity of keys. Factors that affect the administrative complexity of key management include:
    • The number and type of keys used.
    • The type of cryptography used (symmetric or asymmetric).
    • The Key Management Infrastructure in use.

Security Considerations

  • If a message is being signed you should ensure that signature within the message is encrypted, If the signature is not encrypted, it can be the target of a plaintext cryptographic attack.
  • If too much data is encrypted with the same symmetric key, an attacker can intercept several messages and attempt to cryptographically attack the encrypted messages, with the aim of obtaining the symmetric key. To minimize the risk of such an attack, you should consider generating session-based encryption keys with a relatively short lifespan. These session keys are typically derived from a master symmetric key such as a shared identity secret. The session key is normally exchanged using asymmetric encryption, during the initial interaction between a Sender and Recipient. Session keys should be discarded and replaced at regular intervals, based on the amount of data or number of messages that they are used to encrypt.
  • Symmetric encryption algorithms gain much of their strength through the randomness of their encryption keys. If keys originate from a source that is not sufficiently random, attackers may narrow down number of possible values for the encryption key. This can allow a brute force attack to discover the key value from encrypted messages that have been intercepted. For example, if a user password is used as an encryption key, it can be very easy to attack, because user passwords are typically a non-random value of relatively small size, in order to allow a user to remember it without writing it down.
  • You should use published, well-known encryption algorithms that have withstood years of rigorous attacks and scrutiny. Use of encryption algorithms that have not been subjected to rigorous review by trained cryptologists may contain undiscovered flaws that are easily exploited by an attacker.

Related Patterns

There are three different types of patterns associated with Data Origin Authentication: child patterns, dependent patterns, and alternate patterns.

Child Patterns

  • Implementing Message Layer Authentication with UsernameToken in WSE 2.0 - Composite pattern that uses X.509 certificates for Data Origin Authentication
  • Implementing Message Layer Security with KerberosToken2 in WSE 2.0 - Composite pattern that uses Kerberos for Data Origin Authentication

References

  • RFC 2104 - HMAC: Keyed Hashing for Message Authentication at http://www.ietf.org/rfc/rfc2104.txt?number=2104
  • OASIS Standards and Other Approved Work (including WS-Security) at http://www.oasis-open.org/specs/index.php#wssv1.0
  • WS-I BSP Security Challenges: Threats and Countermeasures

Acknowledgments

Improving Web Application Security: Threats & Countermeasures - Chapter 2 athttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh02.asp?frame=true

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Security Terminology Primer

This page uses frames, but your browser doesn't support them.


Security Terminology Primer

The purpose of this topic is to provide a brief introduction to security terminology and its use when describing security scenarios and patterns. Below is a simple scenario to provide some context for the terminology we will explain:

Scenario

An e-commerce application allows a user to log on and view their order status. The order status information is provided from a Web service which is called by the presentation tier. The Web service requires the online to authenticate using a user’s credentials whenever the online application makes a request obtain that user’s order status.

● The publisher of the e-commerce application has chosen to use direct authentication with a database for a simple solution that is optimizes to allow users to sign themselves up and update their own information

● A requestor, in this case the presentation tier provides credentials that contain information about the subject that the Web service can use for authentication. The subject being authenticated by the Web service is the user.

● The credentials contain an identifier for the subject that is unique to the Identity Provider (for example a user login) and a password to provide proof-of-possession.

● The service verifies the subject’s identifier and proof-of-possession against an identity provider. In this case, the identity provider uses a database to store login and password information.

Terminology

● Subject – A user, computer or application that needs to be authenticated to access an application.

● Identity Provider – Entity that maintains authoritative control over identity information of subjects (login ID’s, passwords, etc.) used for authentication.

● Service – Web service requiring authentication.

● Requestor – Application that consumes a Web service.

● Credentials – Set of claims used to prove the identity of a subject. Contains an identifier for the subject and a proof of the subject’s identity such as a password.

● Proof-of-possession is a value that a subject presents to demonstrate knowledge of a shared secret in order to prove his/her identity. Proof-of-possession can be the actual shared secret, such as a user's cleartext password, or a password equivalent, which can be created in a number of ways, including the following:

● A digest of the shared secret, which is typically created using a hash of the shared secret and a salt value.

● A signature for the message that was generated with the shared secret.

● Direct Authentication – Type of authentication where the service validates credentials containing an identifier and proof-of-possession directly with an identity provider.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


X.509 Security Primer

This page uses frames, but your browser doesn't support them.


X.509 Security Primer

The X.509 specification defines a standard for managing public keys through a Public Key Infrastructure (PKI). Public keys are maintained in X.509 certificates, which are digital documents that bind a subject’s identity claims to a public key from a public/private asymmetric key pair. Identity claims are normally understandable by humans, such as a person’s full name or email address, or a machine host name or domain name. X.509 certificates are endorsed and issued by a trusted third party known as a Certificate Authority (CA).

See the following topics for more information:

  • Public Key Encryption and Digital Signatures
  • X.509 Certificates
  • X.509 Application
  • Certificate Authorities

Use of X.509 Certificates in Patterns

The use of X.509 certificates for third party authentication, data origin authentication, and data confidentiality is described in the following Web service security pattern documents:

  • Brokered Authentication - X.509 PKI
  • Implementing Message Layer Security with X.509 Certificates in WSE 2.0.
  • Pattlet – Transport Layer Security with X.509 Certificates and HTTPS

References

http://www.rsasecurity.com/rsalabs/node.asp?id=2277

http://www.rsasecurity.com/rsalabs/node.asp?id=2293

http://www.oasis-open.org/specs/index.php#wssv1.0

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/operations/ipsec.mspx

Kaufman, C., Perlman, R., and Speciner, M. Network Security – PRIVATE Communication in a PUBLIC World. Upper Saddle River, NJ: Prentice Hall PTR., 2002.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Public Key Encryption and Digital Signatures

This page uses frames, but your browser doesn't support them.


Public Key Encryption and Digital Signatures

Public key encryption, also known as asymmetric encryption, is based on a public/private key pair – where the keys are mathematically linked, so that data encrypted with the public key can only be decrypted with the corresponding private key. X509 certificates use Public-Key encryption as an alternative to shared secrets (which are discussed in the Direct Trust pattern).

With Public Key encryption the sender converts the plaintext message into ciphertext by encrypting it with the public key in the message recipient’s X.509 certificate. The message recipient converts the ciphertext back into the plaintext message by decrypting it using the corresponding private key.

The diagram below demonstrates how Public Key encryption and decryption take place:

Figure 1

Public Key data encryption and decryption

By using Public Key encryption, a message sender has assurance that by encrypting the message with the recipient’s public key that only the recipient will be able to read the message.

While the public key can be distributed openly for use by a service authenticating a requestor, the private key in a key pair should be carefully guarded by the Subject, as it is used to prove the subject's identity.

As well as providing data confidentiality through encryption, the public key in the X.509 certificate can also be used to verify digital signatures created by a message sender. In this case, the private key of the message sender is used to create the digital signature, and the corresponding public key, found in the sender's X.509 certificate is used to verify the signature. Digital signatures are used assure the message recipient that the message originated from the identified sender and that the message contents have not been altered since they were signed by the sender.

Note: With Digital Signatures using Public Keys, the origin of the signed message can be traced to one party (either the requestor or the service). This differs from symmetric key protocols such as Kerberos, where a message can have been signed by either party.

Figure 2 shows the process of using public keys to sign a message:

Figure 2

Creation and verification of a digitial signature

For a more detailed description of data confidentiality, see the Data Confidentiality pattern. For more details on Digital Signatures, see the Data Origin Authentication pattern.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


X.509 Certificates

This page uses frames, but your browser doesn't support them.


X.509 Certificates

X.509 certificates contain several required and optional attributes that enable the identification of the subject. The following list of attributes can be contained in an X.509 certificate:

  • Version number: Certificate version (see Note below)
  • Serial number: Unique identifier
  • Signature algorithm ID: Algorithm used to create the digital signature
  • Issuer name: Name of the certificate issuer
  • Validity period: Period during which the certificate is valid. This is typically set to be around one year.
  • Subject name: Name of the Subject represented by the certificate. The subject of a certificate is typically a person, an organization or a web/application server.
  • Subject public key information: Public key, algorithm
  • Issuer unique identifier: Identifier for the Issuer
  • Subject unique identifier: Identifier for the subject
  • Extensions: Extensions that can be used to store additional information (KeyUsage, AlternativeNames, etc.)
  • Signed hash of the certificate data: hash of the above fields encrypted using the issuer’s private key, resulting in a digital signature

Note: Different versions (version 1, 2, or 3) of X.509 certificates that have evolved over time to provide additional security and attributes bound to the certificate. In practice, only version 3 certificates should now be used.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


X.509 Application

This page uses frames, but your browser doesn't support them.


X.509 Application

X.509 security can be implemented at different layers of network or application infrastructure and each implementation had its own advantages and disadvantages:

Secure Sockets Layer (SSL)

SSL is a secure handshake protocol that uses X.509 certificates at the transport layer. It enables two parties to establish a session to communicate securely by providing confidentiality, data integrity and data origin authentication. Some of the advantages of using SSL are:

  • SSL a well-established protocol that is broadly interoperable, easy to configure and use
  • SSL has a performance advantage over message layer security since it is closer to the operating system than the message layer

While SSL has some strong advantages, it does have a few shortfalls:

  • SSL operates point-to-point, which means that messages cannot be persisted in a secure state and SSL-encrypted SOAP messages cannot be processed by intermediaries without first being encrypted.
  • If used in conjunction with WSE 2.0 message layer security mechanisms to provide a complete set of security features, it would be difficult to determine from the message layer that SSL is providing its part of the required security features and vice versa.

WS-Security X.509 Binary Security Token.

At the message layer, X.509 certificates can be used as binary security tokens as per the WS-Security specification to sign and encrypt messages to provide data confidentiality and data origin authentication.

Some primary advantages of using X.509 at the message layer with binary security tokens are:

  • Message layer X.509 security is flexible to provide either point-to-point or end-to-end security, allowing messages to be persisted in a secure state for short periods of time for queue-based processing or for longer periods of time in an archived state.
  • Message layer X.509 provides a high degree of interoperability, providing standards based on the messages as they are sent over the wire rather than focusing on implementation for a particular platform

Message layer also carries with it certain drawbacks:

  • Processing of message layer X.509 security tends to have a greater impact on system performance than X.509 security implemented closer to the hardware.
  • While message layer X.509 security provides a great deal of flexibility, it tends to be more complex to implement than X.509 security at other layers, requiring more knowledge of the underlying protocols, security policy and programming against a Web services security API.

IPSec

IPSec provides a secure tunnel between two machines hosting applications that access resources or communicate with other applications. X.509 can be used in IPSec to authenticate hosts and negotiate a secure session between them. IPSec has some advantages that make it a viable solution for X.509 security:

  • Performance. IPSec benefits from performance since it is close to the hardware layer, as it operates in the protocol stack between the data link and network layers
  • Ease of configuration – IPSec is easy to configure and implement on Windows Server 2003

Much like other X.509 security implementations at other layers, X.509 IPSec has a disadvantage that must be considered:

  • No granularity of security subjects. IPSec policies are implemented based on a host machine rather than a user or an application. X.509 IPSec is effective for providing secure communications between two hosts but not for authenticating user or application subjects to make authorization decisions.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


Certificate Authorities

This page uses frames, but your browser doesn't support them.


Certificate Authorities

Certificate Authorities (CAs) are organizations that verify the identity of a subject (represented in a certificate request) and issue signed X.509 certificates. CAs can be internal or external to an organization and can issue different types of certificates that are for a specific purpose or to confer varying levels of trust.

External CAs are typically commercial entities that provide certificate issuance to customers for a fee. Examples of External CAs include Thawte, VeriSign and RSA.

CAs offer different "grades" of signed certificates for purchase. Some have a nominal fee, and come with minimal requirements to prove the subject's identity. For example, a certificate used to sign emails may be only cost a few dollars and only requires email confirmation to prove that the email address represented by the Subject in the certificate is authentic. By contrast, a certificate used for more trusted activities may cost upwards of a hundred dollars and require a far more rigorous screening process to ensure the subject meets the requirements for the certificate. Parties that wish to use any type of certificate must decide that the criteria to qualify for such a certificate are sufficient for their needs, and that they consider the CA itself to be sufficiently reputable.

Internal CAs such as those provided by Windows Server can simplify certificate management activities, but in this case the trust of the certificate is now based on the organization that issued it. Issued certificates for Subjects within the organization's security domain (usually defined within Active Directory) are typically signed with the organization's root certificate or another other "parent certificate" allowed to sign certificates.

The chain of certificates, from the Subject's certificate to the root certificate used by the CA for signing subject's certificate, is known as a trust chain. A party may decide to trust certificates at any level within the trust chain. This allows them to trust certificates further down the chain, as long as they are able to trace the trust chain back to the level of the certificate they original trusted.

Note: In test environments, you may choose to use certificates that do not have rigorous requirements for proving the identity of the subject. Certificates can be generated and self-signed using the makecert utility, however there are known performance issues when verifying digital signatures using certificates generated by the makecert utility. For more details on the makecert utility, see Certificate Creation Tool (makecert.exe)

Obtaining an X.509 Certificate

Depending on the type of CA, X.509 certificates can be obtained in a variety of ways. For external CAs, certificates are typically obtained for a subject by submitting a Certificate Signing Request (CSR). A CSR contains the subject’s name, public key and algorithm for which the key is used (the vast majority of X.509 certificates you are likely to encounter use RSA for its algorithm).

The public key included in the CSR comes from a public/private key pair generated specifically for use with the requested certificate. As soon as the public/private key pair is generated, the private key should be immediately stored in a secure place such as a machine key store, with access to the key solely restricted to authorized parties. Ideally, the only party able to access the private key file would be the subject represented in the X.509 certificate, although some infrastructures may allow access to the certificate private key by other accounts. When parties other than the subject represented by the X.509 certificate are allowed to access the certificate private key, the ability to support non-repudiation may not be possible. While the public key of the public/private key pair is required for the CSR, the private key should never be sent to the CA under any circumstance.

Internal CAs may also use CSR’s to process X.509 certificate requests; however, since the CA is internal to a specific organization, there can be additional options that reduce the overhead required to process requests and verify subject identities. For example, an internal CA using Windows Certificate Server may enable auto-enrollment, which automates certificate request and issuance for user accounts created within an Active Directory domain.

Figure 1 depicts the process of a Subject requesting and issuing an X.509 certificate involving a CA that processes Certificate Signing Requests:

Figure 1

Requesting and obtaining a certificate from a CA

Certificate Revocation

X.509 certificates can be revoked by the issuing CA if the integrity of the certificate has somehow been compromised. The justification to revoke an issued certificate varies with each CA, but some general causes for certificate revocation include:

  • The private key has been stolen or wrongly disclosed due to improper storage or use. For example when the subject’s private key is attached to an outgoing message instead of their X.509 certificate containing the public key.
  • T he subject represented in the X.509 certificate has breached the trust of the CA that issued the certificate. For example, if information about the subject was intentionally misrepresented to the CA during the process of verifying the subject’s identity.
  • An identity corresponding to a certificate has been removed from an organization that manages an Internal CA. For example a user account is removed from the system, or disabled when the user's employment is terminated.
  • A subject no longer requires the certificate (cessation of operation.) A CA may revoke a certificate if the certificate is no longer required and will not be used by the Subject any more.

X.509 CAs typically publish a list of certificates that have been revoked, based on the CA’s criteria for certificate revocation. These lists are known as Certificate Revocation Lists (CRLs). CRLs are made publicly available, so that a recipient can verify whether or not a certificate used to sign a message is valid. Any message recipient that receives a signed message, should verify that the subject’s certificate has not been revoked, to ensure the integrity of the signatures, based on the expected level of trust associated with the type of certificate.

Certificate Storage and Access

X.509 Certificates can be stored and accessed in a number of ways, including:

  • L ocal repository X.509 certificates may be exchanged out-of-band and stored in a locally accessible repository such as the machine certificate store in Windows. A local repository should only be used if a small number of certificates are required for use by the Requestor or Service.
  • P KI distribution Public Key Infrastructure (PKI) is a platform that allows an organization to centrally manage X.509 certificates required by the organization's Services and Subjects to authenticate and verify digital signatures. Certificates for that organization's Subjects may also be made accessible outside of the organization. An example of a PKI solution would be one included Microsoft Windows Server 2003. For more information, see: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/63e3ba1c-cc23-40b1-9ca2-853869677318.mspx
  • D irect presentation X.509 certificates may be presented to a message recipient by attaching the certificate directly to the message. The recipient may subsequently decide to cache the certificate locally, pass it off to a central repository for storage or simply re-process it when it is attached to a new message.

Certificate Management

There are many issues related to certificate management and this chapter does not attempt to provide complete coverage. One issue that is significant to consider for message layer security is whether distinct certificates should be created for signing and encrypting message layer data.

For message based security, it is considered good practice to use distinct certificates and key pairs for encryption and digital signatures rather than using a single key pair for both. One reason is that the contents of the certificates, as well as policies for issuance, key distribution, revocation, notification of revocation, and key backup are likely to differ depending on the purpose the keys are used for. This is particularly true when signatures are used for longer term authentication and integrity of business documents, rather than merely temporary authentication of a session. Also, if encrypted messages are persisted to disk you may need to decrypt the messages using an archived version of the private key. However, you would not want new digital signatures to be created with this private key.

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


WSE 2.0 UsernameToken Primer

This page uses frames, but your browser doesn't support them.


WSE 2.0 UsernameToken Primer

UsernameToken is a Web Service Security specification used to identify subjects by their username, and optionally authenticate the subject by verifying their proof of possession.

WSE 2.0 Implementation of UsernameToken

In the WSE implementation of UsernameToken, a password is used to establish proof of possession. The password sent in a UsernameToken message can be a cleartext password or a password equivalent, which is a unique representation of a password, typically created by hashing the cleartext password. A password can also be used by a requester to sign the message, which is then verified by a service. When a message is signed, the password used to sign the message is never included in the UsernameToken, as to do so would compromise the signature.

Once the message is received by the service, the AuthenticateToken method of the UsernameTokenManager class is used by WSE to validate the information in the UsernameToken. The AuthenticateToken method returns the password that was used for authentication. This return value is used by WSE to validate the original message. The specific type of validation is based on the password option that was used.

Note: AuthenticateToken can be overridden, allowing UsernameToken to be used in conjunction with custom Identity Providers. WSE 2.0 supports authenticating tokens based on a Windows user account with the password sent as plaintext (see options below). In all other cases a custom UsernameTokenManager is required.

WSE defines three password options used to send a password in the message: SendNone, SendPlainText and SendHashed.

SendNone

This option is used when signing the message with a digital signature. The password is never sent in the SOAP message, but WSE can use the password to sign the SOAP message. A recipient then needs to provide a password to WSE during the signature verification stage. This is accomplished by returning the password used to sign the message from the AuthenticateToken method.

SendPlainText

The password is always sent as plaintext in the SOAP message. This option is recommended only when the UsernameToken is encrypted using a security token or certificate obtained from the target Web service, or when a transport protocol such as SSL is used to connect to the Web service. Otherwise the password could be intercepted and compromised. WSE running on the recipient's computer compares the password in the SOAP message to the one returned from the AuthenticateToken method. If the two values are identical, the password is deemed valid.

SendHashed

The hash of the password is sent in the SOAP message. When a SOAP message is received with a UsernameToken, WSE calls the AuthenticateToken method of a custom UsernameTokenManager class, registered in the configuration file. The AuthenticateToken method returns a password or password equivalent, which WSE creates a hash from. That hash is compared to the one in the SOAP message and if they are identical, the hashed password is deemed valid.

The formula used to calculate the hash is: P_SHA1 ( password, label + nonce + created ) where:

  • Password is either the real password or a password equivalent (for example the hash of the real password) represented as a UTF-8 string.
  • Label is a shared string between sender and receiver, also a UTF-8 string. For the WSE 2.0 Tech Preview, this is the string "WS-Security".
  • Nonce is "Number Once" material, a random sequence of bytes generated from a Cryptographic Random Number Generator (RNG), encoded as Base64.
  • Created is the created time for the token specified in Zulu time using xsd:DateTime format, again encoded as a UTF-8 string.

In addition to verifying the hash, WSE also signs the message with HMAC-SHA1 using 16 bytes of key data from the hash keys.

Note: Although passwords are not sent as plaintext across the wire when the SendHashed option is used, they should be encrypted to prevent offline attacks. The SendHashed option is not recommended, if it results in passwords being stored in plaintext in the database.

References

WSE 2.0 Product Documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wse/html/648af090-3ff0-415a-9967-ce37e8240070.asp

OASIS Standards and Other Approved Work (including WS-Security) at http://www.oasis-open.org/specs/index.php#wssv1.0

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


How to Read Patterns

This page uses frames, but your browser doesn't support them.


How to Read Patterns

What is a Pattern?

A pattern describes a recurring problem that occurs in a given situation and, based on a set of guiding forces called requirements, recommends a solution. Patterns exist at different levels of abstraction including:

● Architecture patterns. Describe how to structure an application at the highest level.

● Design patterns. Describe how to structure subsystems or components within a system.

● Implementation patterns. Describe low-level patterns that are specific to a particular platform. In this case, using the .NET Framework.

For more information, see Pattern – Wikipedia, the free encyclopedia at http://en.wikipedia.org/wiki/Pattern

How to Read a Pattern

A pattern is usually described using the following key elements:

● The Context sets the stage of what artifacts within a problem domain you are working within.

● The Problem is what you want to achieve or deal with within the context.

● The Forces are identified key elements that must be dealt with in the context and affects the problem. Note forces are items that exist within the context.

● The Solution is a way to resolve the forces to solve the problem within a context. When you start looking at how you must deal with those forces – you end up with a resulting context.

● The Name is the simplest label that you can come with that captures what you are trying to achieve in solving the problem.

Characteristics of a Well Written Pattern

What are the characteristics of a well-written pattern? Below is a list that Doug Lea writes on Hillside.net – Writing Checklist. You should consider the following factors when reviewing the Web service security patterns:

● Describes a single kind of problem.

● Describes the context in which the problem occurs.

● Describes the solution as a constructable software entity.

● Describes design steps or rules for constructing the solution.

● Describes the forces leading to the solution.

● Describes evidence that the solution optimally resolves forces.

● Describes details that are allowed to vary, and those that are not.

● Describes at least one actual instance of use.

● Describes evidence of generality across different instances.

● Describes or refers to variants and subpatterns.

● Describes or refers to other patterns that it relies upon.

● Describes or refers to other patterns that rely upon this pattern.

● Relates to other patterns with similar contexts, problems, or solutions.

In addition, the pattern should have a meaningful name.

Engineering View of Using Patterns

The ultimate test of how well a set of patterns work is by using them to engineer a solution. If it is not fairly straight-forward and does not help you to simplify the task of building your system, it most likely is not a well-formed set of patterns.

Figure 1 illustrates the relationships between the group of implementation patterns. The diagram shows the user starting with the context and problem they want to solve. In this case, the problem is dealing with authentication. The final pattern is determined by looking at which forces must be dealt with in our problem context. After selecting the final pattern, note that we can look at various implementations for this pattern.

Figure 1

Authentication Pattern Map

Reference Materials to Existing Microsoft Patterns

Data Patterns

Data Patterns extends previous patterns work by applying it to data problems and showing how to solve them by using SQL Server. These patterns are about the problems faced by those who build the data services in an enterprise class business solution. The guide introduces patterns and why they are important to database designers and administrators, as well as architects and developers. It then presents a catalog of 12 architecture, design, and implementation patterns that are organized to help you locate the right combination of patterns to solve your problem.

Describing the Enterprise Architectural Space

This document presents an organizing table that describes the enterprise architectural space, shows relationships among artifacts in the space, and demonstrates how different roles in your enterprise view enterprise architecture. This document also demonstrates how pattern authors can use the organizing table to organize existing patterns and to identify areas where patterns are not currently documented.

Enterprise Solution Patterns Using Microsoft .NET

Enterprise Solution Patterns Using Microsoft .NET embraces existing work in the patterns community, contributes new patterns, and shows how to implement these patterns in .NET. The guide explains how a pattern documents simple, proven mechanisms, and shows how collections of patterns provide a common language for developers and architects. The guide then presents a catalog of 32 architecture, design, and implementation patterns that are organized to help you locate the right combination of patterns to solve your problem.

Integration Patterns

Integration Patterns explains how patterns were used to design and build a baseline integration architecture within a representative customer scenario called Global Bank The guide includes a catalog of 18 common integration patterns and is organized to help you locate the right combination of patterns to apply to your problem. In addition, the guide introduces a visual model that describes a language of patterns and their relationships.

Testing Software Patterns

Although the software patterns community has created a stir around the construction of pattern languages, testing patterns and pattern languages has been largely neglected. Following Microsoft Solution Framework (MSF) processes, the test team has developed a formal testing methodology and criteria, which are distilled from best practices found in the larger patterns community. This document describes the methodology that the test team developed and applied to the new field of testing software patterns.

For more information, see Microsoft patterns & practices at http://msdn.microsoft.com/practices/patterns/default.aspx

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.


E-mail feedback about these patterns. Web Service Security Patterns
Web Service Security Patterns Documentation