Securing an assertion and encrypting data within the assertion is a critical part of partnership configuration. In a federation environment, key/certificate pairs and standalone certificates serve a number of functions:
The Policy Server Configuration Guide contains overview information and instructions about managing keys and certificates.
You can use SSL server certificates to do the following tasks:
Refer to instructions for enabling SSL for the web server where the CA SiteMinder® Web Agent is installed.
Note: If you enable SSL, it affects all URLs for all services, even the Base URL parameter. This means that all service URLs must begin with https://.
SAML 2.0 Signing Algorithms
For SAML 2.0, you have the option of choosing a signing algorithm for signing tasks. The ability to select an algorithm supports the following use cases:
Signature verification automatically detects which algorithm is in use on a signed document then verifies it. No configuration for signature verification is required.
Each key/certificate pair, client certificate, and trusted certificate in the certificate data store must have a unique alias. The alias is the reference to any private key/certificate pair or single certificate in the certificate store. The certificate data store holds multiple key/certificate pairs and single certificates. In a federated environment there are 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 associated with alias to sign assertions. If no signing alias is configured, the assertion generator uses the key with the following alias to sign assertions:
defaultenterpriseprivatekey
If the assertion generator does not find a default enterprise private key, it uses the first private key in the store to sign assertions.
Important! If you are going to store multiple keys, define the first key that you add with the following alias before adding subsequent keys:
defaultenterpriseprivatekey
A given Policy Server signs or signs and verifies responses. Add keys and certificates for signing and validation to the same certificate data store.
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 system 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, depending on the transaction taking place. 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 verification, 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 CA SiteMinder® Federation Standalone 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.
Enable SSL for the artifact back channel to secure the SSL connection and make back-channel communication secure.
To establish the SSL connection, the relying party has to associate the CA certificate with the signed SSL server certificate. The SSL server certificate secures the SSL connection, while the CA certificate verifies that the SSL server certificate is trusted.
To implement single sign-on using the artifact binding, the relying party sends a request for an assertion to CA SiteMinder® Federation Standalone 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® Federation Standalone 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.
|
Copyright © 2014 CA.
All rights reserved.
|
|