To secure the content of messages and assertions, the SAML standards specify that public key cryptography be used. Using this method, the federation partners exchange public/private key pairs and use the keys to sign, encrypt, validate and decrypt messages and the assertions within the messages, as required in the SAML standard or as appropriate to their environment.
When you configure a federation in Tivoli® Federated Identity Manager, the federation configuration wizard will prompt you with either signing, validation, or encryption requirements or signing, validation, or encryption options based on your SAML protocol and profile or binding selections. For example, if the choices you make when configuring your federation indicate that a signature is required, the wizard will prompt you for a signing key. If your selections result in an option to sign or not, the wizard will let you make a selection.
Before you use the federation configuration wizard, you must have created the appropriate keys. The information in Setting up message security can help you plan which keys you will need in your environment and provides instructions for creating or obtaining them.
The following sections provide general descriptions of the keys used in SAML federations.
XML messages and SAML assertions are signed by one partner to protect the integrity of the message. The signature enables the receiving party to check if the message had been changed or modified during transmission. Signing is done using a private key. The partner who receives the signed XML message or SAML assertion will need the X.509 certificate (public key) that corresponds to the message signer's private key. By default, the X.509 certificate (public key) is included with the signature as a base64-encoded X.509 certificate. However, you have the option of specifying which certificate data you want to include with your signatures.
The signatures in messages and assertions can be validated by the partner who receives them. Validation confirms that the signer's identity as been assured. Validation is done using the public key of the partner who signed the messages or assertions.
In SAML 2.0, messages can be encrypted in addition to being signed. The use of the public/private key pair during encryption and decryption differs from its use during signing and validation. Encryption is done using the public key of the intended recipient. In other words, for one partner to encrypt a message, that partner must have the public key of the partner to whom the message is being sent. The partner who receives the encrypted message must use its private key to decrypt the message. In Tivoli Federation Identity Manager, when SAML 2.0 is used, both partners must obtain their own public/private key pairs to be used for encryption. They must then exchange their public keys so that each partner can encrypt messages to the other.