We’re smarter together. Learn from this collection of community knowledge and add your expertise.

Golden Rules for Security Model Design (part 3)

by SAS Employee DavidStern ‎07-06-2017 05:31 AM - edited ‎07-06-2017 05:49 AM (980 Views)

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.

 

Rule 4: Where necessary, apply ACTs to deny access to PUBLIC/SASUSERS, in combination with ACTs to grant a reduced set of permissions to explicit groups

 

Detail

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 PUBLIC and SASUSERS Denied ACT
  • The SAS Administrators ACT,
  • Select other ACTs to grant permissions for select other groups

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).

Explanation

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.


1.png

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:

  • Rule 1: Only use ACTs, never ACEs
  • Rule 3: ACTs only grant access to explicit groups, never deny

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.

 
2.png
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:

    • The PUBLIC and SASUSERS Denied ACT. This, on its own, denies ALL permissions for ALL users. Hint: do not apply this on its own! If you do, only an Unrestricted User will be able to see the object and its children!

    • The SAS Administrators ACT. This grants back the necessary minimum permissions SAS Administrators should have on all objects, and grants RM to SAS System Services which requires RM on every object.

      • Note: There is a now conflict between the PUBLIC and SASUSERS Denied ACT above which denies RM (and all other permissions) to SAS Administrators, and this ACT which grants RM (and other permissions) to SAS Administrators. However, the conflict is safely resolved in favor of the grants from this ACT, because they are for an explicit group (SAS Administrators), and the denies are for implicit groups (SASUSERS and PUBLIC). The explicit SAS Administrators group is closer to the user in his or her identity hierarchy than the implicit groups, and all else being equal (permissions from two ACTs applied directly to the same folder), the permission for the closest group to the user in the identity hierarchy wins. The identity hierarchy is discussed in the SAS 9.4 Security Administration guide.
    • The Group A ACT which grants RM (among other permissions) to Group A. Again, the conflict between the grant in this ACT and the deny in the PUBLIC and SASUSERS Denied ACT is resolved in favor of the grant in this ACT, because an explicit group (Group A) is closer to the user in his identity hierarchy than an implicit group (SASUSERS or PUBLIC).

 

3.png

 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.

 

Rule 5: Always Apply the SAS Administrators ACT when PUBLIC and SASUSERS are denied access

 

Detail

Apply this rule in conjunction with Rule 4. Always apply both the SAS Administrators ACT and the PUBLIC and SASUSERS Denied ACT together.

 

Explanation

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.

Contributors
Your turn
Sign In!

Want to write an article? Sign in with your profile.


Looking for the Ask the Expert series? Find it in its new home: communities.sas.com/askexpert.