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

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.