Trusting an Identity Provider

Prerequisites

You have configured an identity provider in your network.
If you intend to add the identity provider manually (without using a metadata XML file), you have imported the public-key certificates of the identity provider for encryption and digital signature of SAML messages. Import these certificates into the trust manager of SAP NetWeaver Application Server (AS) ABAP.

For more information, see Trust Manager .
If you intend to add the identity provider from a metadata file, you have a means of accessing the metadata of the provider from a secure source.

If you upload the metadata from a file, the system assumes that you received the file from a trustworthy source. The service provider accepts the metadata. However, if the metadata is signed by the identity provider, the service provider checks that the issuer of the certificate of the signer is trusted by the AS ABAP. If the AS ABAP does not trust the issuer, the service provider rejects the metadata.

Context

Use this procedure to identify an identity provider for your service provider to trust. The service provider requests identity information from the identity provider, which you configure the service provider to trust, for applications the service provider is protecting.

You can have a primary and secondary certificate for signatures. This enables you to span the time when the old primary certificate is due to expire, and you have not yet configured all peers to accept the new one. In that case the secondary certificate is used.

Procedure

Start the SAML 2.0 configuration application (transaction SAML2).
Go to the Trusted Providers tab.
Open the dropdown box for the list of trusted providers in the field Show and select the respective trusted provider.
Choose the Add pushbutton and choose one of the following:
- 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 .
(Optional) Enter an alias.

Note

If you are adding the service provider manually, you also have to specify a name.
Enter the required data for digital signatures and encryption.
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.
Enter the required data for the SSO, SLO, and artifact resolution service (ARS) endpoints.

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.

Note

If you use artifact endpoints that use HTTPS, import the SSL server certificate of the identity provider in the Standard SSL Client PSE. For more information, see Trust Manager.
Enter the required data for authentication contexts and requirements for the authentication response.
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.
Choose the Finish pushbutton.

Next Steps

For Web services, you can trust a security token service (STS).

For more information, see Trusting a Security Token Service .