Key and Certificate Management

Private key/certificate pairs and single certificates for certain  features, such as federation are stored in the certificate data store (CDS). The certificate data store is collocated with the policy store. All Policy Servers that share a common view into the same policy store have access to the same keys, certificates, CDS-configured certificate revocation lists (CRL), and OCSP responders.
sm1252sp1
Private key/certificate pairs and single certificates for certain 
CA Single Sign-On
 features, such as federation are stored in the certificate data store (CDS). The certificate data store is collocated with the policy store. All Policy Servers that share a common view into the same policy store have access to the same keys, certificates, CDS-configured certificate revocation lists (CRL), and OCSP responders.
Contents
2
Certificate and Private Key Usage
Private keys and certificates are required for the following tasks:
  • Federation components use private key/certificate pairs for signing, verification, encryption, and decryption of entire assertions, or specific assertion content.
  • Federation components employ client certificates for back-channel authentication for artifact single sign-on.
  • For establishing SSL connections (SSL server certificates).

The X.509 authentication schemes do not use the certificate data store (CDS) for certificate validation.
SSL server certificates are stored on the web server where they are installed. SSL server certificates are not stored in the certificate data store.
Each key/certificate pair, client certificate, and trusted certificate in the certificate data store must have a unique alias. The alias allows any private key/certificate pair or single certificate in the certificate store can to be uniquely referenced. The certificate data store can store multiple key/certificate pairs and single certificates. In a federated environment, you can have multiple partners. For multiple partners, you can use a different pair for each partner.
If a signing alias is configured for signing assertions, the assertion generator uses the key that is associated with that alias to sign assertions. If no signing alias is configured, the assertion generator uses the key with the
defaultenterpriseprivatekey
alias to sign assertions. If the assertion generator does not find a default enterprise private key, it uses the first private key it finds to sign assertions.
Important!
If you are going to store multiple keys, define the first key that you add with the defaultenterpriseprivatekey alias before adding subsequent keys.
A given Policy Server can sign or sign and verify responses. You can add keys and certificates for signing and validation to the same certificate data store.
You manage the contents of the certificate data store using the Administrative UI.
The following types of key/certificate pairs and single certificates are stored in the certificate data store:
Function
Private Key/Cert Pair
Certificate(public key)
CA Certificates
Client Certificate
Signs assertions, authentication requests, SLO requests and responses
X
 
 
 
Verifies signed assertions, authentication requests, and SLO requests/responses
 
X
 
 
Encrypts assertions, Name ID and attributes
(SAML 2.0 only)
 
X
 
 
Decrypts assertions, Name ID and attributes
(SAML 2.0)
X
 
 
 
Serves as a credential for client certificate authentication of the artifact back channel
 
 
 
X
Validates other certificates and certificate revocation lists
 
 
X
 
Use SSL connections to resolve web services variables
 
 
X
 
 
Signing and Verification Operations
The Policy Server uses a private key/certificate pair for signing and verification tasks. The private key/certificate pair signs the assertion, the assertion response, or authentication request. The specific message that is signed depends on the transaction taking place and the federation profile in use.
Before any signing transaction, the partner signing the assertion sends the certificate (public key) associated with the private key/certificate pair to the partner. This exchange is done as part of an out-of-band communication. The partner uses the certificate to verify the signature.
When a transaction occurs, the asserting party includes the certificate in the assertion, by default. During the verification process, however, the partner uses the certificate that it stores at its site to validate the signature.
For SAML 2.0 single logout, the side that initiates the logout signs the request, and the side receiving the request validates the signature. Conversely, the receiving side signs the SLO response and the initiator validates the response.
Encryption Decryption Operation
For SAML 2.0, you can configure the Policy Server to encrypt an entire assertion, the NameID, or other attributes. If you enable encryption, the asserting party uses the certificate (public key) the relying party sends to encrypt data. Before any transaction, the relying party sends the certificate to the asserting party in an out-of-band exchange. The relying party uses the private key/certificate pair to decrypt the data.
SAML 1.1 and WS-Federation do not support encryption of assertion data.
Certificates for SSL Connections
The Policy Server uses SSL connections in the following ways:
  • For federated communication.
    You can enable SSL for the SAML HTTP-Artifact back channel or for general federated communication. Establishing the SSL connection requires the relying party to associate the CA certificate with the signed SSL server certificate.
    The SSL server certificate secures the SSL connection. The CA certificate verifies that the SSL server certificate is trusted.
  • For ICAS
    You enable an SSL connection to protect the forms credential collector file at the relying party. Import the SSL server certificate from the relying party website into the certificate data store. The server certificate secures the SSL connection.
  • For web services variables.
    You can enable SSL connections for resolving web services variables.
SSL server certificates are stored on the web server where they are installed. SSL server certificates are not stored in the certificate data store.
Certificates To Secure the Artifact Back Channel
To implement single sign-on using the artifact binding, the relying party sends a request for an assertion to
CA Single Sign-On
at the asserting party. The assertion request goes to the Assertion Retrieval Service (SAML 1.1) or the Artifact Resolution Service (SAML 2.0). The retrieval service takes the artifact supplied by the relying party and uses it to retrieve the assertion.
CA Single Sign-On
sends the response back to the relying party over a back channel. The back channel is a secured connection between the asserting and relying party. In contrast, web browser communication occurs over the front channel.
Secure the back channel and the retrieval service from unauthorized access using one of the following authentication methods:
  • Basic
  • Basic over SSL
  • X.509 Client Certificate
    If you use X.509 client certificate as the authentication method, the relying party must provide a client certificate as its credential. This credential lets the replying party gain access to the service at the asserting party that retrieves the assertion.
Consider the following items when choosing an authentication method:
  • Consider using an SSL connection for the back channel. Secure the SSL connection with an SSL server certificate signed by a trusted CA.
    A default set of common root and intermediate CA certificates are shipped with the certificate data store. To use another server certificate signed by a CA, import the CA certificate into the store as a trusted CA certificate.
    Federation uses an SSL-client when processing back channel requests. You can configure the web server at the asserting party to use SSL versions TLSV1_1 and TSLV1_2 with the following ciphers:
    • RSA_With_AES_128_CBC_SHA256
    • RSA_With_AES_256_CBC_SHA256
    These ciphers are supported in both FIPS and non-FIPS mode. The determination whether to use SHA256 is made on the SP server side. Federation has no configuration for selecting the algorithm. Administrators must verify that the server at the asserting party is configured appropriately.
  • If an X.509 client certificate is required to establish a connection, the relying party must have the key/certificate pair or client certificate authentication fails. Verify that the client certificate exists in the certificate data store at the asserting party. When the relying party sends the request for the assertion, the client certificate serves as the relying party credentials to access the retrieval service.
Formats Supported by the Certificate Data Store
The certificate data store supports the following formats:
  • Private keys are supported in the following format and must be DER or PEM encoded:
    • PKCS1
    • PKCS5
    • PKCS8
    • PKCS12
    Only RSA keys are supported.
  • Public certificates are supported in the following X.509 certificate format:
    • V1
    • V2
    • V3
  • Public certificates are supported in the following encoding formats:
    • DER
    • Base64
    • PEM