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.
• The 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.
• The 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:

● 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.