Using Restful SDK “logon/adsso” in cluster architecture causes CORS issues

[Former Member]

We are developing a « custom extension » in Design Studio that uses “Restful Web Service” calls to retrieve WebI document data.  To test, we save the Design Studio application on the BI LaunchPad and execute it from IE.

One of the steps of the “custom extension” is to authenticate via Restful calls with the BI Platform before running any other Restful calls to retrieve document data.

Our first test was the use the http://<baseURL>/logon/long call to retrieve the token (this is successful).

Ref: 4.3.1 To get a logon token from a user name and password from sbo41_bip_rest_ws_en.pdf

Then we replaced it with http://<baseURL>/logon/adsso call to leverage the AD SSO with IE (this is successful).

Ref: 4.3.3 To get a logon token using an Active Directory Single Sign-On (AD SSO) account from sbo41_bip_rest_ws_en.pdf

We have successfully tested everything on the Sandbox which is a single server deployment.  The system baseURL is the same as the Restful baseURL.

We migrate everything to a DEV environment which is a clustered environment.  So we have 2 servers. https://vmboserver1:8443/BOE/BI and https://vmboserver2:8443/BOE/BI

We will have load balancers associated later.  Ex:  https://vmboserver:8443/BOE/BI and https://resfulboserver:6443/biprws

Currently, we are waiting for the load balancers, but we would still like to test doing the following.

When we call https://vmboserver1:6443/biprws/logon/adsso from https://vmboserver1:8443/BOE/BI, it is successful.

When we call https://vmboserver2:6443/biprws/logon/adsso from https://vmboserver1:8443/BOE/BI, we get CORS and access denied error message.  The application is launched from vmboserver2 server but calls the restful on vmboserver1 server.

We have applied following steps but still error occurs and calling Restful services to a different server.

• http://scn.sap.com/docs/DOC-61118

1. setRequestHeader('X-Requested-With', 'XMLHttpRequest'); 
   • http://scn.sap.com/docs/DOC-61231
1. setRequestHeader('X-PINGARUNER', 'pingpong'); 

We have also applied following instructions from sbo41_bip_rest_ws_en.pdf:

Ref: 5.11 To configure cross-origin resource sharing (CORS)

And

Ref: 3.2 Using Ajax and JavaScript with RESTful web services across domains

We have also applied following instructions from sbo41sp3_bip_admin_en.pdf:

Ref: 12.1.8.2.1 To configure Methods and Headers command line parameters

And

Ref: 12.1.8.2.3.1 To configure cross-origin resource sharing (CORS)

And

Ref: 12.1.8.2.4.1 To configure web.xml to enable WinAD SSO

We cannot seem to remove this CORS error from the architecture.  Please any suggestions?

Thanks,

Windows Server

BI 4.1 SP3

[Former Member]

Seing that architecture issues is preventing to use the Restful call "adsso", we have turned to using the call "token" instead and that seems to go over the architecture issue.

Thanks to Rogerio from his blog in finding how to use the token call.

[Former Member]

Hi Sing,

take a look at

Regards,

Rogerio

[Former Member]

Hi Rogerio,

               currently applying this as it was also in my first post and issue is still persisting.

Thanks,

[daniel_paulsen]

I don't have any answers since I'm not familiar with the Cross Domain setup, but here's  some things that come to mind:

1. is the problem limited to /logon/adsso or does it fail with /logon/long (secEnterprise) as well?
2. If you monitor the http traffic with Fiddler, are there any hints towards incorrect headers or redirects?
3. Turn on "Show Error Stack" on both WACS servers to see if you can get any more detail on the error.

[Former Member]

1.  secEnterprise is working with /logon/long...  and /logon/adsso works when deployed on a single server or clustered server but you have to query the same server from the application.

2. Fiddler doesn't provide much as it just shows 401 results (This request requires HTTP authentication)

Header:

OPTIONS https://vmboserver1:6443/biprws/logon/adsso HTTP/1.1

