403!!-Outbound Communication to S4 On-Premise(OData) from BTP ABAP Environment-Free tier(Steampunk)

[vishnucta]

Team,
I am following below blogs for Outbound communication to access OData service in S4 on-premise. Ended up with "403" forbidden error.

(Additional step 3 of adding SAP_COM_0200 into a communication Arrangement. SAP_COM_0200 is not available in steampunk instance)
https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/outbound-communication-from-c...

in Step 4 of below tutorial(S4 public is used in tutorial),
https://developers.sap.com/tutorials/abap-environment-business-partner-outbound-call.html#0664684a-3...

I have added my virtual host and made 'Cloud Connector' switch on with an optional SCC ID given.

But after all this configuration , the check fails in Communication Arrangement

Error as follows:

Can anyone point our what i am missing!!!

Below my SAP CC config

Communication scenario:

CC Log: Request getting logged in Cloud Connector

Best regards,
Vishnu

@Mani_P_S   @ariannamussobarcucci  @FrankJentsch  Any help appreciated. @merveyalcin 

[julieplummer20]

Hi Vishnucta, By “Steampunk” instance, do you mean a Trial instance? If so, you need a license. Best wishes, Julie Plummer.

[vishnucta]

Hi @julieplummer20 @, Thanks for the response. We have a free tier instance.if I am not wrong I guess it's partner tenant. 

ABAP Platform version 2405

@julieplummer20 can you please confirm or guide me to a document/Note regarding outbound communication to Onpremise Http?

Hope Free tier can do outbound communication.

[vishnucta]

@thomaswiegand any new inputs?? 🙂

[BishalDeb]

Hi Vishnucta

[BishalDeb]

Hi @vishnucta 

I am facing same issue. While testing the connection from Comm Arrangement, I am getting 403 error. 

I need to access OData service of an on-prem system from Steampunk.

Cloud Connector is in place for the connectivity and necessary configurations made in Communication systems and communication arrangement respectively.
NOTE: Cloud connector is turned on in Communication System as well.

Kindly suggest what solution you have opted to make it work in your case.

Regards,

Bishal

[thomaswiegand · Accepted solution]

Hi Vishnu,

as the requests reach your Cloud Connector: Do they also reach your backend system? Any additional logging available there?

The 403 coming from the backend system would usually indicate that the user does not have sufficient authorisations to access the service (authentication worked, otherwise 401 would be returned).

Are you able to directly call the service (e.g. from postman / browser) with the user at the backend system?

Best Regards,

Thomas

[vishnucta · Accepted solution]

Hello @thomaswiegand , Thanks a million for the response.

The user "vvishnu" have the enough auth to execute and query information in Backend system.

[thomaswiegand · Accepted solution]

Hi Vishnu,

[thomaswiegand · Accepted solution]

Hi Vishnu, do the requests reach the backend? E.g. do you see any entries in SU53 for the user, which would indicate further authorisation issues? I would also suggest to set the principal type to None in your SCC configuration as you are not using principal propagation, but technical authentication. Best Regards, Thomas

[vishnucta · Accepted solution]

@thomaswiegandthere is not SU53 entries for that user and even i disable principal propagation. Still the same issue.

Even after this the error is same. "403" 

[thomaswiegand · Accepted solution]

Reiterating 🙂 Do you have any indication whether the requests reach the backend (and are not blocked in SCC already)?

[vishnucta · Accepted solution]

@thomaswiegand the SCC logs have no such information that its getting blocked

[vishnucta · Accepted solution]

@thomaswiegandEven the traces shows the request coming to the backend system

[thomaswiegand · Accepted solution]

And in the response in the backend you also see the 403 HTTP Code or is the call successful from backend perspective?

[vishnucta · Accepted solution]

@thomaswiegandIts successful from BE perspective

[Ulrich_Schmidt1 · Accepted solution]

Activate the ICM trace in transaction SICM. It will show you, why the backend replies with 403.

Also helpful might be to activate the Payload Trace in the SCC. Then you can take a look at the HTTP Body of the 403 response, which might give further error details.

[vishnucta · Accepted solution]

Hello @Ulrich_Schmidt1 , thanks for your response.
I have checked the SCC log and no entries corresponds to 403.

There is a temporary redirect 307 but no 403 in response.

SMICM:

My question would be if 403 is returned by backend then OData trace should also reflect the same ? Please correct me if i am wrong.
Gateway Trace:

Regards,
Vishnu

[Ulrich_Schmidt1 · Accepted solution]

You checked the wrong log: the "http_access.log" records only UI requests from the browser to port 8443, it has nothing to do with http requests to backend systems. As I said, these can be seen only in the Payload Trace. (Files traffic_trace_xxxx.trc.)

[vishnucta · Accepted solution]

@Ulrich_Schmidt1      First screenshot in the above list of screens is from "traffic_trace_xxxx.trc".

Let me attach the same again.

[Ulrich_Schmidt1 · Accepted solution]

Ah, it was so small, my old eyes couldn't recognize it...

