Federation Manager Guide › Keys and Certificates for Secure Federated Communication › Certificate and Private Key Usage for Federation

Certificate and Private Key Usage for Federation

Federation Manager uses private key/certificate pairs for signing, verification, encryption, and decryption of entire assertions, or specific assertion content. Federation Manager also employs client certificates for authenticating a client across a back channel for artifact single sign-on. Finally, Federation Manager uses SSL server certificates for establishing SSL connections.

There can be multiple private key/certificate pairs in the key database. If you have multiple federated partners, you can use a different pair for each partner.

Private key/certificate pairs are stored in the Federation Manager key database. Each key/certificate pair and trusted certificate in the key database must have a unique alias. The alias enables Federation Manager to reference any single certificate or private key/certificate pair in the key database. You manage these keys using the Federation Manager UI.

The following types of keys and certificates are stored in the key database:

Signing and Verification Operations

Federation Manager 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 that signs the assertion sends the certificate (public key) associated with the key/certificate pair to the partner. This exchange is done as part of an out-of-band communication. The partner that verifies the signature uses the certificate sent by the signing partner.

When a transaction occurs, Federation Manager 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 single 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 Operations

For SAML 2.0 you can configure Federation Manager to encrypt an entire assertion, the NameID, or other attributes. If you enable encryption, the asserting party uses the certificate (public key) of the relying party to encrypt data. Before any transaction, the relying party sends the certificate in an out-of-band exchange to the asserting party. The relying party uses the associated private key/certificate pair to decrypt the data.

Note: SAML 1.1 does not support encryption of assertion data.

Enabling SSL Connections

You can enable SSL for the artifact back channel or for general federated communication. To establish the SSL connection, the relying party must have the CA certificate associated with the signed SSL server certificate. The SSL server certificate secures the SSL connection, and the CA certificate verifies that the SSL server certificate is trusted.

Note: Federation Manager provides a utility, named migratessl, to migrate SSL keys and certificates from one system to another. Review information about this SSL migration tool.

Client Certificate Authentication Across the Back Channel

For artifact single sign-on, assertions are sent across a back channel. One way to secure the back channel is to require that the relying party provide a client certificate as its credential. This credential allows the relying party to gain access to the Artifact Resolution Service at the asserting party.

More information:

Encryption and Decryption Algorithms Used by Federation Manager