Single Sign-On questions for SAS 9.4

[JuanS_OCS]

Hello everyone,

I would like to pick your nice and brilliant minds just for a moment, if you don't mind. Specially @StuartRogers 's if that is OK.

I am having 2 environments, SAS 9.4 M5 (Windows server, SAS Studio, basically, with Stored Processes being served as web services) and another application (if you are interested, it is RShiny, but not really relevant). Both in AWS.

What is relevant is that RShiny is already configured with SSO/SAML 2.0, being OKTA the IdP, similar as all the other applications within this organisation. SAS Studio is configured with Host Authentication only.

The objectives are:

1. - RShiny application must be able to send a request to the SAS web services (STPs) with user authentication.
2. - Single Sign On with SAML/OKTA is a preference in SAS. Users should not type the password. Around 2 years ago it was attempted to connect Shibboleth with OKTA (similar as described by @MikeRoda in his popular paper), but it was not possible due to conflicts in the XML Metadata interfaces.
3. - Credentials, specially passwords cannot travel through the network, it must be very secured.
4. - Due to auditing requirements, only the user who requests (not a system account, such as sassrv) must access the SAS file system, data, code, etc

Let me simplify the options that have been discussed so far:

A. RShiny must send a URL request with user and password as parameters

Not accepted, as password would travel the network. But simple. I can imagine HTTPS but might not be strong enough and still forces to prompt for password.

B. Try again Shibboleth's configuration

Surely the prefered scenario. Not sure if it would work. I have seen some new developments helping Shibboleth to connect to OKTA, but then I have a few additional doubts:

1. Will that be enough for SAS? I guess this one I would only know by trying.

2. This SSO described in Mike Roda's paper works for SAS Metadata and that is enough for SAS VA and viewing reports. Will that work as well for Stored Processes and/or SASStudio, considering the STPs will need to run under Workspace Server, instead of STP? (See objective #4). To me it seems like it won't work, and would require additional configuration, but I am not sure.

C. Enable Web Authentication and Basic Authentication, and rewriting the user header

Someone had this idea, that you can do this, letting the app make request to SAS webserver through a single service account (sassrv or any other), to ensure SAS can trust this account with elevated privileged (wait for it...), and that rewriting the Remote-User header in the request SAS would allow this account to spawn a SAS session un the name of the user that was rewritten on the header.

While I have a ton of concerns about this option, I still don't want to completely close the doors, therefore I will share my thoughts then you can tell me what you think of all of it.

First of all, the part of Web Authentication with Basic Authentication it is not a new idea, but the part of enabling SAS to impersonate a user through a "trusted" account, specially on a Windows server, without any credentials or SSO in place, it seems more a) Sci-Fi and b) extremely insecure and unworthy.

Trying to think out of the box I thought maybe Windows has a way to enable an account to do this, and maybe, just maybe you could do some tricks with SAS/Connect and having XCMD enabled but ... in my mind all crumbles so hard.

D. A variant of C, but stopping in Web Auth + Basic Authentication, but adding an implementation of the user security matrix checks (grants and denies) within the STPs themselves

I don't see this as a bad options, just old style and it sounds as unnecessarily re-inventing the wheel, however mostly discarded as it implies (of course) a lot of development and extra maintenance. Also discarded as it would not allow the actual user to run on the file system, only the system account, therefore, it is hardly auditable in Windows.

Therefore my main question would be:

- can you see any other feasible option, or how to make the current options more feasible according to the main objectives?

Looking forward to hear from the greatest minds!

Thank you in advance,

Best regards,

Juan

[JuanS_OCS]

Just a little push, to see if anyone has any thought or interest - as I see this post is being viewed by quite some folks.

I'll leave it for a few days more, a week max, if there is no movement, I will close it with my thoughts.

Thank you for your attention.

[Sajid01]

SAS stored process can respond to http/HTTPs post requests.  The Restful requests are independent of the nature of source and destination.
To my knowledge R does have a capability to create and sent http get/post requests.

As long as both R and SAS are within the same organization behind the same corporate firewall and domain , and if SAS Web services are behind firewall/load balancer, use of username/password can be dispensed with.

It is possible to configure firewall to regulate traffic from specific I/P's.

If we have the focus on the larger goal of sending http(s) get/post request from R to SAS and the willingness to accept feasible options  it is a workable. (The second part in my opinion is the difficult one because individual preferences of various parties involved have to be managed.).
The exact mechanics depends on your environment.

[JuanS_OCS]

Thank you @Sajid01 . Indeed, so far your indications are aligned with my thoughts.