This time, we'll look at the most important Golden Rule for Metadata Security Model Design. If you missed the first post in this series which covers the first two Golden Rules, you may wish to read that before this one.
The first six of these eight Golden Rules closely follow those developed by Johannes Jørgensen and Cecily Hoffritz of SAS Denmark, in their paper ‘Metadata Security in SAS® 9.4 – Step-by-Step’. I have included their work in an overall GEL Recommended SAS 9.4 Security Model Design approach, which I recently published in the SAS Community Library - here are part 1 and part 2. There are eight rules, and this time we'll cover the first two.
Rule 3: ACTs only grant access to explicit groups, never deny
This is the most important rule of all
Detail
It is absolutely strictly forbidden for an ACT to deny any permission to any group except PUBLIC or SASUSERS.
You may deny (or grant) any permission to PUBLIC or SASUSERS in an ACT without breaking this rule.
Explanation
Following this rule guarantees that your security model cannot suffer from permission conflicts. Avoiding permission conflicts is a good thing.
A permission conflict occurs when two or more access controls with conflicting settings (at least one grant and at least one deny), for an effective permission such as read metadata, apply to the same object for a particular user. The word effective is important – permission conflicts can and frequently do occur as a result of permissions inheritance through a group hierarchy, or through an object hierarchy.
Permissions conflicts usually occurs when:
- A user is a member of two or more groups, at least one of which effectively grants the user a permission on an object, and at least one other of which effectively denies them that permission on that object. The user may be in more than two groups, so there can be more than one conflicting grant and/or deny for the same permission. The groups may be organized in a hierarchical structure and conflicting effective permissions can originate from any of the groups in that hierarchy.
- The object for which the permission is being evaluated is in a hierarchical structure, and inherits permissions from one or more parent objects (e.g. folders).
- Two or more ACTs are applied to the object itself, or to any parent of the object, one granting the user or a group to which the user belongs the permission and one denying it.
Permissions conflicts can occur in other ways too: follow this rule to avoid them all.
SAS has a very fast and robust permissions resolution engine, that determines if the grant or deny ‘wins’ according to a clear, well-documented but necessarily complex set of rules, which cover all possible precedence and inheritance situations including all the situations described in the paragraph above.
But that complexity is a big problem which you must seek to avoid.
When there is a permission conflict, to figure out whether SAS will grant a permission on an object for a user or deny it, you must know about and consider each grant or deny of that permission which could affect the object in question, and determine which of them takes precedence.
You have to consider the group hierarchy, which allows membership of multiple groups directly, and multiple inheritance paths from multiple parent groups. You have to consider the entire object hierarchy. Then, you must consider that ACEs take precedence over ACTs, which take precedence over permissions inherited from parent objects. ACTs and ACEs can be applied for multiple groups of which the user is a member. The rules SAS follows to determine how the conflicting permissions should be resolved are clearly defined, but are complex, and can be exceptionally difficult for an administrator to follow. Few experienced SAS administrators understand the rules well enough to correctly predict whether the grant or deny will ‘win’ in even simple scenarios.
If you follow Rule 3 (“ACTs featuring explicit groups (not PUBLIC or SASUSERS) may only grant access, never deny”), it does not matter whether a user is a member of one group or many groups. The effective permissions that user has on an object are much easier to understand. Simply look up the object hierarchy to determine the level nearest to the object at which PUBLIC and/or SASUSERS are denied a permission. The user’s permissions are the sum of any permissions granted by other ACTs at that level of the hierarchy or below.
This rule is also one of the more difficult to comply with. It can be very tempting to check a deny checkbox in an ACT or worse, in breach of Rule 1 check a deny checkbox in the Authorization tab of an object or folder, to compensate for a group having unwanted access to a specific resource. But if you break this rule, you will sooner or later cause yourself, your colleagues or your successors a real headache.
If you need to deny a group permissions some levels down inside a folder structure, start again. Rule 4, which we will look at next time, explains how to do this without breaking Rule 3. We will also cover Rule 5, which ensures you don't remove Administrator access to metadata when you deny it to everyone else. See you then!
