Access/Permission SASApp*

[shoin]

Objective: Control access to particular SASApp* based on group membership in SAS Meta 

SAS 9.4 TS1 M3 WIN x64 2012 Server, SAS OA Installed w' SHARE & CONNECT (OA = Office Analytics) Multiple SAS Server context and logical servers all validate.

I have created SASApp_1 and SASApp_2 (with Object spawner 1 & 2 respectively). 

I have user group A & B. 

I would like group A to use SASApp_1 and group B to use SASApp_2

*Using same SASHome and Config\Lev1

On SASApp_1 > Properties > Authorization

SAS General Servers RM

SASUSERS RM

PUBLIC All deny

GroupA RM, WM, Check in metadata

Same repeats for SASApp_2 but for GroupB

sasv9_usermods.cfg under SASApp_1 & 2 points to different WORK path and to be sure for testing set MEMSIZE & SORTSIZE little different per group

Not using any RSTRT options

Issue:

Using SAS EG 7.1 user sasdemo which is a member of groupB still points to SASApp_1  (Should be using SASApp_2 and its relevant sasv9_usermods.cfg)

Question

What did I overlook?  

Why defaulting to SASApp_1?

Note: I have not made any changes into sasv9.cfg in SASHome\SASFoundation*\sasv9.cfg 

[PaulHomes · Accepted solution]

You are denying RM to PUBLIC but then granting it back to SASUSERS. The user sasdemo (and every other user registered in metadata) is an implicit member of SASUSERS so every user has access to both app servers. If you want to control visibility deny RM to PUBLIC and only grant RM back to those groups (not SASUSERS) who should be able to see and use the app server. Also don't forget the SAS Administrators group.

[PaulHomes]

I should have also mentioned that you may want to look at the SAS metadata security best practices discussed in various papers mentioned at the top of this blog post: https://platformadmin.com/blogs/paul/2017/06/sas-gel-security-rules-with-metacoda-security-tests/

In those papers you will see standard patterns, encapsulated in ACTs, for denying broadly to SASUSERS or PUBLIC (I prefer denying to PUBLIC) and granting back narrowly to interested parties (not forgetting admins and service accounts). By using ACTs for the standard patterns you can ensure consistency and reduce the likelihood of mistakes or omissions.

[shoin]

Great info, thank you.

[JuanS_OCS]

Hello @shoin,

very quickly and in addition to the always great tips regarding SAS metadata permissions provided by @PaulHomes: if you focus, for now, on SAS EG, as I read you, I would grant and deny permissions to your groups to the SAS Workspace Server and Logical SAS Workspace Server, instead to the SASApp (SAS Application Servers). This should make it easier for you.

If you do it in this way, it will be easier initially for you, it will work and you will understand how it works. And then, you can build up from there.

[shoin]

Sorry about late update.  Great suggestions and loads of great reference material/links.  After I posted my question, I played around a bit and ended up implementing the same solution as suggested by @PaulHomes.  I refreshed the App servers and started seeing the outcome as I wanted. 

@JuanS_OCS I ended up staying with SASApp* contexts as I wanted the permissions applied to the context.

I thank you all for the time and help and your suggestions.  I enjoyed the links to further docs.  My thanks.  I am also glad that in my 'playing' I ended up on the sme principles that were mentioned.  Good to be validated!

Cheers!