Oh, no!!! Where did my SAS Viya content go?
In our SAS Viya administration classes, we always talk about security. We stress the precedence of the implicit prohibit for Authenticated Users being the lowest and the explicit prohibit being the highest in the Viya General Authorization. That inevitably leads to the question from the students,
"How do you recover if someone accidentally applies an explicit prohibit setting on the read permission for the Authenticated Users group to an object?"
Fortunately, I have a solution for them and do that as a demonstration after they complete their exercises. A summary of that solution follows.
General Authorization Review
As a refresher on General Authorization, you can see here the precedence I mentioned above.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
An implicit prohibit for the Authenticated Users group is applied by default to objects like folders, reports, data plans, etc. That implicit prohibit has the lowest precedence and can be easily overridden with an explicit grant for other users or groups. An explicit prohibit has the highest precedence and cannot be overridden by an explicit grant. Explicit prohibit rules have absolute precedence. If the explicit prohibit setting is applied to the Read permission for the Authenticated Users, the object still exists in Viya but no one knows it's there. Even the members of the SAS Administrators group are unable to see it because they are also Authenticated users.
How did we get here in the first place?
The scenario described above is more likely to happen if you are applying authorization settings using the sas-viya CLI vs. SAS Environment Manager. There are a couple of warnings in Environment Manager that alert you that prohibiting the read permission for the Authenticated Users group will have dire consequences.
When you use the CLI, you enter the command and run it. There is no analysis of the command to determine what actions are being performed. There are no warnings issued that tell you something bad is about to happen.
$ sas-viya authorization prohibit -permissions read -object-uri /reports/reports/4df447b6-5e38-417c-b8e6-548af9ab44fe/** authenticated-users
Id 4cacbff2-3fbf-473c-8fe6-d1f64322aff0
ObjectUri /reports/reports/4df447b6-5e38-417c-b8e6-548af9ab44fe/**
ContainerUri
Principal
PrincipalType authenticatedUsers
Type prohibit
Permissions [read]
The authorization rule has been created.
Don't just break the rules...Delete them
Notice the last line in the output of the sas-viya command above. The good news is an authorization rule is created when authorization settings are applied to an object. If adding the rule makes the object unavailable, then removing the rule will make it available again. All you have to do is find it. Fortunately, there's a Rules page in SAS Environment Manager to manage the rules. There's also the authorization plug-in for the sas-viya CLI. Either can be used to locate the rule and delete it.
That brings us back to the students' question..."How do you recover if someone accidentally applies an explicit prohibit setting on the read permission for the Authenticated Users group to an object?"
Solving with SAS Environment Manager
SAS Environment Manager is probably the easiest way to resolve the issue so let's start there. Select the Rules page and,
- Filter on the Authenticated Users Principal
- Filter on the Prohibit Setting
- Click Apply to see the results
- Find the rule on the right and select it
- Delete it
The object will once again be accessible. Note, it may be useful to add the Date Created column to the view to help further identify the rule.
Solving with the sas-viya CLI
When using the sas-viya CLI, you may not know what the object URI of the missing object is. That means all prohibit rules must be found. There are some default prohibit rules used to secure the environment in addition to what's been created by accident. To view all the prohibit rules run this command.
$ sas-viya -output text authorization list-rules | grep prohibit
483325f0-6201-4f57-ab14-8518cb77cb46 /batch/jobs everyone prohibit [create]
0976699c-9b60-443b-ab6d-5897e92b1960 /batch/jobs everyone prohibit [create]
8d902037-d652-4533-9508-71093da807eb /compute/sessions/*/*/** SASAdministrators group prohibit [delete update create read]
946d9bbc-cba5-11e7-abc4-cec278b6b50a /** authenticatedUsers prohibit [create read]
450be992-48c5-4e14-bfb0-47d142059176 /folders/folders/8af48321-d89c-4522-9557-079bce15edce/** authenticatedUsers prohibit [delete update add secure create remove]
4cacbff2-3fbf-473c-8fe6-d1f64322aff0 /reports/reports/4df447b6-5e38-417c-b8e6-548af9ab44fe/** authenticatedUsers prohibit [read]
b6767b79-1ce1-436c-a513-bdd5bb2ef9ce /identities/groups/** authenticatedUsers prohibit [update create]
bbef4a18-34f8-4529-b39a-e1eb5cd9bb70 /identities/groups/** authenticatedUsers prohibit [create]
a5d1b321-b22a-4bf0-b07b-bb63443c7490 /identities/groups/SASAdministrators everyone prohibit [delete]
72f043a5-3c45-41ed-9365-d81d758b5bb2 /folders/folders/16d6016b-ca0a-438a-b502-538742bef506/** authenticatedUsers prohibit [delete update add secure create read remove]
d2c515d4-793b-4e91-b13a-a27bcc5a0dee /** authenticatedUsers prohibit [create read]
It is important to get the output in text format versus JSON to ensure all the properties of the rules are captured. JSON output is spread across multiple lines and won't list the object URI, permission, etc. Once again, identify the rule in the list, here 4cacbff2-3fbf-473c-8fe6-d1f64322aff0. The object URI is needed in the CLI command to delete the rule. Copy and paste it into the command below.
$ sas-viya --output text authorization remove-rule --id 4cacbff2-3fbf-473c-8fe6-d1f64322aff0
Rule 4cacbff2-3fbf-473c-8fe6-d1f64322aff0 removed.
The object will once again be accessible.