Accept: */*

Origin: https://vmboserver

Access-Control-Request-Method: GET

Access-Control-Request-Headers: x-pingaruner, content-type, accept

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; Tablet PC 2.0)

Host: vmboserver1:6443

Content-Length: 0

Connection: Keep-Alive

Cache-Control: no-cache

3.  We'll turn on "Show Error Stack" on both WACS but not sure what I am looking for as the Network tool (F12) inside IE seems to already point us to the proper error.

... required Cross Origin Ressource Sharing

... CORS preflight

... XMLHTTpRequest: Network Error 0x80070005, Access is denied.

Thank you for the suggestions.

[daniel_paulsen]

Again, this is not my area of expertise, so I may be talking jibberish here...

If the secEnterprise logon works and the adsso fails, it could be the Origin settings.

If, from Anthony's blog, you are using "Allow Origins : * " this could be the issue.  From what I could find, requests requiring credentials cannot use a wildcard.  Try specifying both servers (using FQDN) in the "Allow Origins" property of the WACS and remove the wildcard.

Also, I'm not sure if this applies in your case, but apparently for a request using credentials, you need to specify XMLHTTpRequest.withCredentials = true;  or the browser will reject any request without the following header:

          Access-Control-Allow-Credentials : true

and it will block the response to the requestor.

I found a cool tool where you may be able to test this: http://client.cors-api.appspot.com/client

I hope this helps,

Dan

[former_member197386]

Hi,

May this help?

http://scn.sap.com/docs/DOC-61118

Anthony

[Former Member]

Thanks for the link Anthony, but as you can see, it was already posted and tried on my initial post.

Since then, we have dumb down a little the issue to the fact that simply having the Restful Service on the BOE server and the Tomcat on another server is causing this issue.  Nothing to do for now with load balancers.  Having the Design Studio application launch from BI LaunchPad which has a different URL then the destination server where we do Restful calls is creating the CORS issue.  And seems it's only the logon/adsso feature of Restful.  When using logon/long, it seems to go through and pass through the CORS.

Currently, I'm testing it out with WebI as I just learned from Rogerio that you can do javascript and implement Restful calls directly in WebI.  As I am launching from WebI which normally uses the URL of Tomcat for the BI  LaunchPad, and within the WebI, I create Restful calls to the Restful service which resides on another server.  We'll see if the logon/adsso will go through...  I right now that the logon/long works fine.

Why is this multiple tier installation causing issues?  Shouldn't it be ok to have split the services into multiple servers?  Could it be that because the Restful service is relying on another application server (WACS) instead of Tomcat, so it's like having a completely different system which we need to communicate?  Moving the WACS server to the same server as the Tomcat would be a probable solution but it's not something we really want to go forward with.  That would put a burden to Tomcat has we are thinking of using the Restful services to the max, thus having it's own ressources.

Any thoughts?

[BasicTek]

It's just my opinion but I would say for the record that all efforts to avoid using WACS for anything (especially anything that will be in production one day) should be made. If you can get a similar result not using WACS you will be much better off for it in the future. Configuration, limitation, troubleshooting, bugs, are all seriously inhibited with WACS especially when you add 3rd party auth.

OK that said it sounds like your WACS server is different then tomcat (where SSO is working) If that is the case the documentation out there does not take this in account. Normally to get WACS restful working you need tomcat working with SSO on the same server, once we verify that then we can transfer the settings over to WACS.

It is feasible to get WACS restful SSO working without tomcat SSO, but as stated above troubleshooting and configuring it will be very difficult if not impossible.

You mention not wanting to move WACS to the tomcat server, that's fine but can you add another tomcat to the WACS server? Get SSO working on the tomcat, and then transfer the settings?

If not then have you created SPN's for WACS URL (since it's different than tomcat) and I don't believe that's documented.

Regards,

Tim

[Former Member]

Thanks Tim, and I am aware that we should move away from WACS which was the case before we started to experience the Restful Web Services.  I think it will not run without WACS installed.

Also from the SAP Note 1959371

Currently WACS only remaining function in BI 4.x is for restful web services.

Is there a way to use Restful without WACS and have it run on Tomcat?

We'll see if the SPN on the AD would help.

Thanks,

[BasicTek]

Not yet, and I'm hearing Lumira has functionality using WACS so it will probably be around much longer than we'd like.