This procedure assumes you have already configured trust with an identity provider and you want to change these settings as a follow on procedure. You can make these same settings during trust configuration.
For more information, see Trusting an Identity Provider .
This procedure also assume that the public-key certificates you use to encrypt and check digital signatures have been configured. Although you can change the configuration public-key certificate with this procedure, we recommend that you perform an update of the trusted provider instead.
For more information, see Updating the Configuration of a Trusted Provider .
Depending on how you have configured the trust between your SAML service provider and its trusted identity provider, the SAML messages exchanged can include authentication-relevant or personal information. Information of this kind includes user ID, name, last name, address, and telephone number. Exposing such information may expose your network to risk from eavesdroppers or violate local compliance regulations.
The SAML standard provides signature and encryption configurations to protect SAML bindings:
Digital signatures validate the identity of the provider.
You configure what messages the service provider signs and what messages must be signed by the identity provider. The service provider rejects unsigned messages that require signatures.
The service provider supports the following digest algorithms for signing the outgoing SAML 2.0 messages:
Encryption makes sensitive information unreadable without decoding.
You configure what information the service provider encodes and what information must be encoded by the identity provider. The service provider rejects messages with unencrypted information, where encrypted information is required.
If your network configuration allows it, you can also use back-channel communication to protect the client from sensitive information. Even back-channel communication can require protection, if the communication directly between service provider and identity provider is not secure.
For more information, see Configuring Back-Channel Communication .
For this configuration to work, the identity provider has to support the same signing digest algorithm.
The signature and encryption options must match with those of the identity provider. If the service provider requires SAML assertions always be digitally signed and the identity provider never signs them, then the SAML configuration cannot function.
Give some thought to your encryption and signature options and make choices that make sense for your configuration. These also depend on the environment in which your SAML network is working. Systems that operate in a secured area behind a firewall have different requirements from systems exposed to the Internet. We have the following recommendations:
Encrypt or require encryption for those elements that can expose authentication or other personal data about the users. If you use the transient or persistent name ID formats, these name IDs are already opaque. There is no need to encrypt these name IDs. The e-mail name ID format, however, can reveal the users real name and contact information. When using the transient and persistent name ID formats, you can send attributes. These attributes can also reveal personal information, which you should encrypt.
The SAML standard provides many points in the process at which you can sign and check for signatures. Do this only where it makes sense. For example, you can require signature of the SAML assertion and the SAML response. It does not make sense for the identity provider to sign the SAML response and then pack it in a SAML assertion and sign it again before sending the assertion to the service provider. This would only make sense if you developed a custom process to separate the SAML response from the SAML assertion and send the response over a third party before the response is processed. You can further complicate the process by using the HTTP artifact binding and requiring signature of the artifact response. The identity provider signs the message three times.
The service provider supports signature inheritance. If the SAML 2.0 response is signed, the service provider considers the SAML 2.0 assertion to be signed. Likewise, if the SAML 2.0 artifact response is signed, the service providers considers the SAML 2.0 response and SAML 2.0 assertions it contains to be signed.
For more information, see the documentation supplied by the identity provider vendor.