In this article, we'll compare the SAS 9 and SAS Viya permissions users (or better, groups to which they belong) are granted, to allow those users to change, just read, or not even see the contents of a folder.
In part 2, we will look at how SAS 9 permissions on folders are mapped to SAS Viya permissions during migration or promotion. That should be interesting to anyone migrating their SAS content or their Admin knowledge from SAS 9 to SAS Viya, although you should be prepared for very few of your SAS 9 permissions to be reproduced as SAS Viya permissions in practice, when you promote content from SAS 9 to SAS Viya.
In any case, a good understanding of what combination of permissions will grant a user various degrees of access in SAS Viya is valuable to anyone planning to migrate too, so we'll cover that first, in this post.
Permissions are applied and respected widely in SAS 9 and in SAS Viya - on metadata folders, reports, data and on the host OS and in databases. A complete comparison of the various authorization systems used together in SAS 9, and those used in SAS Viya would be far too much for one article. (Even I won't try that!)
But if you follow the good practice of applying permissions to metadata folders in SAS 9 where possible, then folders are a good place to begin in comparing authorization in SAS 9 and in SAS Viya general authorization.
Table 1 below shows the permissions you would grant or deny to a user - or preferably to a group the user belongs to - in order to give them the capabilities indicated in the first column on a folder and its contents.
| To enable a specific user to... |
Effective permissions in
SAS 91 |
Effective permissions in
SAS Viya |
| |
On the folder (and where relevant on its contents) |
On the folder itself (i.e. from rules which target the folder's URI) |
Conveyed to the folder's contents (i.e. from rules which target the folder's container URI) |
| Hide the folder |
Read Metadata is denied on the folder. |
Read is 'not authorized' |
Not important, since folder is hidden from users |
| See the folder, but not its contents |
Read Metadata is granted on the folder. Read Metadata is denied on each object inside the folder. This pattern is not commonly used in SAS 9, as it is laborious to implement and maintain. |
Ensure that a Read grant is not inherited from a folder higher up the tree, but Read is granted directly on the folder itself |
Read should not be granted on the folders contents. There are two equivalent ways of saying this:
- Read (convey) is not granted on the folder, or
- There is no rule which grants Read on the folder's container URI
Both mean the same thing. |
| See the folder and its contents, but not modify its contents |
Read Metadata is granted on the folder, and is inherited by its contents. Write Member Metadata must not be granted on the folder, and Write Metadata must not be granted either on the folder or on its contents. |
Depends on whether the folder inherits a Read grant from a parent folder or not. If a Read grant is not inherited from a parent folder, then grant Read directly on the folder itself, and grant Read (convey) on the folder to pass Read permission down to its contents. If a Read grant is inherited from a folder higher up the tree, there is no need to grant it directly on the folder, or its contents: Read is already inherited by the folder and by its contents. In order to not allow the user to modify the folder or its contents, no other permissions on the folder or its contents should be effectively granted to this user. |
| See the folder (but not be able to modify it), and be able to modify its contents |
Read Metadata is granted on the folder, inherited by its contents. Write Member Metadata is also granted on the folder. However, Write Metadata must not be granted on the folder itself, so the user cannot rename/move/delete the folder or modify its authorization. |
Depends on whether the folder inherits a Read grant from a parent folder or not. If a Read grant is not inherited from a parent folder, grant Read directly on the folder itself, and grant Read (convey) on the folder to pass Read permission down to its contents. Or, as above, if a Read grant is inherited from a parent folder, there is no need to grant it directly on the folder, or its contents: Read will be conveyed down to them too. Remember to grant Add and Remove on the folder itself for this user (or better, a group they belong to), so that this user can add and remove objects from the folder. I think these two grants may be easily overlooked by administrators familiar with SAS 9. Lastly, grant Update (convey), Detete (convey), Add (convey) and Remove (convey) on the folder, so that these four permissions are also passed to the folder's contents, including any subfolders. (Alternatively, create a rule targeting the folder's container URI which grants this user Update, Delete, Add and Remove - which means the same thing). |
| Modify the folder and its contents, but not change permissions on the folder or its contents |
Not possible in SAS 9. If you grant a user permission to modify the folder by granting the user (or better, a group they belong to) Write Metadata on the folder, this will also allow the user to change authorization on the folder. |
Easy in SAS Viya. On the folder, arrange that this user is granted Read, Update, Delete, Add and Remove, but not Secure. |
On the folder's contents, arrange that this user is granted Read, Update, Delete, Add and Remove, but not Secure. |
| Modify the folder and its contents, including change permissions on the folder or its contents |
Read Metadata and Write Metadata are granted on the folder, and both are inherited by its contents. If you use Data Integration Studio, also grant Check In Metadata on the folder, so that it is inherited by the folder's contents. |
All permissions (Read, Update, Delete, Secure, Add and Remove) are granted on the folder. |
On the folder's contents, similarly grant all permissions (Read, Update, Delete, Secure, Add and Remove). |
Table 1 - Folder permissions compared in SAS 9 and Viya
Note 1: I have focused on metadata-related permissions in the SAS 9 column of this table: Read Metadata, Write Metadata, Write Member Metadata and in one case Check In Metadata. It does not cover data-related permissions like Read, Write, Create, Delete etc. For SAS 9 folders which contain libraries, tables etc., data-related permissions are important too.
But SAS Viya folders do not contain data objects (they are managed by CAS), so I have not included data-related permissions in the SAS 9 column of this comparison.
There are plenty of established and well publicised good practice documents for how authorization models in SAS 9 should be designed. Rule #1 of the Golden Rules of Security Model Design in SAS 9 is 'Only use ACTs, never ACEs', and Rule #2 is 'Only add groups to ACTs' (i.e. never users). See also my series of five papers on Recommended SAS 9.4 Security Model Design, published on SAS Communities: part 1 and part 2.
However, if you follow those good practices in SAS 9 (and you absolutely should), and you later you promote your SAS 9 content to SAS Viya, please be aware that most of those permissions, most of your security model will not be promoted to SAS Viya! Only direct ACEs are promoted from SAS 9 to SAS Viya... and we have long recommended you don't use them. Plus, the groups which may feature in those direct ACEs may not match equivalently-named groups in the target SAS Viya system.
So, all this means that you will almost certainly have to design and implement a completely new authorization model in SAS Viya to secure your content promoted into SAS Viya from SAS 9. We'll look at this in more detail in part 2.
Hope to see you then!
