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 keys and certificates 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, and it uses SSL server certificates for establishing SSL connections.

There can be multiple private keys and certificates in the key database. If you have multiple federated partners, you can use a different set of keys for each partner.

Private keys and certificates 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 any single certificate or private key/certificate pair to be easily referenced when configuring signing, verification, and encryption of assertions and assertion content. 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 Operation

A private key/certificate pair is used for signing and verification tasks. The private key signs the assertion, the assertion response, or authentication request, depending on the transaction taking place. Prior to any transaction involving signing, the partner signing assertions gives the certificate (public key) associated with the private key to the partner that verifies the signature. This exchange is done as part of an out-of-band communication.

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 check the validity of the signature.

For SAML 2.0 single logout, the side that signs or verifies requests and responses depends on which side initiates single logout. The side that initiates the logout signs the request, and the side receiving the request validates the signature. Conversely, the receiving side must sign the SLO response and the initiator must validate the response.

Encryption/Decryption Operation

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, while the relying party uses the associated private key to decrypt the data.

The certificate is sent in an out-of-band exchange from the relying party to the asserting party prior to any transaction.

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

Enabling SSL Connections

You may enable SSL for the artifact back channel or for general federated communication. Establishing the SSL connection requires that the relying party have the CA certificate associated with the signed SSL server certificate. The SSL server certificate secures the SSL connection, and the CA certificate makes sure the SSL server certificate is trusted.

Client Certificate Authentication Across the Back Channel

For artifact single sign-on, assertions are sent across a back channel. You may secure the back channel by requiring the relying party to present a client certificate as its credential to gain access across the back channel to the asserting party's Artifact Resolution Service.