Show TOC

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

Procedure

  1. Start the SAML 2.0 configuration application (transaction SAML2).

  2. On the Trusted Providers tab, 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.

  3. Enter an alias.

  4. 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 software 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 with those of the identity provider. If the service provider requires that SAML assertions are always igitally 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 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.

      End of the recommendation.

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

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

  7. Choose the Finish pushbutton.

More Information

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

For more information, see Trusting a Security Token Service.