Ok, then I have an idea: the original request runs into a 307. The HTTP client on Cloud side then tries to follow that redirect, and this follow-up request then runs into the 403, before reaching the backend (or even the SCC).

Question is: the URL in the "location" header, is that on a different host, or same host and only the path is different? (Unfortunately some parts are blotted out in your screenshot, so I can't see it.)

If it's a different host, then one possibility would be: in the SCC, you have created a hostname mapping only for the first host, but not for the second. (Or if the scenario works with destinations, a problem could also be, that only a destination for the first host exists in the Cockpit, but not for the second host.) In that case you would see an error message in the SCC's "Audit Log", like "Denying access to system ...."

If only the path is different, one problem could be, that in the "Access Control" settings for the host you have not allowed the second path. Again there would be an error in the Audit Log.

If there is no entry in the Audit Log, this means the 403 for the second request must be coming from a component, before the request reaches the SCC. In that case we would need to check some cloud-side logs in more detail. (I hope, the HTTP client in the Cloud App also traces some low-level details?!)

[vishnucta · Accepted solution]

@Ulrich_Schmidt1Thanks a lot for spending some time helping me . Coming to your question i would be great if you can tell me which "location" header you are referring to. There are url configured in "outbound communication" and in "communication Arrangement" ?

Are you referring to this ? when you mean "location" header

[Ulrich_Schmidt1 · Accepted solution]

You can see the "location" header at the very end of the Response data for the 307 Temporary Redirect. The HTTP client (in the cloud) will trigger a second HTTP request to exactly the URL specified in this field.

[vishnucta · Accepted solution]

@Ulrich_Schmidt1The URL in "location" header is virtual/proxy url that is used in the SAP CC configuration

Access Path:

In Addition to above:

2nd request goes without a port and 1st request is to port 443. I have highligted in below screenshot.

And in Audit i can see "Deny Access...."

Is that the 2nd request from cloud http client is picking up default port 80????

I am expecting it to pick up 443 since that what coming from Communication System.

Is the UI hostname i gave in above screenshot creating problem? As per my understanding UI hostname is an optional field and it gets defaulted anyway with normal host.

[Ulrich_Schmidt1 · Accepted solution]

That's it, I have seen that problem before. 😞

Somewhere along the path back, the port 443 gets omitted (because it is the "default port" for the https protocol, so why bother mentioning it...). Then at some other point, the information about "https" gets lost, and the client then thinks its "http". (Probably in the Cockpit/destination, which can be defined only with "http", because the tunnel is already SSL-encrypted?!)

Now the "default port" of the http protocol is 80, so the client (thinking the redirect is for http), "re-adds" the port 80... And the SCC does not have a mapping for port 80, so it denies the request with a 403 error. (So in fact, the statement in the beginning "the SCC logs have no such information that its getting blocked" was wrong, wasn't it?)

Unfortunately, I don't remember the solution. Some component along the line HTTP Client --> Connectivity Agent(Proxy) --> SCC --> Backend needs to be fixed.

But if you want to have a quick&dirty fix, the following workaround fixes the problem: in the SCC, create a second host-mapping, where everything is the same, only the "virtual port" is set to 80. (Real port needs to be the same 443 and protocol "HTTPS".) Then the second redirected request should go through fine as well.

The only thing I don't quite understand yet: the original URL and the URL in the location header look identical (unless I didn't read the screenshots correctly). Why did the backend re-direct the request "to itself"?? That doesn't make sense?! (However, if there is a small difference between original and re-directed request, you could also change the application/HTTP client to use the re-directed URL in the first place, instead of the original one. Then you save one roundtrip (better performance!) and don't run into the problem with the default ports getting confused.

[vishnucta · Accepted solution]

@Ulrich_Schmidt1You are absolutely right , i missed the entry in Audit. 😞 😥

The quick/dirty fix will work but i have configured my Communication System to talk to backend via Cloud Connector (I have switched it off while creating the system)

My understanding was it wont use the destination service rather route the request via virtual host mentioned in SAP CC Access Control. Cockpit/Destination , as you mentioned in your reply have "http" but will it be relevant since i have switched off in Communcation System.

You mentioned "Some component along the line HTTP Client --> Connectivity Agent(Proxy) --> SCC --> Backend needs to be fixed." 
Are you talking about something in SCC Settings or Server related settings in S4 Backend system? Do we have some Apps or  Eclipse ADT steps to configure something at ABAP Cloud in BTP ?

Only BTP configuration that we do is Communication system/Arrangement. Is there anything else in ABAP Cockpit i can leverage for trouble shooting this redirect?

Thanks a lot for your response .

[vishnucta · Accepted solution]

@thomaswiegand Thanks a lot for your suggestions @Ulrich_Schmidt1 Thanks a lot for guiding me in the right direction and your solution.

[Ulrich_Schmidt1 · Accepted solution]

To find out, where exactly the accidental switch from https/443 to http/80 is happening, we would need to look at the logs of the Connectivity Agent (and perhaps also the logs of the HTTP Client used by the application).