The right way and the wrong way to limit access to SAS Environment Manager
A consultant called me from a customer site to explain that he had accidentally stopped all authenticated users including SAS Administrators from using SAS Environment Manager. There was now no-one left who could use the Rules page in SAS Environment Manager to remove the 'prohibit' rule which was causing the problem.
Oops!
The consultant had correctly guessed that there would be a way to let themselves get back in using the sas-admin CLI. But he or she wanted a little help to do it and to avoid making things any worse.
This particular mistake will probably be fairly common, especially while many of us are new to SAS Viya's General Authorization system. So I think it's worth explaining what happened, how to fix the immediate problem of being locked out, and suggest a better way to achieve the original aim.
The SAS Viya General Authorization system is very different from the SAS 9 Metadata Authorization system. One of the most interesting differences is that it provides the SAS Administrator with several ways to lock themselves out of part or all of their own system! Fortunately, there are several suitably secure ways for an administrator to let themselves back in, so while it may initially be a heart-stopping moment when you realise you locked yourself out, there will almost certainly be a way to get back in - possibly several ways.
Limiting Access to SAS Environment Manager: the wrong way
In this case, the consultant wanted to prevent end users except SAS Administrators from using SAS Environment Manager at all.
I do not think it is necessary to remove general all-user access to SAS Environment Manager at most customer sites. But it is supported, according to this list of Selected Rules That Affect Access to Functionality. Looking at the rules which govern access to SAS Environment Manager, the consultant noticed:
❶ There is an out-of-the-box rule granting SAS Administrators access to all the pages in SAS Environment Manager (/SASEnvironmentManager/**)
❷ Another rule grants Authenticated Users access to the top level of SAS Environment Manager (/SASEnvironmentManager/)
❸ Several more rules grant Authenticated Users access to certain pages in Environment Manager, but not all of them
Figure 1 - Rules managing access to SAS Environment Manager (click to enlarge)
The consultant reasoned (correctly) that to prevent most users from accessing SAS Environment Manager, he or she needed only to prevent users from accessing the top level of SAS Environment Manager, so that they would not see the button on their navigation menu.
So, using the Rules page in SAS Environment Manager, he or she modified rule ❷, which grants Authenticated users access to the top level of SAS Environment Manager (/SASEnvironmentManager/). He or she changed this rule to prohibit Authenticated Users from accessing the top level of SAS Environment Manager instead, reasoning that rule ❶ above (which grants SAS Administrators access to all the pages in SAS Environment manager) would still work.
When you do this, you get a dialog asking 'are you sure?', which ought to make you stop and think for a moment. The exact problem is explained in this dialog:
Figure 2 - Prohibit Access 'are you sure?' dialog
Disregarding that warning and clicking OK, rule ❷ now looks like this:
Figure 3 - Authenticated Users are going to be prohibited access to SAS Environment Manager
We should really change the description of the rule too, since it no longer allows access, it prohibits access.
Initially everything looks okay - your permissions to access SAS Environment Manager are evaluated when you first access it, and are cached for a short time, so we don't immediately get locked out:
Figure 4 - Modified rule - access to SAS Environment Manager is going to be prohibited to all users (click to enlarge)
However this change doesn't produce the intended result, for two reasons:
- SAS Administrators are authenticated users too.
- A prohibit always beats any grants in the general authorization system where a grant and a prohibit both apply to the same resource for the same user: Prohibit always wins.
After the SAS Administrator logs out, nobody, not even the SAS Administrator, can use SAS Environment Manager. This also means nobody can use Rules page to undo this change.
Figure 5 - Nobody can access SAS Environment Manager (click to enlarge)
Uh-oh. This is going to make finishing the implementation project more difficult.
At this point the consultant realised his or her mistake and its root cause, and asked for help.
Restoring access to SAS Environment Manager
The good news is that we can resolve this impasse using one of the best bits of SAS Viya: the sas-admin Command Line Interface (CLI). In this case, we'll use the General authorization plug-in.
To use the sas-admin CLI you need a shell session running on a SAS Viya host in the [CommandLine] host group for your deployment - in other words, one of the hosts where the Viya command line tools are deployed. You'll need to log in to that host as a user who has access to the filesystem directories containing the SAS Viya Command Line tools, such as 'sas' or 'root'. I am illustrating this post using a collection of hosts in SAS's RACE environment, for which I have root access, but you absolutely don't have to be root to do this.
First, we need to authenticate as a SAS Administrator (who has permission to modify the problem rule), using the authentication plugin for the sas-admin CLI. There are several SAS Administrators in this environment, and I'm using one called geladm:
/opt/sas/viya/home/bin/sas-admin auth login --user geladm --password xxxxxx
[root@intviya01 ~]# /opt/sas/viya/home/bin/sas-admin auth login --user geladm --password xxxxxx
Enter credentials for http://sasviya01.race.sas.com:
Login succeeded. Token saved.
[root@intviya01 ~]#
Now we can use the authorization plugin for the sas-admin CLI to list all rules in a text output format (rather than a more verbose JSON format), and use grep to find the rules which target SAS Environment Manager.
/opt/sas/viya/home/bin/sas-admin authorization --output text list-rules | grep SASEnv
In the results, we see the same rules that we saw in the filtered view of the Rules page in Environment Manager, which is reassuring. They are not necessarily in the same order, but in this case it seems that they are, and the prohibit rule is the second from last in the list:
[root@intviya01 ~]# /opt/sas/viya/home/bin/sas-admin authorization --output text list-rules | grep SASEnv
278f2ecc-1a48-485a-8b88-1efade65416d /SASEnvironmentManager/** SASAdministrators group grant [read]
953a133b-8a82-456a-99c4-bf7119f03ae9 /SASEnvironmentManager/dashboard Administrators authenticatedUsers grant [read]
1f714fa1-ab6d-4ee7-a4cf-24c4ca3bc342 /SASEnvironmentManager/content SASAdministrators authenticatedUsers grant [read]
9f0c7f1a-5d4b-4db1-aef3-58e1845f67f9 /SASEnvironmentManager/data SASAdministrators authenticatedUsers grant [read]
26d5e0e7-7f54-4821-83e8-babc7b193cec /SASEnvironmentManager/servers sasapp authenticatedUsers grant [read]
de1159c9-47cd-493e-9c3b-62df8afb24a2 /SASEnvironmentManager/credentials sasapp authenticatedUsers grant [read]
6e966869-a463-4e96-8270-2077557c54f8 /SASEnvironmentManager/ sasapp authenticatedUsers prohibit [read]
2994f5f6-c0a8-4694-b2f5-80c8e42f3549 /SASEnvironmentManager/jobs SASAdministrators authenticatedUsers grant [read]
[root@intviya01 ~]#
The rule IDs in my environment will be different from yours. Here, the rule ID of the prohibit rule causing our problem is 6e966869-a463-4e96-8270-2077557c54f8.
Now we can update this rule, to change it from a prohibit back to a grant, so that it grants all Authenticated Users access to /SASEnvironmentManager/. Again, remember you need to substitute the rule ID of the offending rule in your deployment, in place of the rule ID in mine:
/opt/sas/viya/home/bin/sas-admin authorization update-rule --id 6e966869-a463-4e96-8270-2077557c54f8 --grant --authenticated-users
[root@intviya01 ~]# /opt/sas/viya/home/bin/sas-admin authorization update-rule --id 6e966869-a463-4e96-8270-2077557c54f8 --grant --authenticated-users
{
"description": "Allow access to an application.",
"id": "6e966869-a463-4e96-8270-2077557c54f8",
"mediaType": "",
"modifiedBy": "geladm",
"modifiedTimestamp": "2018-10-04T13:28:02.220Z",
"objectUri": "/SASEnvironmentManager/",
"permissions": [
"read"
],
"principal": "",
"principalType": "authenticatedUsers",
"reason": "",
"type": "grant",
"version": 10
}
The rule has been modified.
[root@intviya01 ~]#
And now our SAS Administrator (and everyone else) can get back in to SAS Environment Manager:
Figure 6 - We can access SAS Environment Manager again (click to enlarge)
So, what would be a better way to reduce the number of people who can use SAS Environment Manager, if that is something you determine is appropriate for your customer and their authorization model?
Limiting Access to SAS Environment Manager: the right way
Again, I want to be clear that I do not think it is necessary to remove this general all-user access to SAS Environment Manager at most customer sites.
But suppose you felt absolutely compelled to, what is a good way to do it? Simple. You want to:
- Effectively not grant but also not prohibit access to /SASEnvironmentManager/ for Authenticated Users
- In the SAS Viya General Authorization System, access to any resource is by default not authorized, and will only be authorized if there is at least one rule granting access, and no rules prohibiting it. We can rely on this to not authorize Authenticated Users to use SAS Environment Manager. Simply don't grant them access to it.
- The word effectively in this point is relevant when an out-of-the-box rule exists which grants something you do not wish to grant. The two most obvious ways to make rule ❷ ineffective are to:
- Delete rule ❷
- Disable rule ❷ - this option may be considered messy if you are confident you know what you are doing, but it may help you reverse the change later by simply re-enabling the disabled rule, if you change your mind.
- Grant access to /SASEnvironmentManager/ to some smaller subset of users
- If that subset of users is just SAS Administrators, there is nothing to do for the second part because rule ❶ already takes care of SAS Administrators.
- If you wish another group of users, broader than just SAS Administrators but not as broad as all Authenticated Users to get access to SAS Environment Manager, you could modify rule ❷, rather than delete or disable it. Why not modify the rule so that it grants access to /SASEnvironmentManager/ to another group, instead of to Authenticated Users? You could even call your new group 'SAS Environment Manager Users', as shown in Figure 7 below.
Figure 7 - If you wish to restrict access to SAS Environment Manager, why not create a new Custom Group called 'SAS Environment Manager Users' (id=SASEnvironmentManagerUsers), and modify rule ❷ to apply to this group instead of Authenticated Users? (click to enlarge)
Now, users who are SAS Administrators, or are members of the SAS Environment Manager Users group see SAS Environment Manager in their side menu, but users (like Hazel in the screenshot below) who are in neither of those groups do not:
Figure 8 - Hazel, who now does not have access to SAS Environment Manager, does not see a 'Manage Environment' option in the side menu (click to enlarge)
Here is the same side menu for a user called Delilah who is a member of a group called Data Managers, which I put in the SAS Environment Manager Users group in this environment:
Figure 9 - Delilah, does have access to SAS Environment Manager, and sees a 'Manage Environment' option in the side menu (click to enlarge)
The use of a new custom group, or an LDAP group if you have one which is suitable, to manage access to SAS Environment Manager is documented and supported. It also seems elegant and unlikely to confuse another SAS Administrator in future. Of course, there's no obligation for you to have any users in the SAS Environment Manager Users group, if you don't want anybody (other than SAS Administrators) to have access to it.
One more thing. You should really design your authorization model before you start implementing it.
80% of the initial effort of setting up a good security model should be spent on design and an appropriate level of documentation. About 10% of the effort is needed for actual implementation - it's comparatively quick and easy. And about 10% of the effort is required for testing, to ensure the authorization model really does what you intended.
I hope this was useful!
Hi @akcoray, if I understand you correctly, the permissions you describe are not the default. It looks like someone may have changed the default authorization rules without completely understanding how they work.
However, you can most likely fix it, by finding the authorization rules that have been modified or added. It may only be a small number. Which version of SAS Viya are you using? In SAS Viya 4, in SAS Environment Manager signed in as a user who is in the SAS Administrators custom group, first go to the Content page. In the content page, right-click any folder, and choose View Authorization. Then look at the names of the permissions along the top for the one you are interested in, e.g. Read for the permission to see a folder, or Update for the permission to change it's name, or Read (Convey) for the permission to see objects inside the folder and so on.
Next, look at the Principals down the left of the authorization dialog, and find Authenticated Users, or another group or user, and click in the cell in the table that is the intersection of that row and the column for the permission you chose, and which shows a symbol for the authorization decision that would be made for that permission for that user, on the selected folder..
A dialog appears, and if you click on the Contributing Rules tab of this dialog, you can see which rules contributed to the authorization decision. This usually isn't a very long list - often just one or two rules. From that list you may be able to see what's causing the odd permissions behavior.
A small number of rules created out of the box during deployment use Prohibit settings to stop users accessing certain things, but the vast majority only grant permissions. Look for rules where the setting is Prohibit (or just possibly, Conditional Prohibit). Do they target a folder? If so, there is a good chance that they are causing or contributing to a permissions issue. See my YouTube Video for examples of good permission patterns - none of them use a Prohibit setting in an authorization rule: (708) SAS Demo | Simple General Authorization Patterns in SAS Viya - YouTube
Alternatively, still in SAS Environment Manager, go to the Rules page. There, click on the Manage Columns button top right:
Add the Date Modified column. Unfortunately you can't currently sort the rules in this table by their column headings, but you can at least see that the great majority of the rules were created at the about same time on the same date. This would be when your instance of SAS Viya was deployed. Then, you can filter the rules for ones edited since that date.
That should be a much smaller list of rules. If you right click a rule that targets a folder in its Object URI or Container URI fields, you should be able to see the name of the folder that corresponds with either or both of those URIs. That might also help.
