Hi All,
Description:
We recently upgraded our ERP landscape from ERP EHP 3 to 6.
So our NW stack went from 7.0 to 7.31
We use PI to interface between a 3rd party application and our ERP.
But incase of a disruption of our PI system, we have a plan B and its a webservice.
When we did the upgrade, all was fine, PI and all worked.
If checking SICF, the service is active.
Check SOAMANAGER, service is active.
We never invoked plan B.
We have the need to transfer a high volume from the 3rd party to ERP, so bypassing PI is a much faster route in our case.
When trying to hit the webservice, no response.
As I start digging.
SICF, its active, run a test, it does prompt to log in but blank HTTPS page.
So, I launched SOAMANAGER, SAP tells me that the webservice was configured in the old layout, and the new layout will be used.
CLick OK.
I see my webservice Active. So decide to Edit it and click same so it regenerates just to see.
Then I get this error.
SRT Framework exception: ICF: Cannot generate ICF information from SOAP information[System is not prepared for WS Security authentication (note 1319507)] |
And it is now in inactive STate.
I read note 1319507.
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 (for 7.1X) or DELAY_L_<SID> (for 7.0X). A
direct logon with the authentication data contained in the SOAP document is not
possible, since the ICF cannot access SOAP data.
The user name and the
credentials are kept in the secure store and copied into the ICF node of the ws
provider when a configuration is activated.
In case no credentials are
available in the secure store, you get the following error
message:
System is not prepared for WS Security authentication (note
1319507)
Use report wss_setup to create the user DELAY_LOGON (for
7.1X) or DELAY_L_<SID> (for 7.0X), which has no authorizations. The report
also stores the user password in the secure storage. If the user
DELAY_LOGON/DELAY_L_<SID> then accesses the WS provider, the initial
authentication is done using DELAY_LOGON/DELAY_L_<SID>, until the SOAP
processing framework switches the user after successful evaluation of e.g. the
sent SAML assertion.
Before I try this. Any advice? Anyone else see this before? Almost appears the security has been hardened in the newer NW stacks.
Should I run this report? Also concerned about NW stack levels, it discusses 7.1X and 7.0.
Let me know your thoughts and experiences.