Explanation + resolution for CX_WS_ST_CACHE_ERROR

Technology Blogs by Members

Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!

Organizations that have applied Duet Enterprise in their application landscape, may encounter the following error in the NetWeaver Gateway WS (WebServices) Errorlog: CX_WS_ST_CACHE_ERROR / Error when writing the ST to DB. The technical explanation for this error is that NetWeaver tries to write a SAML Security Token (ST) into a database table, but fails as that ST is already present as unique key in the table. The functional explanation is that NetWeaver WebService handling applies a message replay detection mechanism, and this is triggered as result of same message received more than once. Message replay is a security attack, used in Denial of Service attacks to bring down the availability of your landscape, or used to compromise the data integrity by resending update requests. So message replay detection is a good security measurement.

Duet Enterprise 1.0 applies SAML 1.1 to provide Single Sign-On from SharePoint 2010 into SAP NetWeaver Gateway 2.0. Required part of SAML support is that the identity provider must unique assert each identity token. This uniqueness is used by service provider to verify the validity of a SAML assertion: in case already used, the identity assertion should be interpretated as stolen and potential misused in message replays.

In the Duet Enterprise runtime client-service flow, SharePoint BCS (Business Connectivity Services) is the service client, and SAP NetWeaver Gateway is the service provider. So Gateway must verify requests received from SharePoint BCS on idempotency, aka detect message replays. SharePoint BCS supports this by unique tagging of each request send with a SAML Assertion ID added into the message header. SharePoint BCS calculates this SAML SignatureValue based on 2 source values: message issuer and message instant id. The issuer value is fixed set to "SharePoint", the instant value is dynamic set to timestamp at moment of sending:

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_2519fc29-9577-403c-a66d-7926b55760a2" IssueInstant="2013-11-08T08:39:07.274Z" Issuer="SharePoint" MajorVersion="1" MinorVersion="1">

However, the applied SharePoint BCS signing approach is vulnerable for false positive signaling of message replay. In case different requests are send by SharePoint BCS in the same millisecond, their calculated SAML Assertion ID will be the same! And thus lead into the NetWeaver receiving side incorrectly believing this is a message replay (attack), and therefore refuse to handle the subsequent received message(s) with same SAML Assertion ID. SharePoint contexts in which this may happen are sending Gateway READ requests in batch during SharePoint Search crawling, custom webparts that use a composition of SAP data services to render the webpart UI (e.g. customer + order headers).

Microsoft Support has confirmed this vulnerability in the SharePoint BCS SAML assertion signing. But sadly stated that "as it is not critical, chances are not very high that this will be fixed anytime soon. Sorry.."

The only remedy for the false positive problem is to disable the message replay detection for the Duet Enterprise runtime flow on the receiving NetWeaver side. Althought this sounds as a security risk, in reality it is not. The Duet Enterprise message flow is inside your internal network, between SharePoint farm and NetWeaver Gateway system. A Duet Enterprise service request can only be initiated automatic by SharePoint BCS as the SAP service consumer, in response of a request send to SharePoint to retrieve the external SAP data.

In the Duet Enterprise context, any message replay attack must originate at the SharePoint webapplication level, from outside your DMZ. Thus to prevent message replay attacks, an organization must protect at SharePoint webapplication level. Most seen protection here is via a Reverse Proxy (e.g. Microsofts UAG, IBM WebSeal, SAP WebDispatcher, ) in front of the DMZ.