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:

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