SAC: BW Live connection with SAML2 shows error [IOLayer]: (#61) / (#2001), token E in JSON

[MKreitlein]

Dear SAP Community,

as you might know... my questions here are rather complicated than easy 🙂

However I have another strange issue here, where the solution might be simple, if you know it or had the same before:

I'm using a Custom Cloud Identity Provider for the SAC login and the same is configured in SAML2 t-code in the BW system (7.50 SP16).

We have CORS configured via UCONCOCKPIT and the HTTP Allowlists and we also created the Rewrite File, see:

https://help.sap.com/doc/00f68c2e08b941f081002fd3691d86a7/2022.2/en-US/c863b66d03154c81a5f1bee769bb2...

The SAC login to the IDP works with e-mail address and password. The SAC user SAML attribute is E-mail and our SAP BW Users also have the e-mail address in their user profile.

When I try accessing this URL, it works fine. We are redirected to the IDP, I login with E-mail & password and the result of the Server Info is displayed correctly:

https://<ourBWsystem>:443/sap/bw/ina/getserverinfo?sap-client=001

Basically we can say: SAML2 works.

Now comes the strange part:

As of know we have two system connections to this BW system, one with SAML login, one with User&Password = BW User, not the e-mail address.

When I first try to use the story based on the SAML Live-model, then I get this error message:

Initialization of table failed: IOLayer Error: Error [IOLayer]: (#61) Destination host is unreachable

When I switch to the User & password Live-model, then the login pop-Up occurs, where I type in my BW user & PW.

Then this error appears:

Initialization of table failed: IOLayer Error: Error [IOLayer]: (#2001) Unexpected token E in JSON at position 0. Error [Protocol]: (#400) error

Here, in addition I see the red warning message like this:

Error: "Failed to connect to system. Please contact your administrator to check possible causes: CORS settings, third-party cookies blocked." with Link to that page:

https://help.sap.com/doc/00f68c2e08b941f081002fd3691d86a7/2022.2/en-US/2d8bfc35a007408e8967f601ef1f4...

BUT NOW: When I switch back to the SAML Story - it works, data is loaded correctly!

This means that CORS cannot really be configured incorrectly, since now it works...

The question is: What is the problem?

If I try vice-versa: First User&PW story with login --> same error message. Afterwards, the SAML Story works fine!

It seems the BW system wants BW user&password under all circumstances, even via SAML... but as shown with the GetServerInfo Link above... here the IDP login is forwarded to BW without a new login window.

Thanks for your input.

BR, Martin

FYI: I searched in Launchpad but found only two notes which are not matching 😞

[IOLayer]: (#61) - For this I find only: https://launchpad.support.sap.com/#/notes/3130675 which relates to PDF export and is under investigation since about 2 months.

[IOLayer]: (#2001) - For this I find only: https://launchpad.support.sap.com/#/notes/2856852 which relates to BOE Live Universes, not SAP BW Queries.

[martin_benacka]

m.kreitlein,

have you found final solution for this issue or you operate with workaround?

Regards, Martin

[MKreitlein]

Hello Martin,

we recently deleted and recreated the SAML setup in our BW system in t-code SAML2.

We created and exchanged the xml files newly, and since then it seems that it is running stable.

Hope this helps?!

BR, Martin

[JaySchwendemann]

Hi Martin,

here we meet again to demistify SAPs "one vendor - it all works magically" promise.

I second, that you need to tackle samesite cookie, but you seem to have already done that?

• icm/HTTP/samesite=None
• icm/HTTP/samesite_none_add_secure=ON

---

I also would advise briefly looking into https://www.chromium.org/updates/same-site/test-debug/#using-the-devtools-network-panel

---

Then I would suggest (the tool is really not too bad) using the Security Diagnostic Tool (https://launchpad.support.sap.com/#/notes/2960670) to maybe get some insights on the BW system

Cheers

Jens

[MKreitlein]

Hello Jens,

thanks for your ideas...

Regarding "icm/HTTP/samesite_none_add_secure=ON"

Our REWRITE File is exactly the one like here: https://help.sap.com/doc/00f68c2e08b941f081002fd3691d86a7/2022.2/en-US/c863b66d03154c81a5f1bee769bb2...

So it states:

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*)" "$1$2; SameSite=None; Secure"
    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*; *SameSite=[a-zA-Z]+.*); SameSite=None; Secure" $1$2
    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*; *Secure.*); Secure" $1$2

Is it necessary to add this "samesite_none_add_secure=ON" here as one more line, too?

Regarding the Security Diagnostic Tool... good idea... I tried it, but there is nothing which would state an error (I ran it in debug mode). It starts with

Incoming HTTP request:
---------------------------------------------

GET /sap/bw/ina/GetServerInfo?sap-client=001 HTTP/1.1

HTTP headers:
---------------------------------------------
 ~request_line:  GET /sap/bw/ina/GetServerInfo?sap-client=001 HTTP/1.1
 ~request_method:  GET
 ~request_uri:  /sap/bw/ina/GetServerInfo?sap-client=001
 ~path:  /sap/bw/ina/GetServerInfo
 ~path_translated:  /sap/bw/ina/GetServerInfo
 ~query_string:  sap-client=001
 ~server_protocol:  HTTP/1.1
 host:  OURBWHOST
 ~server_name:  OURBWHOST
 connection:  keep-alive
 sec-ch-ua:  "Google Chrome";v="107", "Chromium";v="107", "Not=A?Brand";v="24"
 accept:  */*
 sec-ch-ua-mobile:  ?0
 user-agent:  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36
 sec-ch-ua-platform:  "Windows"
 origin:  https://OURSACurl.eu10.hanacloudservices.cloud.sap
 sec-fetch-site:  cross-site
 sec-fetch-mode:  cors
 sec-fetch-dest:  empty
 referer:  https://OURSACurl.eu10.hanacloudservices.cloud.sap/<br>; accept-encoding:  gzip, deflate, br
 accept-language:  de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
 cookie:  sap-usercontext=sap-language=DE&sap-client=001
 sap-ua-protocol:  https
 ~server_name_expanded:  OURBWHOST
 ~server_port_expanded:  443
 ~remote_addr:  OURIP
 ~uri_scheme_expanded:  HTTPS

Cookies:
---------------------------------------------
 sap-usercontext:  sap-language=DE&sap-client=001, domain:  , path:  , expires: 

Form fields:
---------------------------------------------
 sap-client:  001

Then the IDP is recognized

SAML20 SP (client 001 ): <br>--------------------------------------<br>Local provider<br>----------------------------------------------------------------------------<br><br>Name: YBWH_SAML2<br>Signing keypair: CN:CN=BWH, OU=I0020132266, OU=SAP Web AS, O=SAP Trust Community, C=DE Fingerprint SHA1:etc<br>Encryption keypair: CN:CN=BWH, OU=I0020132266, OU=SAP Web AS, O=SAP Trust Community, C=DE Fingerprint SHA1:etc<br>Clock skew: 120 seconds<br>IdP discovery(CDC)<br>   Selection mode: Automatic<br>   Internal CDC read service: Enabled<br>   External CDC read service: Disabled<br>   External CDC read service URL: <br>Affiliation: No affiliation is configured<br>Legacy Systems Support (Issue Logon Ticket): On<br>Debugging: Disabled<br>Assertion Consumer Service:<br>   Supported Bindings: POST, ARTFCT, PAOS<br>   Endpoint Path: /sap/saml2/sp/acs/001<br>   Default Application Path: <br>Single Logout Service<br>   Supported Bindings: POST, ARTFCT, SOAP, REDIR<br>   Endpoint Path: /sap/saml2/sp/slo/001<br>   Response Location Path (HTTP Artifact): /sap/saml2/sp/slo/response/001<br>Artifact Resolution Service<br>   Mode: Enabled<br>   Endpoint Path: /sap/saml2/sp/artifact/001<br>   Artifact Validity Period: 60 seconds<br>Proxying Settings<br>   Proxy Count: 0<br>Custom authentication contexts<br>Relay state mapping<br>   There are no relay state mappings

And then 2 IDPs are listed... the one which is used in Prod. system, and the one for Dev system.

FYI: Our Dev system got deleted accidentally in Feb. this year, and rebuilt from the Prod. - we did not touch the old SAML settings, but added only the one which is also connected to the SAC from where we try to access the Dev system.

I see the outgoing request to the IDP

SAML20 SP (client 001 ): Outgoing AuthnRequest
SAML20 Binding:          REDIR
SAML20 Signed:           True
SAML20 IdP Name:         OURIDP.accounts.ondemand.com
SAML20 Destination:      https://OURIDP.accounts.ondemand.com/saml2/idp/sso/OURIDP.accounts.ondemand.com<br>SAML20 <samlp:AuthnRequest ID="S005056ba-35a4-1edd-9c94-7a045912e0c6"
SAML20                     Version="2.0"
SAML20                     IssueInstant="2022-11-30T11:41:26Z"
SAML20                     Destination="https://OURIDP.accounts.ondemand.com/saml2/idp/sso/OURIDP.accounts.ondemand.com"<br>SAML20                     ForceAuthn="false"
SAML20                     IsPassive="false"
SAML20                     xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
SAML20   <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
SAML20   YBWH_SAML2</saml:Issuer>
SAML20   <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
SAML20 </samlp:AuthnRequest>
SAML20 

then:

Outgoing HTTP response:

HTTP headers:
---------------------------------------------
 ~server_protocol:  HTTP/1.1
 access-control-allow-origin:  https://OURSACurl.eu10.hanacloudservices.cloud.sap
 vary:  Origin
 access-control-expose-headers:  X-CSRF-TOKEN,SAP-REWRITEURL,SAP-URL-SESSION-ID,SAP-PERF-FESREC,SAP-SYSTEM
 access-control-allow-credentials:  true
 cache-control:  no-cache, no-store, must-revalidate, private
 pragma:  no-cache
 expires:  Thu, 01 Jan 1970 00:00:00 GMT
 content-type:  text/html; charset=utf-8

Cookies:

It seems like going back and forth 4-5 times... but no error message is given.

After the 5th "Outgoing http response" the log ends... and SAC displayed the well-known error.

Still no root cause.

BR, Martin

[JaySchwendemann]

Is it necessary to add this "samesite_none_add_secure=ON" here as one more line, too?

I don't think so. My touchpoints with those ICM parameters I gave stem from a Fiori Server which doesn't have a a Web Dispatcher in front of, so it dealt with samesite via ICM parameters. I think by specifying "SameSite=None; Secure" you already, implicetely dealt with the "secure" part

However, I'm not sure about the path you took (take with a grain of salt, I'm no SAC admin). It seemed by following https://help.sap.com/doc/00f68c2e08b941f081002fd3691d86a7/2022.2/en-US/c863b66d03154c81a5f1bee769bb2... you now have a mishmash (yes, that's an english word also 🙂 between "Live Data Connection to SAP BW Using a Direct CORS Connection via Unified Connectivity" and "Live Data Connection to SAP BW Using a Direct CORS Connection via ICM Script". Not sure if this is necessary or even adviseable and may depend on the patch level of your BW system

When following "Live Data Connection to SAP BW Using a Direct CORS Connection..." did you also implement the dummy auth handler via class "ZCL_DUMMYAUTH_SERVICE"?

About the Security Diagnostics Tool: I used it to troubleshoot a misfunctioning SAML connection between Azure AD and our Fiori server, where effectively the missing samesite = none was a problem. So YMMV

Since you seem to be using current Chrome, there is this note https://launchpad.support.sap.com/#/notes/3205694 that you may or may not know. But since your problem goes way back to spring, I doubt it will be the real issue. Nonetheless, you should apply the correction or else future Chrome version may not work whatsover. Maybe it also helps to get some more insights

If you ask me about my general guts feelings: I assume the reason it starts working after a basic auth is, that you then get over the auth part on BW by means of a cookie. As SAML2 seems be working when directly accessing BW it kinda smells like "browser security, one domain cannot do things on another domain". But that last statement is probably not news to you.

Sorry, if I could not be of more help till now. Cheers

Jens

[former_member82170]

Hello,

Are you able to resolve this issue?

Thanks and Regards,

Prasad

[MKreitlein]

Hello Prasad,

unfortunately I was still not yet able to solve this issue 😞

There are no new insights or ideas on this.

Our workaround is that we build our stories on the SAML connection.

Before we open the story we call any other built on the User/Password connection, enter it, and afterwards the SAML story loads.

BR, Martin

[Slav_Kurakin]

Dear Martin, I have exactly same issue , do you have resolved the problem

on error :

'https://*****.accounts.ondemand.com/saml2/idp/sso/arvew3dd0.accounts.ondemand.com?SAMLRequest=hZFfS4UwGMa%2FiuxenZZaQwXrEAgVh04UdDe3V85AN9s7z6lv3%2FRAnC4q2NXD%2B%2Fz5sRL5OEysmd1eP8H7DOiCdlORHaUZzfLuKgToZZgAiJCLvg%2B7vChyKBLRdT0JXsCiMroiaURJ0CLO0Gp0XDsv0TQN6aV%2Fz%2FSaZQXL8jcSbHyD0tytrr1zE7I45vYAxwspacSFMLN2GBktYeRaRsKM8TIyjZWcYkTz3zUJ7owVsCJVpOcDwjJtyxHVAb6Vj3HQyFb8isxWM8NRIdN8BGROsF3zcM88FpuscUaYgdTlcs1WSnvm%2F9vua8EuuKTeNdub1zI%2BSzlFTuzR29rN1gxKfC7zR%2B5%2BT02iZFWUDPv1lM0aJxCqVyBJ0AyDOd5a4M7DOjsDietT6c9%2Frr8A&RelayState=oucqqvqvwbyoeefdoreecoacffobwxxwexrcbbf&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=lXRXG26Ucv7wizMteZQgWJ3SSwDyZEx%2BvIT29yXjdosNSwACIKntIrxSx7GI4WSBrXi8pqEo6opStY24Vn3OgF4SaMELrkdRcAAvSbVwId9qIejkyaep00iQGdLAI5d22Iy92mFCssIN0N5Z2UdBLQSo5XIva%2BWTD0%2BOIhEIRAHKBrIoQ%2BFFGPZrrOmvGQvOYozZi5Vx721b4xdDIbxhRXe%2BFgF3%2FdBPQ%2FzhSmSB63BWM4d5Bfrr9VuJ2viayzcapD0EWPhuJBypWgEruR7MvqnrqXOg3FTQKA8BQuWm5AP%2F1%2FVALghzhilvz0hG%2BjmacyNK4y%2FHbeg%2B4Lu0BQMT2w%3D%3D' (redirected from 'https://xxx.xxx.xxx:8501/sap/bw/ina/GetServerInfo?sap-client=100') from origin 'https://****10.hcs.cloud.sap' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

app.chunk.2405.673703dead96284dd933.js:2

GET https://****.accounts.ondemand.com/saml2/idp/sso/arvew3dd0.accounts.ondemand.com?SAMLRequest=hZFfS4U... net::ERR_FAILED 200

appreciate if you may share the solution

[MKreitlein]

Hello Vyacheslav,

thanks for asking ... no unfortunately I did not solve it, yet 😞

After reading several documents or Blogs about CORS, e.g.

https://cloud.google.com/storage/docs/cross-origin?hl=en

https://blogs.sap.com/2019/01/07/cors-and-fioriui5-everything-you-need-to-know/

... I'm quite sure that either my IDP does not issue the SAC URL header when using SAML to my BW System.

Or the BW system does not acknowledge it, when sent from the IDP.

I added the IDP also in the UCONCOCKPIT - since I found a blocked entry there:

Unfortunately I don't know which methods are required (I added CONNECT, too), so it is almost a 1:1 copy of the SAC entry.

That's all I tried so far ... but it does not work always for all colleagues on the first try 😞

BR, Martin

[MKreitlein]

Hello Shailu,

thanks for your feedback. Regarding this: https://launchpad.support.sap.com/#/notes/2887651

Exactly this is my scenario:

Logon and single sign-on using SAML2. To be more precise, the SAML2 POST binding against a SAML Identity Provider (IdP) that resides in a different registrable domain is affected. An example is using SAP ID service with your intranet systems. Both the IdP and the ABAP system issue cross-domain cookies that need to set the SameSite=None attribute. The SAP ID service already does this correctly.

--> The question is: How and where to set the attribute in the Cloud IdP?

In my BW systems (Dev and Prod) we have exactly the same REWRITE file from the help page.

We have CORS enabled in the parameter: icf/cors_enabled

We have the the whitelist scenario configured via UCONCOCKPIT.

We have SAML2 configured... the difference is: Prod BW. is with Windows ADFS IDP in own network--> works fine. Dev. BW is with Cloud IDP on accounts.ondemand.com --> problem occurs.

Thanks to your answer I tried debugging, this is the result:

I found out that in the HTTP checks there was one red entry for this IdP and service: /sap/saml2/sp/acs/001/

Now I added this same entry to the whitelist with the same headers as my SAC entry.

Unfortunately this does not solve the issue... message is still the same.

So, do you think I need to add "icm/HTTP/samesite=None" into RZ10 profiles, too?

Is this not required in my Prod. BW because they are in the same domain?

Thanks, Martin

[ShailendarAnugu]

Hi Martin,

Can you please confirm, if same site cookies fix has been applied? refer to https://help.sap.com/viewer/00f68c2e08b941f081002fd3691d86a7/release/en-US/c863b66d03154c81a5f1bee76... or https://launchpad.support.sap.com/#/notes/2887651

if no, please apply it either through ICM rules from server side solution (please note browser side solution is invalid in latest chrome browsers) or set the icm/HTTP/samesite = None, https://launchpad.support.sap.com/#/notes/2893546 .

if yes, please try to debug using browser developer tools, under network, you should be able to check which service calls are failing.

Thanks,

Shailu.