Trusting an Identity Provider

• Manually

• Upload Metadata File

  Provide the path to the metadata XML file of the identity provider. If the metadata XML file is signed, you must provide the location of the public-key certificate with which the service provider can verify the signature. You can select the following sources:

  • From the trust manager

  • From the file system

  For more information about configuring the trusted issuers, see Maintaining the Certificate List .

1. Select the public-key certificates from the key storage for checking the digital signature of the identity provider and encrypting messages sent to the identity provider.

   If you add the identity provider from a metadata XML file, the public-key certificates are already configured.

2. Select the digest algorithm for signing the outgoing SAML 2.0 messages.

   The AS ABAP service provider allows the following digest algorithms:

   • SHA-1
   • SHA-256
   Caution

   For this configuration to work, the identity provider has to support the same signing digest algorithm.

3. Choose an encryption algorithm.

   Note

   The cryptographic software of the identity provider must support the encryption algorithm you choose or it cannot decrypt your messages.

4. Choose the signature and encryption options for requests, responses, and assertions for Single Sign-On (SSO), Single Log-Out (SLO), and artifact resolution.

   The signature and encryption options must match with those of the identity provider. If the service provider requires that SAML assertions are always initially signed and the identity provider never signs them, the SAML configuration cannot function.

   Recommendation

   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 operating. Systems that operate in a secured area behind a firewall have different requirements from systems exposed to the Internet. We have the following recommendations:

   • Encryption

     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 users' real names 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.

   • Digital signatures

     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 to 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. In this case, 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.

The metadata XML provides the bindings supported by the identity provider. If you add new bindings, you must configure the identity provider to support them.

You can specify the comparison method for the authentication contexts the service provider requests from the identity provider.

The service provider requests from the identity provider certain authentication contexts and a comparison method. It is up to the identity provider to decide how to interpret the requested authentication contexts and comparison method, and to choose which type of authentication to perform. If more than one authentication context is configured to be requested from the identity provider (by the service provider), they are sent as an ordered list.

You can choose among the following methods:

• Better

  If the comparison method is set to "better", the identity provider should find an authentication context stronger than the one requested by the service provider. For example, we specify that we request PasswordProtectedTransport authentication context with comparison method “better”. The identity provider will decide which authentication contexts are stronger according to it, and perform the authentication according to the selected authentication contexts. Let’s say that according to the identity provider, Kerberos authentication context is stronger than PasswordProtectedTransport. In this case, authentication can be performed using the Kerberos authentication context.

• Exact

  We declare we want the identity provider to use the specified authentication contexts only, and no other. In this way, the identity provider cannot use a “better” authentication context even if it supports such a context. The service provider will expect to receive a SAML 2.0 assertion, which specifies that some of the requested authentication contexts are used. Otherwise, it will not accept the received assertion. This option is equivalent to an empty comparison method.

• Maximum

  The identity provider should use an authentication context that is as strong as possible, but without exceeding the strength of at least one of the authentication contexts specified by the service provider.

• Minimum

  The identity provider should use an authentication context that is at least as strong as one of the authentication contexts specified by the service provider.

If you do not specify a comparison method (leave it empty), the service provider will not send a comparison method, and the identity provider should use the “exact” method.