A shorthand notation for describing Viya authorization rules
Many followers of the SAS Communities site wish my posts were shorter. A few would prefer I didn't post at all. Today they're out of luck, but I'll try to be brief and show you how you can too, using a shorthand notation for describing Viya authorization rules.
We encourage SAS administrators who are responsible for authorization (permissions) to document their security models as they design and update them. The idea is that someone else could implement and maintain the security model if the current administrator was not around, and critically that someone else can learn why it was implemented this particular way.
But anyone who has documented a real authorization model will tell you it can be tedious to write, and to read. Long lists or tables of permissions settings applied to objects for groups don't make for very interesting reading. So you can at least be merciful to the poor reader and keep them as short and clear as possible.
While working a few months ago on the authorization sections of an internal SAS implementer's workshop for Viya 3.3, I decided to practice what I preach. I documented key parts of the security model which students implement during the administration chapters' hands-on exercises, in the attached file 'Highlights of Security Model Design for GELCorp v2.docx'.
In doing so, I noticed that we don't seem to have a notation for describing what permissions should be (or have been) set on folders and other objects in Viya.
SAS 9 notation
Descriptions of SAS 9 metadata permissions are nearly always given in shorthand notation, and I've seen several variants of one. The table below contains an example where '-' means deny, '+' means grant, 'all' means all permissions, 'RM' means Read Metadata, 'WM' means Write Metadata and so on:
| Default ACT (Repository ACT) | PUBLIC: | -all |
| SAS Administrators: | +RM,WM,WMM,CM,A | |
| SAS System Services: | +RM,WM | |
| SASUSERS: | +RM,WM,CM |
I didn't invent this notation, but you can see lots more examples, with a full explanation in my papers on Recommended SAS 9.4 Security Model Design. Look for Chapter 8 'Access Control Templates' in the Core Artefacts, Data Integration or Visual Analytics papers. They use 😧 for deny instead of '-' and G: for grant instead of '+', but otherwise the notation is similar.
Viya Authorization Rule Ciphers
This is great for SAS 9, but I have not yet seen a Viya security model design from the field which uses such a shorthand notation. Perhaps some trailblazers who are administrators for permanent production Viya implementations big enough to justify the effort have already invented a notation for general authorization rules. I'd love to see one; please do tell me about yours! But since I haven't seen one so far, here is mine:
Note: a variation of this which I have seen colleagues use has 'X' for 'Remove' instead of 'Re', so a grant of all permissions directly on an object is written +RUDSAX.
Rather than describe my notation in full (I am trying to be brief), let me illustrate it with a couple of examples:
The coloured boxes in the tables above and below correspond, to make it easier to find the meaning of each permission setting.
If you already know a bit about General Authorization rules in Viya, I expect the tables above are fairly intuitive. This notation is meant as a shorthand between a writer and reader who know General Authorization already. The shorthand 'ciphers' are meant to encode the information succinctly, but are not meant to be cryptic and hard to understand. But if you are confused (and curious enough), I wrote a fairly detailed explanation in these ciphers in the attached 'Highlights of Security Model Design for GELCorp v2.docx'.
It's obvious to a reader who really does know General Authorization that some fine details of general authorization rules cannot be adequately represented with these ciphers - for example the nature of any conditions in the rules, whether the rules are disabled or enabled (assume they are all enabled) and likely some other fine details. I haven't tried a version for CAS access controls yet. Is there an audience for that? I guess there would be, but do let me know.
And please let me know if you think this has been done already, and better than here, or if you find this notation useful.
