Background documentationMessage-Based Authentication with WS-Security Locate this document in the navigation structure

 

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 (ICD) initially performs the logon using the technical user DELAY_L_<SID> 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_L_<SID> user, which does not have any authorizations. The report also stores the user password in the secure storage. If the user DELAY_L_<SID> then accesses the WS provider, the provider evaluates, for example, the sent UsernameToken. If the user name and password match, the WS provider performs a user exchange and logs on the user specified in the UsernameToken.

Caution Caution

You need to execute the wss_setup report after the system setup. Otherwise, the user DELAY_L_<SID> and its password will not exist. A logon to a Web Service provider would then fail wiht a 401 header error.

End of the caution.

This graphic is explained in the accompanying text.

WS Consumer Accesses the WS Provider Using the ICF

  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_L_<SID> user stored in the ICF and its password for the authentication.

  3. The WS provider evaluates the UsernameToken. If the user and password match, it resplaces the user DELAY_L_<SID> with the user specified in the UsernameToken.