Newcomers to SAS Viya Administration may appreciate these tried-and-tested patterns for securing folders, and the content within them (reports, data plans, models etc.). Nothing too fancy today; if you are new to security model design in SAS Viya, this post is for you.

It presents five patterns for permissions on folders, reports, data plans and the like, and shows how you can combine them and apply them to design a simple but effective security model (or authorization model) for a folder structure.

SAS Viya has two authorization systems

If you are just starting work with permissions in SAS Viya, then you should be aware that there are TWO authorization systems in SAS Viya:

• The general authorization system is used to secure (manage access to) folders, reports, data plans, models and other content stored in SAS Viya’s database (the SAS Infrastructure Data Platform, which uses PostgrSQL behind the scenes). It is also used to manage access to SAS Viya applications and some of their features.
• The CAS authorization system is used to secure (manage access to) data, held in or accessed through SAS Cloud Analytics Services (CAS).

There is no overlap between the two systems. If you are interested in the permissions on a CAS library or table, you use the CAS authorization system. For everything else stored inside SAS Viya, it’s the general authorization system. Click the links above for the documentation. It’s worth mentioning that SAS Viya does make use of the host operating system’s filesystem, and can also access data in other databases or in SAS 9, each of which has its own authorization system too. These are therefore important too, but they usually take up less of a SAS Administrator’s attention.

SAS Viya has a built-in custom group called SAS Administrators, which is granted broad administrator access to much of the SAS Viya system out of the box. It is not a good idea to make users members of SAS Administrators unless they will bear at least joint responsibility for the health and stability of your SAS Viya deployment. Departmental ‘power users’ who just need read and write access to all your users’ content should not be made members of your SAS Administrators group! It’s better to make a content administrators group (or equivalent) and grant that group more access than you grant to most users.

Editing folder permissions in SAS Environment Manager

In the Content page in SAS Environment Manager (and some other places too), you can edit the authorization settings for folders, reports and other objects stored by SAS Viya. For most objects, e.g. reports, data plans, models etc, the Edit Authorization dialog looks like this. I’ve overlaid a blue shape, intended to emphasize that all four permissions apply to the object itself:

The Edit Authorization dialog for a folder has two more permissions (add and remove), and also has a second set of permissions. Those on the left apply to the folder itself, while those on the right, with ‘(convey)’ in their names, apply to the folder’s contents (technically, they apply to the folder’s ‘container’ and are conveyed to its contents). Again I’ve overlaid blue shapes to emphasize this:

This allows you to easily set different permissions on the folder itself from those you set on the folder’s contents: you can prevent users from renaming, deleting or moving a folder, but allow them to edit everything inside it. That’s nice!

When securing folders and the content inside them in SAS Viya, three basic guidelines to follow are:

• Secure folders, not individual objects (reports etc.) wherever possible. It’s simpler to manage, and easier to understand later. If two reports in the same folder should have different permissions, they should probably be in different folders.
• Grant permissions to groups, not individual users. It’s simpler to manage, and easier to understand later. If there isn’t a group that contains the set of users you need, either make a Custom Group, ask your Active Directory or LDAP administrator to make a new group for you, or consider using a larger existing group if that will work without granting too much access to someone who should not have it.
• Avoid prohibits, especially ‘(convey)’-ed prohibits. Try to design your authorization scheme or security model so that you grant permissions wherever you need them, to give just enough access to content, and not too much. If a group of users should have access to a folder, and some of its contents, don’t grant Read (convey) permission on the parent folder, and try to prohibit Read permission on the subfolder(s) that the group of users should not be able to see. That would initially work, but it’s poor design and will likely become an inconvenience later. Instead, grant the group Read access, not Read (convey), on the folder, and then selectively grant that group Read and Read (convey) on the contents that they should be able to see.

These guidelines give rise to some recurring patterns of access. Note that you won’t find these patterns anywhere in the software: there is no screen, or button, or command for defining and applying them. They are design concepts only. This post’s five simple general authorization patterns are as follows (click any image to enlarge it):

No Access

The default. SAS Viya does not give user access to anything unless it is directly or indirectly granted.

This pattern is of course only effective if the user or group does not have access conveyed from a parent folder. So long as it does not, your masterly inactivity on this folder’s permissions ensures it too is not accessible to this user or group. If the folder does have access conveyed for the user or group in question from higher up the folder hierarchy, remove those conveyed permissions, and grant the permissions you require (whether conveyed or not) more selectively to subfolders or to a smaller group, so that the group in question does not get access they should not get.

<Group> Read

Grants a group permission to see this object only.

When a group should have read access to an object (ideally a folder), but not the objects’ contents, apply this pattern for that group. To apply it, grant a specific group Read permission on this folder, on the left-hand side of the authorization grid (or if you are using a programmatic method to set permissions, on the object URI), and grant the group nothing on the right-hand side of the grid (or on the container URI).

The 'Group' in angled brackets is written that way because that you might use variants of this pattern for several different groups: you may use an HR Read pattern, a Sales Read pattern, or a North American Finance Modelers Read pattern, as demanded by your requirements. Substitute the name of an actual group to turn the generalised, abstract pattern into a specific concrete pattern.

<Group> Read Convey

Grants a group permission to see this object and everything inside it.

To apply this pattern, grant a specific group Read permission on this folder, on the left-hand side of the authorization grid (or if you are using a programmatic method to set permissions, on the object URI), and also grant it the Read permission on the right-hand side of the grid (or on the container URI).

<Group> Edit Contents

Grants a group permission to make changes to all of the content of this folder. When you grant permissions in the Group Edit Contents pattern, you will usually also grant the permissions in the Group Read Convey pattern too: users who edit things need to see them.

For this pattern, grant the group Add and Remove on the object itself, and grant it Update, Delete, Add and Remove on the object’s container. These permissions allow the group to add and remove objects from the folder, to modify the objects inside the folder, and to add and remove objects from any subfolders.

Usually, you wouldn’t apply this pattern on its own. If a group is allowed to edit the contents of a folder, they usually need to be able to see the folder too. So, apply this Group Edit Contents pattern plus the Group Read Convey pattern together, for the same group on the same object:

<Group> Secure

Grants a group permission to add, remove, or change permissions on this object.

To apply this pattern, grant a specific group Secure on this folder, and Secure (convey) on the container.

When you grant permissions in the Group Secure pattern, you will usually also grant the permissions in the Group Read Convey and Group Edit Contents patterns too: users who manage objects’ permissions are generally super-users, content administrators or similar, and need to be able to see and edit the things they are allowed to secure:

Using the patterns

We have seen five simple regularly-occurring general authorization system permissions patterns, and a couple of ways in which some of them are usually combined. You may have instances of each of these patterns for each of several different groups in a security model design. Let’s see how they can be applied to a fictitious folder structure for the made-up organization we use in some of our GEL Administration workshops, GELCorp:

You may notice that the symbols in this table’s cells correspond to the symbols for the patterns presented above. The white symbols show patterns of permissions that should be granted to the group in the column header, on the folder in the row header. The grey symbols show inherited permissions, to remind us that they are in effect on a folder, but do not need to be directly granted on it again.

This security model design is certainly not the only way you could choose to secure GELCorp’s folders. But I expect you can see, at a glance, how the folders are intended to be secured, even if it is not always obvious from this diagram why. Plus, if you were to follow this design for each group and each folder where a symbol appears, you would get exactly the same set of permissions we apply in our workshop.

Hopefully you would agree that this is quite an easy way to represent and the basic permissions design for a set of folders, for multiple groups!