Procedure documentationTrusting an Identity Provider Locate this document in the navigation structure

 

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.

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 to import the public-key certificates of the identity provider for the digital signatures of SAML messages. You also have to import the public-key certificates of the identity provider for encryption of SAML messages, if they are required. Import these certificates into the key storage of the SAP NetWeaver Application Server (AS) Java.

    For more information, see Using the AS Java Key Storage.

  • If you intend to add the identity provider from a metadata file, you should have a means of accessing the metadata of the provider from a secure source.

    • If you upload the metadata from a file, you must ensure that you got 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 signer's certificate is trusted by the SAP NetWeaver Application Server (AS) Java. If the AS Java does not trust the issuer, the service provider rejects the metadata.

    • If you upload the metadata from a URL, the service provider distinguishes between accessing the URL with HTTP or HTTPS in addition to whether the metadata is signed or not.

      Protocol

      Metadata is Signed

      Metadata is Unsigned

      HTTP

      If the issuer of the signing certificate is trusted, the service provider accepts the metadata.

      The service provider rejects the metadata. There is no way for the service provider to verify the source of the metadata.

      HTTPS

      If the issuer of the signing certificate is trusted, the service provider accepts the metadata. As an additional check, you can require the service provider to check if the issuer of the server certificate for Secure Sockets Layer (SSL) is trusted. If the issuer is not trusted, the service provider rejects the metadata.

      If the issuer of the server certificate for SSL is trusted, the service provider accepts the metadata.

Procedure

  1. Start SAP NetWeaver Administrator.

  2. Choose   Configuration Management   Security   Authentication and Single Sign-On   and choose   SAML 2.0   Trusted Providers  .

  3. From the list of trusted providers, show the identity providers.

  4. Choose the Add pushbutton and choose one of the following:

    • Manually

    • Specifying Metadata URL

      Provide the URL of the metadata XML file for the identity provider and determine if you want to verify the SSL server certificate of the identity provider.

      • If the metadata is unsigned and you are accessing the URL with HTTPS, select the Verify SSL Peer Identity checkbox. Otherwise the service provider rejects the metadata. To view the certificates of the certificate authorities the AS Java trusts, choose the Trusted Issuers pushbutton.

        For more information about configuring the trusted issuers, see Selecting the Keystore View for SSL for the Service Provider.

      • If the metadata is signed and you are accessing the URL with HTTPS, you can select the Verify SSL Peer Identity checkbox as an option to confirm the identity of the identity provider.

      • If you are accessing the URL with HTTP, clear the Verify SSL Peer Identity checkbox.

    • Uploading Metadata File

      Provide the path to the metadata XML file of the identity provider.

  5. Enter a name and an alias.

    Caution Caution

    Do not change the name of the identity provider if the metadata XML file provides it. The name must match the name configured in the identity provider exactly.

    End of the caution.

  6. 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. Choose an encryption algorithm.

      Note Note

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

      End of the note.

    3. 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 those of the identity provider. If the service provider requires SAML assertions always be digitally signed and the identity provider never signs them, the SAML configuration cannot function.

      Recommendation 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 the user's 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.

      • 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 through a third party before the response is processed. You can further complicate the process by using 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 provider considers the SAML 2.0 response and SAML 2.0 assertions it contains to be signed.

      End of the recommendation.

  7. 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.

  8. Enter the required data for authentication contexts and requirements for the authentication response.

  9. Choose the Finish pushbutton.