Configuration Guides › Federation Security Services Guide › Signing and Encrypting Messages to Secure Federated Transactions › Certificate and Private Key Usage for Federation

Certificate and Private Key Usage for Federation

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

There can be multiple private keys/certificate pairs in the SOA Security Manager key database, known as the smkeydatabase. If you have multiple federated partners, you can use a different pair for each partner.

Private key/certificate pairs and single certificates are stored in the SOA Security Manager key database. Each key/certificate pair, client certificate, and trusted certificate in the key database must have a unique alias. The alias enables SOA Security Manager to reference any private key/certificate pair or single certificate in the key database.

You can manage the contents of the key database using the smkeytool utility.

The following types of key/certificate pairs and single certificates are stored in the key database:

Signing and Verification Operations

SOA Security 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 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 producing authority 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.

Encryption/Decryption Operation

For SAML 2.0 you can configure federation security services to encrypt an entire assertion, the NameID, or other attributes. If you enable encryption, the producing party uses the certificate (public key) sent by the relying party to encrypt data. Before any transaction, the relying party sends the certificate to the producting party in an out-of-band exchange. The relying party uses the 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. Establishing the SSL connection requires that the relying party has the CA certificate associated with the signed SSL server certificate. The SSL server certificate secures the SSL connection, and the CA certificate verifies 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. One way to secure the back channel is to require that the relying party provide a client certificate as its credential. This credential lets the replying party gain access to the Artifact Resolution Service at the producing authority.