topic SAS Studio security setup in Administration and Deployment

SAS Studio security setup

Kamsher — Fri, 03 Aug 2018 16:15:55 GMT

Hi All,

We are currently running SAS 9.4 M5 (For Linux) and SAS Studio 3.71. We also have users who use batch sas and SAS interactive. We use grid with x nodes and the integration of SAS infra with grid is through LSF 9. Assuming a user logs into SAS Studio , he/she would be routed to one of the x grid nodes and the root directory (along with sub-dirs) are made available in the left palette of SAS Studio. Our current security setup is such that any user who would like to access SAS Studio application, has to -

1) His/ her unix ID needs to have access to SAS servers as well as the x Grid nodes

2) needs to be part of SAS Metadata (PAM auth verification)

Now whenever the user logs into SAS Studio, we see 2 processes spawned under his/ her ID. Now we would like to configure te security in such a way that these jobs should not be spawned under the user's ID, rather there should be a common service account. So irrespective of whoever logs into SAS Studio (after the system authenticates him/ her), all processes should be owned by a service account.

How do we go about this? Any thoughts?

Re: SAS Studio security setup

PaulHomes — Thu, 02 Aug 2018 23:10:45 GMT

To launch SAS Workspace Servers using a service account instead of the requesting user account you can configure it for SAS Token Authentication - see SAS Token Authentication and How to Configure SAS Token Authentication in the SAS 9.4 Intelligence Platform: Administration Security Administration Guide.

Re: SAS Studio security setup

Kamsher — Fri, 03 Aug 2018 13:38:39 GMT

Thanks Paul. I'll read the artifact you shared! 🙂

Re: SAS Studio security setup

Kurt_Bremser — Fri, 03 Aug 2018 13:44:21 GMT

Out of experience, I advise against this. You lose all options of using operating system based user specific settings, like file system quotas etc

Re: SAS Studio security setup

shayne — Fri, 03 Aug 2018 15:49:59 GMT

As @Kurt_Bremser correctly mentions in his reply, the limitation of configuring SAS Token Authentication is that you lose granularity of host access on the workspace servers. You'll need to be very aware of the privileges assigned to the service account on the host operating system - if it's configured to have generous privileges, than any user's workspace server session will also have that generous access to the host OS (although you can apply some access restrictions via SAS metadata).

I'm interested in understanding the business value / reason behind the type of configuration you are asking about. Can you give us more info about why this configuration is desired at your site?