The GEL team has been putting a lot of effort into creating materials for Viya-based products recently. But we have not forgotten that the overwhelming majority of our customers, and most of our current delivery projects here in 2017 use SAS 9.
So, in this article, I would like to show you a small but rather handy decision flowchart:
But what is it, and where does it come from?
I jointly presented a SAS UK & Ireland Webinar on Monday 9 October 2017, with Paul Holmes of Metacoda. The title of our talk was SAS® Security Model Design Golden Rules, Validation, and Monitoring. You can watch the recording of that webinar here, (after giving your name and contact details) and we've added the PowerPoint slides, reference links and Q&A on the follow-up post on the SAS Communities website here: bit.ly/SASUKMetacodaWebinar.
For my part of this talk, I spruced up a series of metadata security quiz questions originally designed by the now-legendary Cecily Hoffritz in SAS Denmark. Each question asks you which of two conflicting SAS 9.4 permissions would win, in a series of four different scenarios. We look at the right answers, and I then go on to explain why each answer is right. The point is to show that the explanations are maybe not so obvious as they initially seem, and that it's easy to construct even simple situations in which many experienced SAS administrators struggle to predict consistently which SAS 9 permission wins. The quiz is meant to be an object lesson in why following our Golden Rules for Metadata Security is a good idea, because they help you avoid being in those confusing situations in the first place.
Anyway, back to that decision flowchart above.
In preparing to explain why the correct answers are correct, Paul showed me a brilliant chart in the SAS 9.2 version of the SAS Intelligence Platform: Security Administration guide, which I had forgotten all about. It was like rediscovering an old friend: SAS(R) 9.2 Intelligence Platform: Security Administration Guide > Authorization > Authorization Mode.... The chart isn't in more recent versions of that document. It's not wrong - in fact, it has stood the test of time remarkably well, but it's inevitably a complex thing to explain, and for the SAS 9.3 and later security admin docs, we tried doing it without the chart. But I think it is a really clear and complete explanation of how an authorization decision is made so wanted to use it in my talk.
I must acknowledge here the work of Catherine Hitti and her team in SAS Publications, who published not just the original authorization decision flowchart which I have re-formatted here (with some minor omissions), but also the examples which I've given below. Much of this post is based on her work.
My only difficulty was that the original chart is meant for someone reading the docs by themselves, and not for presenting to an audience, some of whom may be sitting at the back of a room or watching a relatively low-resolution webinar, where it may be a little hard to see the diagram while someone narrates the flow. So, I made my own version for use in a presentation setting, and I hope Catherine and her team will forgive me for shamelessly 'borrowing' their original diagram and explanation. It may be old, but it definitely bears repeating!
My hope is that if you need to present this to a customer, using something like PowerPoint, you may find my versions of the authorization decision flowchart helpful for that format.
Let's start by explaining the symbols used on the decision flowcharts in this post:
Let's build up our version of the authorization decision flowchart in stages.
When SAS 9 determines the authorization decision for a given permission for a given user on a SAS 9 metadata item, the first thing it considers is whether there is any access control which sets that permission for that user on the item itself. If so, that access control will 'win' against any conflicting permission inherited from the item's immediate parent.
Only if there are no access controls on the item itself, are the effective permissions on the item's immediate parent used instead (i.e. inherited). If there are no access controls on the item's immediate parent, this is recursive, so SAS Metadata Server then looks at that item's parent, and so on, all the way up the tree. The permissions of 'last resort' come from the Repository ACT (Default ACT) if there is one - and there should be!
Situation: LibraryA has an explicit denial for PUBLIC. LibraryA’s parent folder has an explicit grant for the user.
Outcome: User cannot see LibraryA.
I expect everyone reading this will think it is obvious that direct permissions on the item have precedence over inherited permissions - good! But the thing to remember later on is that this step in the decision flowchart is FIRST. This means that an explicit Access Control Entry (ACE) setting a permission for the user on the item's immediate parent object will not beat an Access Control Template (ACT) setting the permission for a group of which the user is distantly a member, via several other nested groups, if that ACT is applied directly to the metadata item in question. Is the primacy of this step in the flowchart still so obvious in that situation? (Congratulations if it is!)
Note that the WriteMemberMetadata permission for a user on a parent item conveys the WriteMetadata permission from a parent item to its children, without the user necessarily getting WriteMetadata permission on the parent item.
Also, note that there are rare cases where a metadata item can have more than one parent. In these cases, a grant inherited from any one parent is sufficient to grant the permission to the user on the child item - even if the permission is denied for the user on the item's other parents. This is perhaps not intuitive, but it is so rare that I chose to omit it from my decision flowchart.
So, our remaining attention is on the various ways access controls can be set on the item itself. We will elaborate the part of the decision flowchart which deals with (potentially conflicting) access controls on the item.
If there is only one authorization setting on the item itself, then obviously that setting 'wins'. If there is more than one authorization setting, but they are all 'grant' or all 'deny' then there is no conflict - the permission is 'granted' or 'denied'.
In case there are two or more conflicting authorization settings on the item itself, the next thing SAS Metadata Server looks at is whom the authorization settings are for. Are they for the user, or for a group the user is a member of? The top green box in our decision flowchart now has two new blue boxes in it:
Either an ACE or an ACT for the user, will beat a conflicting ACE or ACT for a group to which the user belongs.
But if there are two conflicting access controls (ACEs or ACTS - at this point it doesn't matter which) which are BOTH for groups the user is a member of, then the access control for the group the user is more closely a member of will win.
Situation: LibraryA has an explicit denial for GroupA and an explicit grant for GroupAA. The user is a direct member of GroupA. GroupA is a direct member of GroupAA.
Outcome: User cannot see LibraryA.
Next, we need to expand the chart to describe what happens when two conflicting permissions are both set for the user himself/herself, or are both set for groups that the user is a member of with the same proximity (i.e. the user directly a member of both, or is indirectly a member of both groups, the same number of groups removed from each in the group hierarchy).
First, we can explain what happens when the conflicting permissions on the item are both for the user himself/herself, by expanding the top blue box in the previous flowchart into two boxes:
It's not possible to set two conflicting Access Control Entries for the user himself/herself on the same item of metadata. You can only tick one box for the user: grant or deny. That user can't be on more than one row of the Authorizations tab for the item in SAS Management Console.
But if there are two conflicting access controls for the user himself/herself, where one is an explicit Access Control Entry (ACE) and the other is an Access Control Template (ACT), the ACE wins. This is quite intuitive.
Situation: LibraryA has an ACT denial for GroupA and an explicit grant for GroupB. The user is a direct member of both GroupA and GroupB.
Outcome: User can see LibraryA.
Now suppose that the two conflicting access controls are both Access Control Templates which feature entries for the user himself/herself - this is a tie in the second blue box for 'On the item' which says "Is there an ACT whose pattern explitly grants or denies this permission to the user?"
Or, suppose that neither of the two conflicting access controls are for the user himself; both are for groups that the user is a member of, and with the same proximity in the group hierarchy. This is a tie in the the third blue box for 'On the item' which says "Is there a grant or denial that applies to the user because of his group memberships? Consider only the explicit and ACT settings that are closest to the user."
In case of a tie for two ACTs featuring the user himself, if at least one of those ACTs denies the user that permission, the authorization decision will always be Deny.
In the case of two or more permissions (which might be a mixture of ACEs and ACTs) some of which grant the permission and some of which deny it, for one or more groups which are all the same proximity to the user, then if at least one of the conflicting permissions is an explicit (ACE) grant, and none of them is an explicit (ACE) deny, then permission authorization decision will be that the permission is granted.
In any other situation where there are grants and denies from ACEs or ACTs for groups to which the user belongs at the same proximity, the authorization decision will be that the permission is denied. Examples might be two ACEs for groups the user is directly a member of: one grant and one deny. Deny wins. Or two ACTs for groups that the user is directly a member of, some grant and some deny. Deny wins. Or an ACT granting the permission and an ACE denying it for groups the user is directly a member of - deny wins.
Situation: LibraryA has an explicit denial for GroupA and an explicit grant for GroupB. The user is a direct member of both GroupA and GroupB.
Outcome: User cannot see LibraryA.
Important note: I have intentionally omitted some steps in the decision flowchart for conditional permissions. These only apply to Information Maps, OLAP Dimensions, and Row Level Security. See the original decision flow chart if you are using those things - they make the diagram a bit more complicated, and I decided to omit them because they are only occasionally used.
Now we understand the decision process, we need to distill it down to make it easier to remember, or easier to use as an quick aide-memoir. First, let's simplify the words:
This is enough to remind is how the decision flow works, though probably not enough to explain it in the first place.
Finally, we can make it smaller, so that it can fit on a slide alongside other things, or on a pocket-sized printout, while remaining
I find that this chart, despite its simplification from the original, is a really handy tool to help me remember which of several conflicting permissions on an item in metadata wins.
But still, we'd prefer not to have to use this very often. If you follow the Golden Rules for Metadata Security Design explained in part 1, part 2, part 3, part 4 and part 5 of my series on the subject, your security model should be simple and logical enough that
you shouldn't have to think about all this!
See you next time!
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.