BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
shoin
Lapis Lazuli | Level 10

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 

 

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
PaulHomes
Rhodochrosite | Level 12

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.

View solution in original post

5 REPLIES 5
PaulHomes
Rhodochrosite | Level 12

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
Rhodochrosite | Level 12

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
Lapis Lazuli | Level 10

Great info, thank you.

JuanS_OCS
Amethyst | Level 16

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
Lapis Lazuli | Level 10

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!

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 5 replies
  • 3522 views
  • 9 likes
  • 3 in conversation