Private keys and certificates are required for the following tasks:
Private key/certificate pairs and single certificates for federation functions 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.
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 |
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 |
|
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.
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.
Note: SAML 1.1 and WS-Federation do not support encryption of assertion data.
The Policy Server uses SSL connections in the following ways:
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.
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.
You can enable SSL connections for resolving web services variables.
Note: SSL server certificates are stored on the web server where they are installed. SSL server certificates are not stored in the certificate data store.
To implement single sign-on using the artifact binding, the relying party sends a request for an assertion to CA SiteMinder® 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 SiteMinder® 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:
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:
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:
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.
The certificate data store supports the following formats:
Only RSA keys are supported.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|