Permissions on folders in SAS 9 and SAS Viya (part 2)

[#1]

In Part 1 of this article, I wrote about the permissions you would set in SAS 9 and in the SAS Viya general authorization system to grant users various degrees of access to a folder itself and the folder's contents.

That post ended with a note of caution: if your SAS 9 deployment is secured following good practices and practically all permissions are set via Access Control Templates (ACTs), then at present almost none of those permissions can be promoted 'automatically' when you promote your existing SAS 9 folders, reports, jobs and other content to SAS Viya 3.4. Only direct Access Control Entries (ACEs) are promoted, and we have long advised against using ACEs in SAS 9. This is rule #1 of the Golden Rules of Security Model Design in SAS 9.

In this post I dive deeper into the key considerations for reproducing your SAS 9 security model in SAS Viya, which lead me to argue that you almost certainly need to design it afresh in SAS Viya. There is a lot to cover and this post is a long read, so grab your biggest mug of coffee and settle in...

What is the impact of the fact that ACTs are not promoted to SAS Viya with the provided promotion tools (at present)? It's a challenge if you implemented your SAS 9 security model using only ACTs, as we recommend. And that's not the only thing to be aware of, either...

• Deny permission settings in SAS 9 are not promoted to SAS Viya, even from ACEs. There is a good reason for this: the Prohibit setting in SAS Viya is much more emphatic and final than the SAS 9 Deny setting, as it cannot be over-ridden.
• Some SAS 9 permissions have no exact equivalent in SAS Viya: ManageCredentialsMetadata, CheckInMetadata, Administer and Execute. Analogous concepts for some of those exist in SAS Viya, but not exactly as equivalent permissions. Others apply only to data, and have equivalents in the CAS authorization system, in this post we focus on folders.
• Precedence and inheritance are different between the authorization systems in SAS 9 and SAS Viya, for both content and data.

Oh boy. Well, don't give up hope just yet. For one thing, my colleague Gerry Nelson wrote a post describing a macro- and script-based approach to Creating SAS Viya authorization from SAS 9.4 Metadata. In that post, he wrote "What if you want to export the authorization separate from the content, and then selectively apply that authorization? This is possible using code in SAS 9.4 and the command line interfaces Viya. The good news is the SAs 9.4 and Viya provide us with the tools to take an alternate approach."

Gerry's tool, available to SAS staff from SAS' internal Gitlab site (but not currently accessible outside SAS) translates permissions from one SAS 9 folder to one SAS Viya folder at a time, creating a JSON file per folder describing the permissions that should be applied in SAS Viya. It follows the same permission mappings as described in the documentation.

It was a conscious design decision to have these scripts work one-folder-at-a-time, for the reasons I am arguing in this post: you need to think about the authorization you are promoting and not just blindly automate it. We could write more scripts to recurse the folder structures in both SAS 9 and SAS Viya and manage the promotion of authorization settings for a whole folder structure at once. Gerry's tool does not have that 'recursive' capability at the time this post was written, and I don't think adding it would be the best way to reliably promote authorization settings. I would rather encourage more conscious consideration of what you are promoting, whether you really need it and how it should be secured.

It's excellent that we can promote authorization separately from the content, but the differences between SAS 9 and SAS Viya will often mean you must redesign the security model for content you move from SAS 9 to SAS Viya, to produce the intended access control in SAS Viya's general authorization system. In this post, we look at key considerations for that re-design work.

There are other good resources on this topic:

• Gerry Nelson wrote last July about transitioning from VA on SAS 9.4 to SAS Viya, which gives a high-level overview of promoting users and groups, permissions, data, folders etc. It's a good introduction to the topic, but you will want to read more than just this.
• Christine Vitron also wrote a nice article last August discussing some of the differences between folder security in SAS Viya and SAS 9.

It's authorization, Jim, but not as we know it

Let's begin this part's story with a statement of the problem we face.

As the documentation in SAS Viya 3.4 Administration > Promotion (Import and Export) explains:

Important: The SAS Viya approach to authorization is very different from the SAS 9 approach. For that reason, promotion cannot fully replicate your SAS 9 authorizations in SAS Viya. See Comparison to SAS 9 Authorization in SAS Viya Administration: Orientation to Authorization.

Important: Promotion does not process access control templates (ACTs). If you deconstruct ACTs into individual access control entries (ACEs) before promotion, promotion can process the individual ACEs that are directly set on each promoted object.

This may change in future but right now, that's how things stand.

This means you are likely to get a very incomplete facsimile of your existing SAS 9 security model during an automatic promotion of content and authorization together to Viya 3.4. You may be able to get closer to your original design if you use the macro- and script-based approach Gerry presented. But the resulting permissions will be unlikely to perfectly implement the access controls you intend users to have. So, what should you do?

If you have a relatively simple authorization model where folders (only, not other content objects) are secured with clearly-understood and simple patterns of permissions applied with ACTs, we suggest you do not promote the access controls along with the rest of your content at all. Start again, and secure your promoted content afresh in Viya. This should be simpler and lead more consistently to a well-structured end result than allowing what few ACEs exist in your model to be promoted to SAS Viya 3.4 rules, and trying to make up for the differences.

Alternatively, if you have an complex security model, or one which you do not understand fully in SAS 9, you may prefer to use Gerry's SAS macros and scripts (if you work for SAS and have access to them) or else write your own tools or scripts to a.) record the access controls applied to your content in SAS 9, b.) apply equivalent access controls to the promoted content in SAS Viya, and c.) test that the new controls grant groups and users an equivalent level of access in SAS Viya to the access they had in SAS 9. This is feasible, but likely to be a lot of work.

All this assumes that you have an existing security model in SAS 9 which you value, and want to reproduce in SAS Viya. If not, obviously just design a new security model from scratch.

But assuming you want to bring your SAS 9 security model to SAS Viya, let us consider three critical considerations for reproducing your SAS 9 security model in SAS Viya, for folders and content you migrate:

1. Principals (Users and Groups)
2. Permission mappings
3. Folder structure

Let's focus on each of these considerations in turn.

1. Principals (Users and Groups)

You need the same principals (certainly the same groups, having the same members) in SAS Viya that were used in your security model in SAS 9. If your groups in SAS 9 and SAS Viya come primarily from Microsoft Active Directory (AD) or another LDAP provider, this may be quite straightforward, but most in SAS 9 deployments I have seen, it's not as simple as that.

Generally, SAS groups are more conveniently managed (created, edited) in SAS Management Console, and stored in the Metadata Server, than managed in AD/LDAP and then synced to SAS 9 Metadata. A mix of both is common. This tends to mean you have groups which are important to your authorization model in SAS 9 metadata which are not in AD/LDAP. You will need to re-create those groups and their lists of members in SAS Viya manually or automatically somehow, if you intend to use them in your replica authorization model.

When you use the promotion tools to move your content from SAS 9 to SAS Viya, they include support for moving groups. But that would generally be a one-off move of groups, and not something you would run repeatedly.

Another way to do this (assuming you are synchronising groups and users from a single SAS 9 deployment to a single SAS Viya deployment) would be to:

1. Run SAS code to list groups and their members in SAS 9, and store the result as a CSV or .sas7bdat dataset
2. Make that CSV or dataset available to your SAS Viya deployment, using a shared directory or file copy
3.  Run sas-admin CLI commands, with the identities plug-in, to list groups and their members in SAS Viya, and store the result in a CSV or JSON file. Or you could use our pyviyatool listgroupsandmembers.py
4. Run some code - SAS would probably be best, or perhaps Python - to load in the SAS 9 and SAS Viya groups and members lists, get them into similar formats, and then find the difference between them:
   1. a. groups in SAS 9 not in SAS Viya
   2. b. groups in SAS Viya not in SAS 9
   3. c. members of each group in SAS 9 who are not in that group in SAS Viya
   4. d. members of each group in SAS Viya who are not in that group in SAS 9
5. Perhaps modify the results of step 4 to exclude a groups in an 'exclusion list' from the results - exclude groups that you do not want to be part of the sync
6. Create new groups in SAS Viya for each group in 4a
7. Remove groups from SAS Viya for each group in 4b (carefully - sense check the list of groups the script proposes to remove before it removes them!)
8. Add members to groups per the list in 4c
9. Remove members from groups per the list in 4d

I think there would be quite a lot of interest in a script, or set of scripts to do this, or something similar. It would also be useful to customers who run SAS 9 and SAS Viya deployments side-by-side, and want the same SAS groups/custom groups in both. Please let me know if you know of anyone who is doing this!

2. Permission mappings

The SAS documentation describes how some of the SAS 9 Metadata permissions on folders may be translated to general authorization rules when those folders are promoted into SAS Viya, in the SAS Viya 3.4 Administration documentation > Promotion (Import and Export). There is a similar description in SAS Viya 3.4 Administration > Permission Mappings for Content Objects. It's worth reviewing both.

Whether you are looking at these mappings to understand what will happen to permissions applied by direct Access Control Entries in SAS 9 when you promote content, or whether you are looking at them to decide how to manually reproduce your existing SAS 9 authorization model in SAS Viya, it is important to understand that these mappings are reasonable best guesses for how a SAS 9 permission equates to a SAS Viya permission. Sometimes that guess will not be what you would choose yourself.

Below is the table for folder permission mappings, copied from that last section in the documentation (correct at the time this post was published - the documentation is updated from time to time):

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

Here are the mappings for Reports from the same doc:

You can see that the mappings for reports are just a subset of the mappings for folders. Like most objects, reports only have an objectURI (so no permission mappings to containerURIs are relevant). WriteMemberMetadata is meaningless for reports in SAS 9, so there is no mapping for that permission. It's reassuring that they are consistent!

These mapping cannot be right in all situations. As we saw in Part 1 of this article, there are more degrees of 'read' and 'read-write' access than you might initially suppose: I listed five, plus 'hidden'.

Here are four examples of where the mapping might be incorrect:

2.1. ReadMetadata

SAS 9 permission: A principal (a group, or a user) is granted ReadMetadata on a folder

SAS Viya permission: A principal is granted Read on both the folder's objectURI and its containerURI

How might this sometimes be incorrect? This reproduces the SAS 9 inheritance from folder to child objects: they inherit Read permission. However, in SAS Viya, if there are any objects inside the folder that you do NOT want this principal to have Read permission, you may prefer to only grant Read on the objectURI, and not on the containerURI.

2.2 Denied permissions

SAS 9 permission: A principal is denied ReadMetadata, WriteMetadata or WriteMemberMetadata on a folder

SAS Viya permission: Nothing

When might this be incorrect? Deny permission settings are not promoted. Your SAS 9 authorization model may have relied on some deny setting to prevent users from seeing something.

Avoid using Prohibit settings in this situation, since they cannot be overridden except by removing them. Instead, grant the permissions on the parent folder only (without conveying them), then selectively grant permissions on the objects inside that parent folder which this principal should see.

2.3 WriteMetadata

SAS 9 permission: A principal is granted WriteMetadata on a folder

SAS Viya permission: A principal is granted Update, Delete and Secure on both the folder's objectURI and its containerURI

When might this be incorrect? This gives the principal the ability to rename, move, delete or change authorization settings on the folder, just as WriteMetadata did in SAS 9, and it also gives the principal the same permissions on the folder's contents.

Note the absence of the Add and Remove permissions: these would also be required to add items to the folder, or remove items from the folder.

In SAS Viya, you can separate the permission to modify a folder, from the permission to change it's permissions. You may not always want the Secure permission to be granted to this principal, on the folder and its children.

2.4 WriteMemberMetadata

SAS 9 permission: A principal is granted WriteMemberMetadata on a folder. Usually this is granted in combination with ReadMetadata (but not WriteMetadata).

SAS Viya permission: A principal is granted Add and Remove permissions on the folder itself allowing the principal to add items to or remove items from the folder. Also, the same principal is granted Update (convey), Delete (convey) and Secure (convey) (or put another way, they are granted Update, Delete and Secure on the folder's containerURI).

When might this be incorrect? The intent of this SAS 9 permissions pattern are typically to allow the principal to see the folder and modify its contents (including modifying the authorization settings on its contents), but not modify folder itself or its authorization settings.

Again, the mapping to Viya permissions is usually right, but you may not wish this principal to have the ability to change the authorization controls on this folder's contents: the Secure (convey) permission may be unwanted.

2.5 The rest...

Other SAS 9 permissions are not mapped, for folders:

• Data-related permissions (Read, Update, Select etc). applied to SAS 9 folders have no corresponding permission for SAS Viya folders, which do not contain data objects.
• CheckInMetadata has no equivalent in SAS Viya.

3. Folder structure

There is a great tip in the Permission Mappings for Content Objects, which explains:

Because authorization precedence in SAS Viya is very different from authorization precedence in SAS 9, it is a good idea to review and rethink your folder structure, rather than automatically replicating your SAS 9 folder structure in SAS Viya. The general authorization system is flexible enough to accommodate almost any folder structure, but preserving an existing folder structure is not always the cleanest and most efficient approach.

One of the main reasons for redesigning your existing SAS 9 folder structure when you move your content to SAS Viya is the difference between the SAS 9 'deny' and the SAS Viya 'prohibit' settings. This is one of the main things which that tip is referring to when it talks about authorization precedence.

Let's walk through an example to illustrate this, using a simple, generic set of groups and folders.

Group structure

For this example, we imagine an fictitious organisation, and focus on just one team in that organization, represented by the word 'Team'. Our example team has normal users (Team_Normal), and super users (Team_Super) who are the only users allowed to work with a restricted set of folders and content. SASUSERS is the implicit group in SAS 9, and the equivalent to Authenticated Users in SAS Viya:

We will consider permissions for SASUSERS, and members of the Team_Normal group who are normal SAS users in the team, and for members of the Team_Super group who are super-users in the team, allowed to see/modify restricted content.

The Team_Super group is a member of Team_Normal, so that users in Team_Super do not also need to be added to Team_Normal, in order to receive the permissions granted to Team_Normal. All users are members of the implicit group SASUSERS.

Folder structure

We will illustrate a design challenge for our promotion of folders from SAS 9 to SAS Viya using a fairly common folder structure:

The purpose of each folder, or in one case, set of folders, is as follows:

• Company: top level folder for the whole organization's content. 'Company' is a placeholder for the fictitious company's name. Contains subfolders for each team. Separates company content from SAS 9 system top-level folders.
• Team: the top level folder for a single team within our fictitious company. Other teams will have their own folder structures, but for simplicity are not shown.
• Team_General1..n is a set of one or more folders, used by all members of the Team_Normal group, for general work.
  • If n=1, there is only one such folder.
  • If n=1000, there are a thousand of them.
  • n could be any positive integer.
• Team_Restricted is a folder containing sensitive content, which only members of the Team_Super group should be able to see.
• Team_Restricted_Reports is a subfolder of Team_Restricted, likewise containing sensitive content which only members of Team_Super should be allowed to see/modify.
  Note: This customer has chosen to organise all their team folders under a corporate top level folder ('Company'), to allow them to manage permissions, perform release management operations, audit content and permissions etc. from a top-level folder. There are advantages and disadvantages to doing this: some customers will instead choose to have all the 'Team' folders for each of their teams, departments, projects, data topics etc. as top-level folders, which flattens the hierarchy by one level making it simpler for users who might otherwise question the purpose of having their content in a top-level folder named for their company. We see both in the field; you can have this folder in your structure or not. Let's move on.

Non-technical indication of permissions

As an optional step in designing or reviewing a security model, something like this can aid your thinking about who does what to which folders, in broad terms ('no access', 'read only', 'read-write'). You may create something like this as a first pass at designing an overall folder structure with your customer, before you take a second pass to consider the more detailed permissions and think about what each group should really be able to do in each folder, in SAS technical terms. Do it if you find it useful, otherwise feel free to skip this step.

We are not declaring what we mean by the permissions here, in particular what read-write actually means.

SAS 9 permissions

If you do not have very many general folders (so that n is a small number, and the set of folders labelled here as Team_Gemeral1..n is small), this would be a reasonable design for SAS 9 metadata permissions:

In the table above, cells with a yellow background at the intersection of a folder and a group represent some sort of permissions applied for that group on that folder: following our Golden Rules for Security Mode Design in SAS 9, these are always applied using ACTs.

Cells with a white background are at the intersection of a folder and group where no particular permissions (via ACTs) are applied for that group to that folder. Inherited permissions are shown in square brackets, in an abbreviated notation as presented in the table in section 8.1 Abbreviations for Names of Permissions in ACTs, in the Core Artefacts paper of the set of five papers on GEL Recommended SAS 9.4 Security Model Design.

A dash (-) means this group has no effective access to this folder - it is hidden from them.

The Stop sign represents application of two ACTs defined in the papers on GEL Recommended SAS 9.4 Security Model Design, namely the 'PUBLIC and SASUSERS Denied ACT' and the 'SAS Administrator Settings' ACT. Applying this pair of ACTs is the recommended way to 'stop all access at this point, and start again from here' in SAS 9 metadata. It is nearly always accompanied by further ACTs, granting back permissions to those groups who should have them on this folder.

The remaining boxes are explained in the key below the table: boxes with yellow backgrounds showing where ACTs are applied. Not all the permissions granted by those ACTs are shown, as it would make the table very cluttered if they were.

Why this design is more laborious to maintain if there are many general folders

Notice that the row for the set of folders labelled 'Team_Gemeral1..n' has ACTs applied to it, for what would ideally be named something like the 'Team_Normal Read Write ACT'. That ACT should grant +RM WMM R to Team_Normal, in addition to the grant of R and S members of the Team_Normal group inherit on each of these folders from the parent Team folder. But the real issue is that in this design, we apply it to every single folder in this set.

If there is exactly one of every other folder, that means that the total number of ACTs that need to be applied is something like 8+n: one for Company, three for Team - remember the Stop sign represents two ACTs, three for Team_Restricted, and one for Team_Restricted_Reports, plus one each for the n folders in the set labelled 'Team_Gemeral1..n'.

This is significant - if n=1000, that means you need to apply ACTs in 1008 places for 'Team'! That isn't fun, though of course you could script it to make things easier. But then you must create all those 'general' folders using your script.

If you have such a large number of general folders, and don't automate their creation somehow, a better solution might be to adjust your SAS 9 security model for the Team folder structure like this:

Note the difference between this design and the one above. Instead of applying a Team_Normal Read Write ACT on every single folder in the set labelled 'Team_Gemeral1..n', we apply that ACT to the parent folder, here labelled 'Team'.

At the expense of being a bit over-permissive (all Team_Normal members now get WriteMetadata on all the Team_General1..n folders, which they don't need), it reduces the number of ACTs applied to 10, irrespective of the size of n.

This doesn't impair the ability to secure the Team_Restricted folder structure, which is still made accessible as desired to members of the Team_Super group just like in the previous diagram. No changes to the folder structure were needed to make this labor-saving (or at least, script-saving) simplification to the security model design.

Replicating our security model in SAS Viya

Below is one possible interpretation of the our authorization model in SAS Viya:

As with the SAS 9 version, cells with a yellow background at the intersection of a folder and a group represent some sort of permissions applied for that group on that folder. Since SAS Viya does not have ACTs, these are rules. All the permissions granted in these rules are given using A shorthand notation for describing Viya authorization rules.

As before, cells with a white background are at the intersection of a folder and group where no particular rules are applied for that group to that folder. Inherited permissions are shown in square brackets, in the same notation.

A dash (-) means this group has no effective access to this folder - it is hidden from them.

The remaining boxes are explained in the key below the table. Because SAS Viya folders have permissions on the folder object itself, and a separate set of permissions conveyed to the folder's contents, some of these descriptions are a little wordy. I find the shorthand notation much more straightforward and concise.

Incidentally, I know some SAS colleagues use a similar shorthand where X represents 'Remove' instead of 'Re'. This has the merit of being shorter and less ambiguous, since Re could be confused with Read, were it not for the fact that in my notation the letters for the permissions are always in the same order as the View | Edit Authorization dialog in the SAS Viya visual interfaces. I've kept my version of the notation for consistency with my other posts, but I may switch to 'X' for 'Remove' after this post.

Three things are interesting about this:

• It is not the only answer possible: you could certainly make some changes, still claim it was a fair translation of the SAS 9 authorization model. In particular, you might want to include grant the groups Add and Remove permissions on folders where permissions like Update, Delete Add and Remove are conveyed to their children! Without Add permission on a folder, users cannot add new items to the folder. This is not part of the permission mapping from SAS 9 for WriteMetadata or WriteMemberMetadata! I think it might be important.
• There are rules targeting the Team_General1..n folders. This should concern you if there are a lot of them (n is large).
• There are no prohibited permissions in the design. As a rule, there should not be prohibit permissions in any good SAS Viya general authorization design.

This design requires roughly 4+2n rules to implement: one for the Company folder, one for the Team folder, 2 for each Team_General1..n folder (one targeting its objectURI, and another targeting its containerURI), one for the Team_Restricted folder (since folder requires grants of Read and Read (convey), it can be implemented as a single rule), and two for the Team_Restricted_Reports folder. That doesn't sound bad at all - it's less than the count of SAS 9 ACTs, but if this team has 1000 general folders, so n = 1000, then that's still 1004 rules. Can we do something to reduce the rule count when n is large?

SAS Viya designs when there are many general folders

We just moved one of the ACTs up a level in the folder structure in SAS 9, so that should do the trick in SAS Viya too, right? Here is what that might look like:

Here we have changed the rule targeting the Team folder's objectURI, to grant members of the Team_Normal group Read (convey), Update (convey), Delete (convey), Add (convey) and Remove (convey) on everything inside the Team folder. This is a little bit over-permissive in that it allows all members of Team_Normal to make changes to the Team_General1..n folders, which they do not really need to be able to make.

In an attempt to prevent all the non-super users in Team_Normal from seeing and modifying the Team_Restricted folders, we have denied all permissions except Secure (which was never granted to these groups) to team normal using a Prohibit rule, shown in this table as -RUDARe,-RUDARe& in red. This might be excessive, prohibiting Read alone is probably sufficient to keep all the non-super users out of the Team_Restricted folders.

However, although we then have rules to grant Team_Super the permissions they need on the Team_Restricted and Team_Restricted_Reports folders, those grants do not work. All of the effective permissions for members of Team_Super on those folders will still be not-authorized, because of the Prohibit rule on the Team_Restricted folder for Team_Normal users. Remember that Team_Super users are members of Team_Normal too, to save us from having to double the number or rules we need to apply to all the other folders in this team's structure. So, this design does not work, for the Team_Super users.

If you can see a way to make that work which I have missed, without changing the folder structure, and without granting individual rules on all of the Team_General1..n folders, please get in touch!

Lots of individual rules as in the previous table (perhaps created using scripts) would work, but is more effort to implement, and I wonder if the authorization system will run into difficulty if you create such a very large number of rules. There must be a better way, and there is.

Change the folder structure in SAS Viya

Our revised SAS Viya design moves the Team_Restricted folder up a level, so that it is directly below the Company folder, and is a peer of the Team folder, rather than its child.

The changed rule targeting the Team folder's objectURI, to grant members of the Team_Normal group Read (convey), Update (convey), Delete (convey), Add (convey) and Remove (convey) on everything inside the Team folder still acts as a single change to give access to the general folders, at the expense of being a little bit over-permissive.

But by moving the Team_Restricted folder 'out of the way' of those conveyed permissions, we avoid the problematic Prohibit, and avoid having non-super users getting access they should not have to the Team_Restricted folder. We can secure the Team_Restricted folder structure however we wish, and get the effective access we want (or only very slightly more), and this design only requires 6 rules, no matter how many Team_General1..n folders there are.

Well done if you made it this far: I should be giving you a 'like' thumbs-up below!

Hopefully this shows why, no matter the tools and scripts you use to help with the process, when moving an authorization model from SAS 9 to SAS Viya, and especially if it is large or complex, you really need to design the implementation detail of that authorization model in SAS Viya afresh. The existing model may be an excellent starting point, but it is quite unlikely to be something you can 'press the easy button' to migrate, and changes to the folder structure may be the easiest way to create a simple, efficient authorization model without an enormous number or rules.

See you next time!