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.
You need to execute the wss_setup report after the system setup. Otherwise, the user DELAY_LOGON and its password will not exist. A logon to a Web Service provider would then fail with a 401 header error.
The WS consumer wants to access the WS provider and authenticate itself with a UsernameToken.
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.
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.
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.
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.