Continuing our series on Golden Rules for Metadata Security Model Design, this time we'll look at Rule 4. It describes how to deny a group of users some permissions down inside a folder structure, without breaking Rule 3. Rule 4 itself is simple, but to understand it fully takes some explanation, so this is the longest post in the series.
And we also review Rule 5, which ensures you don't remove Administrator access to metadata when you deny it to everyone else.
If you missed the first two posts in this series, you should read part 1 and part 2 before this one.
I want to acknowledge the work of Johannes Jørgensen and Cecily Hoffritz of SAS Denmark, who published the first six of these eight Golden Rules in their paper ‘Metadata Security in SAS® 9.4 – Step-by-Step’. I have expanded on their work (adding two more rules, additional explanation, and much else besides) 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.
This rule covers situations where you need to reduce or remove the access one or more groups have to a metadata object (such as a folder) and its children.
Only design permissions for a folder like this when no sensible alternative exists for designing the folder structure a different way. If possible, redesign the folder structure to move a more restricted folder somewhere else so that it is not beneath a more widely-open folder. If that is not possible or would result in a confusing folder structure, it may be necessary to apply ACTs to deny broad access, and re-grant more limited access as follows.
To reduce or remove access to an object for the groups which would otherwise inherit broader access than you want them to have, apply:
The first of these is not part of the standard set of ACTs created when you first deploy SAS Metadata Server. To see its design, look at Table 1 – GEL Recommended ‘Core’ Access Control Templates to include in any security model design, in section 8.2 of the Core Artefacts paper attached to this article, for the detailed design of the first two of these ACTs. See also Rule 5 below for more on the SAS Administrators ACT and why you should apply it alongside the PUBLIC and SASUSERS Denied ACT.
If the existing ACTs featuring these groups are too permissive, create a new ACTs which grant only the permissions you want, and apply those new ACTs to the object.
Rule 4 does not conflict with Rule 3, because Rule 3 prohibits denying permissions to members of an explicit group, but in Rule 4 we apply ACTs which deny access to implicit groups only.
All users (whether authenticated or not) are members of the implicit group PUBLIC. Authenticated users are also members of the implicit group SASUSERS, and probably belong to at least one explicit group (i.e. any group other than SASUSERS or PUBLIC).
This rule defines how you should restrict access to metadata objects in your folder or object hierarchy. It allows you to grant access to a more limited group or set of groups, and ‘hide’ the metadata object and its child objects from all other groups.
To explain this rule, let’s consider a permission such as ReadMetadata (RM), granted or denied for an object such as a metadata folder. The rule applies in exactly the same way to any permission on any object, but we will use this example because it is simple and easy to follow. In this example, suppose that two groups, group A and group B, have inherited (grey) a grant of RM on the folder, but we only wish group A to have RM, and we want RM to be denied for group B. In this example, there is a Group A ACT which grants RM (among other permissions) to Group A. There is also a Group B ACT which grants RM (among other permissions) to Group B.
Figure 1 – A folder intended for Group A only is beneath a parent folder that is accessible (i.e. it has Read Metadata permission granted) to Group B as well as to Group A
But we do not wish Group B to have Read Metadata permission on ‘folder for Group A only’. The simplest way to prevent Group B from reading the content of that folder would be to explicitly deny Group B Read Metadata on that folder. But doing that would break two of our golden rules:
So, we will solve this problem using an ACT. And we won’t create or use an ACT which denies Read Metadata (or any other permission) to Group B.
The correct way to meet to our requirement to effectively deny Group B access to the ‘folder for Group A only’ involves a PUBLIC and SASUSERS Denied ACT and a SAS Administrators ACT, both defined as shown in the paper Recommended SAS® 9.4 Security Model Design: Core Artefacts, in section 8.2 Recommended Core Access Control Templates. The figure below only shows the Read Metadata grants in these ACTs, to avoid the figure becoming unnecessarily complicated. Many other permissions besides Read Metadata are set in the complete definitions of these two ACTs.
Figure 2 – Partial representations of a PUBLIC and SASUSERS Denied ACT, and a SAS Administrator Settings ACT, showing only the Read Metadata permissions they deny and grant. You should also apply the SAS Administrator Settings ACT wherever you apply the PUBLIC and SASUSERS Denied ACT.
Rule 1 says we must not explicitly apply an ACE on this folder to deny RM for group B.
Rule 3 says we must not deny RM to group B in an ACT, and apply that ACT to the folder.
Instead, to remove the inherited RM permission for group B, leaving it intact for group A, we apply:
Figure 3 – In this illustration, three more ACTs (highlighted in orange) have been applied to ‘folder for Group A only’, with the result that Group A still has access to that folder, Group B does not, and none of the golden rules of security model design have been broken.
This leaves the folder accessible by SAS Administrators, SAS System Services and Group A as intended, but inaccessible (RM is denied) for members of Group B, as intended.
Of course, in this simplified example, in addition to the PUBLIC and SASUSERS Denied ACT and the SAS Administrators ACT which effectively set the permissions on a folder back to a minimum, we only added the Group A ACT back to ‘re-grant’ access to the folder to that group. In real customer SAS deployments, there may be more than one group which needs to be ‘re-granted’ access when you ‘start again’ by applying the PUBLIC and SASUSERS Denied ACT and the SAS Administrators ACT. You may have to apply several additional ACTs to the same folder to restore the desired permissions.
As you can see, the logic for determining effective permissions on an object for a user is somewhat complex. Follow rule 4 to avoid having to resolve the complex inheritance and precedence logic in your head (and to avoid SAS having to resolve that same logic in metadata) in order to determine who wins in the event of conflicting grant and deny permissions effective on an object for a particular user! Rule 4 allows you to deny access to a folder, without breaking rules 1 and 3, and while keeping the logic simple and easy to follow.
Apply this rule in conjunction with Rule 4. Always apply both the SAS Administrators ACT and the PUBLIC and SASUSERS Denied ACT together.
While Unrestricted Users are not subject to metadata permissions, all other users including members of the SAS Administrators group are. If you deny access to an object and its children to PUBLIC and SASUSERS, there is no magic rule built in to SAS which grants access back to SAS Administrators. You must do it yourself: always apply both the SAS Administrators ACT and the PUBLIC and SASUSERS Denied ACT together.
This is illustrated in the figures for Rule 4 above.
The series continues next time, in a (mercifully) shorter post, when we look at Rule 6. I hope you'll come back for that one.