Message-Based Authentication with WS-Security

If a WS consumer of an SAP system logs on to a Web service with message-based authentication such as a UsernameToken, a SAML token, or an X.509 certificate, the Internet Communication Framework (ICF) initially performs the logon using the technical user DELAY_LOGON that is stored in the ICF. A direct logon with the authentication data contains in the SOAP document is not possible, since the ICF cannot access SOAP data. The report wss_setup creates the DELAY_LOGON user, which does not have any authorizations. The report also stores the user password in the secure storage.

If a WS consumer then accesses the WS provider, the user stored in the ICF node is first used to perform a logon. The WS provider then evaluates, for example, the UsernameToken sent with the request. If the user name and password match, the WS provider performs a user exchange and logs on the user specified in the UsernameToken.

1. The WS consumer wants to access the WS provider and authenticate itself with a UsernameToken.

2. The ICF cannot evaluate the authentication in the document, but rather requires an HTTP authentication. Therefore it uses the DELAY_LOGON user stored in the ICF and its password for the authentication.

3. The WS provider evaluates the security token (such as a UsernameToken). If the user and password match, it replaces the user DELAY_LOGON with the user specified in the UsernameToken.

• User Repair

  You can check and, if necessary, repair the DELAY_LOGON user in all ICF nodes. This can be necessary if the DELAY_LOGON user has been locked or changed, or if its password has been changed.

• Standard Service Configuration for SecureConversation

  You can set up the standard service for SecureConversation with the field Create Provider Configuration.

• Tolerance for System Clock Synchronization

  If the system clocks of your systems are not synchronous, you can use the Time Tolerance field to set a tolerance.

• Selecting the Utilized Encryption and Signature Algorithms

  WS providers use the configured algorithms for signatures. The default setting is the Advanced Encryption Standard 128 (AES128) with SHA1. Other supported algorithms are TripleDes, AES192, AES256, and SHA256.

  Note

  To use SHA256, you need to have installed the SAP Cryptographic Library PL28.

• Selecting the SAML Trust Configuration

  • Using an SAML Trust Relationship

    The system validates SAML assertions in SOAP messages using the configuration interfaces of SAML 2 and the selected Trust PSEs.

    With this setting, the system validates SAML 1.1. and SAML 2.0 assertions using the trust settings made in the SAML 2 configuration interface.

    Note

    We recommend that you use this setting.

    More information: Preparing WS Provider AS ABAP for Accepting SAML Token Profiles for Validation with the SAML 2 Infrastructure.

  • Use the logon ticket trust relationship

    The system validates SAML assertions in SOAP messages using the assertion ticket or logon ticket PSE. This corresponds to the standard behavior until now.

    With this setting, the system uses the SAML 1.1 assertions using the trust configuration in the logon ticket PSE and the user assignment from table USREXTID. The system validates SAML 2 assertions using the trust settings made in the SAML 2 configuration interface.