BookmarkSubscribeRSS Feed

A shorthand notation for describing Viya authorization rules

Started ‎11-02-2018 by
Modified ‎11-02-2018 by
Views 3,903

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: 1 Access-Control-Ciphers-1024x270.png

 

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: 2 Viya-Folder-Structure-Permission-Design-for-gelcorp-v2-1024x736.png

 The coloured boxes in the tables above and below correspond, to make it easier to find the meaning of each permission setting.3 Common-Ciphers-v2-1024x269.png

 

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.

Comments

Hi @DavidStern,

 

Thank you. I am very glad to read from you again. For what respect to my preferences, please make as many and as longer posts as you want to. Always useful! It goes to my bookmarks right away.

 

I think the last link points to a internal-SAS site, because my browser cannot reach it.

 

 

Hi @JuanS_OCS, thank you! I don't see which link points to an internal SAS site; they all look like external links from what I can see. What is the text for the link which doesn't work? If you can point me towards it, I'll fix it! 🙂

Version history
Last update:
‎11-02-2018 09:43 AM
Updated by:
Contributors

sas-innovate-2024.png

Don't miss out on SAS Innovate - Register now for the FREE Livestream!

Can't make it to Vegas? No problem! Watch our general sessions LIVE or on-demand starting April 17th. Hear from SAS execs, best-selling author Adam Grant, Hot Ones host Sean Evans, top tech journalist Kara Swisher, AI expert Cassie Kozyrkov, and the mind-blowing dance crew iLuminate! Plus, get access to over 20 breakout sessions.

 

Register now!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags