BookmarkSubscribeRSS Feed
☑ This topic is solved. Need further help from the community? Please sign in and ask a new question.
Mushy
Quartz | Level 8

Hi All,

 

Following is the screenshot of an example where an effective control is added 

Mushy_0-1675254449270.png

Could someone explain the sentence "A new explicit control is added on top...."

because I see ultimately the user/group gets the same access when added on top?

What is the actual difference when we have the right tick with "grey" highlight, "green" highlight and "no" highlight?

 

Let me know if you need more information.

 

 

Thanks

Mushy

 

1 ACCEPTED SOLUTION

Accepted Solutions
PaulHomes
Rhodochrosite | Level 12

@Quentin has already explained it well but I might add another couple of points, some examples, and direct you to a blog post and documentation that might help you discover more detail.

 

I think the complexity around SAS 9 metadata security comes from the interplay of 3 different things: the type of access control (ACT or ACE/Explicit); the object inheritance path, a set of parent objects, any of which may have had access controls (of either type) applied, from which the object of concern may indirectly inherit; and the identity hierarchy, a set of groups the user is a member of (including nested groups), which may have been used in access controls anywhere in the object inheritance path. All of those 3 things plays a role in determining the precedence of access controls and permissions. As already mentioned, a green checkbox means the direct setting comes from an ACT, applied directly to the object of concern. A white checkbox means the direct setting comes from an ACE (explicit permission) applied directly to the object of concern. A grey checkbox means it is indirect - it may come from an ACT or ACE on a parent object (inheritance path), or it may have come from another ACT or ACE on the same object but from a parent group (identity hierarchy).

 

I thought some examples might help in trying to further answer your question on why might you change a green (ACT) or grey (Indirect) allow to a white (ACE) allow? As Quentin said, it would be to add a higher precedence permission. You are more likely to change a green/grey deny to a white allow but it is possible to change an allow to an allow too:

 

Example 1 (replace grey tick with white tick): if you have a grey (Indirect) ReadMetadata grant for the SAS Administrators group on an object you might change it to a white (ACE) ReadMetadata grant on the basis that someone (maybe you in a later step) was to add a white (ACE) ReadMetadata deny for the PUBLIC group on the same object. In the absence of the SAS Administrators ACE grant, the PUBLIC ACE deny on the same object would have higher precedence than the SAS Administrators Indirect grant. Every member of the SAS Administrators group is a member of PUBLIC too, so we add the SAS Administrators ACE to override the (future) PUBLIC ACE and ensure SAS Administrators maintain access.  NOTE: that if you were to do it the other way round and add the PUBLIC ACE deny first you would then see the SAS Administrators checkbox was now grey (indirect deny from another group in the identity hierarchy) and so you would then be changing a grey (Indirect) deny to a white (ACE) grant for SAS Administrators group.  For this strategy (wide deny, narrow grant back) I would actually recommend doing it through ACTs rather than ACEs - see the golden rules mentioned in the blog post below.

 

Example 2 (replace green tick with white tick): This one is more contrived, and not something you would encounter if you follow best practices, but it does show what is possible and if it is possible then it needs to be understood and potentially handled. To set up this example create 2 groups, Group A and Group B, and add the SAS Demo User as a direct member of both groups. Now create 2 ACTs: Grant A and Deny B. In the Grant A ACT add Group A and grant ReadMetadata, then in the Deny B ACT add Group B and deny ReadMetadata. Now create a top level folder and apply both the Grant A and Deny A ACTs to that folder. In the Authorization tab for that folder you will now see a green (ACT) grant for Group A and a green (ACT) deny for Group B. Now to visualize this, add the SAS Demo User into the Authorization tab and remove the automatic white (ACE) ReadMetadata grant for them. You will see a grey (Indirect) deny for ReadMetadata due to the conflict in the 2 ACTs. Now go to the Group A entry and tick the green (ACT) grant to add a white (ACE) grant (the example we are after). Go back to the SAS Demo User and you will see the grey (Indirect) permission for ReadMetadata is now a grey (Indirect) grant due to the higher level precedence ACE you just added. As I mentioned, this is a contrived example and if you follow best practices (the golden rules) and only ever deny permissions to PUBLIC or SASUSERS then this type of scenario should not occur.

 

I hope these examples helped. I would thoroughly recommend reading a blog post by @DavidStern at https://communities.sas.com/t5/SAS-Communities-Library/Which-SAS9-Permission-Wins/tac-p/560050 which contains links to other helpful articles. It also steps you through a great flow chart from some older SAS documentation that I have found very useful when trying to understand tricky permissions issues where you might get an effective grant when you expect an effective denial or vice versa.

 

Finally, if you ever find yourself trying to debug these issues on a regular basis my company has some commercial add-on software for tracing and understanding SAS 9 metadata permissions: https://platformadmin.com/blogs/paul/2016/03/tracing-permissions-sas-metadata-security/

View solution in original post

6 REPLIES 6
Quentin
Super User

I'm not an admin, but I'll take a stab at it from memory.

 

I don't like the phrase "added on top", that's not how I think about it.  Check with grey/green/white background are three different things.

 

A check mark with grey background means this permission is indirect (which I think generally means inherited from some higher level object).  For example if you give a user explicit permission to read a folder, they will have inherited permission to read all the tables in the folder.

 

A check mark with a green background means the permission comes from an ACT.

 

A check mark with a white background means the user was given explicit permission.

 

Again, I'm not an admin, but I do maintain metadata permissions for some stored processes I develop.  I follow the general rule of trying to set explicit permission at a high object level (e.g. I will have a project folder, and explicitly give a project group access to that folder).  Then everything within the folder (subfolders, stored processes, etc) all get inherited access.  This makes permissions either to maintain/review.

 

It's logical to think that there would be no difference in the end-result for check with white vs grey vs green background.  But I think there is also a precedence among them.  For example, if I have an inherited deny to an object but an explicit grant, I will have access to the object.  Because explicit permissions take precedence over inherited permissions.

The Boston Area SAS Users Group (BASUG) is hosting our in person SAS Blowout on Oct 18!
This full-day event in Cambridge, Mass features four presenters from SAS, presenting on a range of SAS 9 programming topics. Pre-registration by Oct 15 is required.
Full details and registration info at https://www.basug.org/events.
Mushy
Quartz | Level 8

@Quentin  Thanks for the response.. Indeed the information provided helps, But my question is all about what would be the difference if you have a allow permission in green and you change it to allow permission in white or when you have allow permission in grey and change it to allow permission in white.

 

Thanks

Mushy

Quentin
Super User

It's about the precedence, as I understand it.

 

For example, if you had allow permission in grey and deny permission in grey, then the permission would be denied.  Because inherited deny has precedence over inherited allow.

 

If you change to allow permission with white background (explicit) but still have deny permission in grey (inherited), then permission would be allowed.  Because explicit allow has precedence over inherited deny.

 

If the deny is unchecked, then I would expect no effective difference between the allow check being white vs green vs grey.

The Boston Area SAS Users Group (BASUG) is hosting our in person SAS Blowout on Oct 18!
This full-day event in Cambridge, Mass features four presenters from SAS, presenting on a range of SAS 9 programming topics. Pre-registration by Oct 15 is required.
Full details and registration info at https://www.basug.org/events.
PaulHomes
Rhodochrosite | Level 12

@Quentin has already explained it well but I might add another couple of points, some examples, and direct you to a blog post and documentation that might help you discover more detail.

 

I think the complexity around SAS 9 metadata security comes from the interplay of 3 different things: the type of access control (ACT or ACE/Explicit); the object inheritance path, a set of parent objects, any of which may have had access controls (of either type) applied, from which the object of concern may indirectly inherit; and the identity hierarchy, a set of groups the user is a member of (including nested groups), which may have been used in access controls anywhere in the object inheritance path. All of those 3 things plays a role in determining the precedence of access controls and permissions. As already mentioned, a green checkbox means the direct setting comes from an ACT, applied directly to the object of concern. A white checkbox means the direct setting comes from an ACE (explicit permission) applied directly to the object of concern. A grey checkbox means it is indirect - it may come from an ACT or ACE on a parent object (inheritance path), or it may have come from another ACT or ACE on the same object but from a parent group (identity hierarchy).

 

I thought some examples might help in trying to further answer your question on why might you change a green (ACT) or grey (Indirect) allow to a white (ACE) allow? As Quentin said, it would be to add a higher precedence permission. You are more likely to change a green/grey deny to a white allow but it is possible to change an allow to an allow too:

 

Example 1 (replace grey tick with white tick): if you have a grey (Indirect) ReadMetadata grant for the SAS Administrators group on an object you might change it to a white (ACE) ReadMetadata grant on the basis that someone (maybe you in a later step) was to add a white (ACE) ReadMetadata deny for the PUBLIC group on the same object. In the absence of the SAS Administrators ACE grant, the PUBLIC ACE deny on the same object would have higher precedence than the SAS Administrators Indirect grant. Every member of the SAS Administrators group is a member of PUBLIC too, so we add the SAS Administrators ACE to override the (future) PUBLIC ACE and ensure SAS Administrators maintain access.  NOTE: that if you were to do it the other way round and add the PUBLIC ACE deny first you would then see the SAS Administrators checkbox was now grey (indirect deny from another group in the identity hierarchy) and so you would then be changing a grey (Indirect) deny to a white (ACE) grant for SAS Administrators group.  For this strategy (wide deny, narrow grant back) I would actually recommend doing it through ACTs rather than ACEs - see the golden rules mentioned in the blog post below.

 

Example 2 (replace green tick with white tick): This one is more contrived, and not something you would encounter if you follow best practices, but it does show what is possible and if it is possible then it needs to be understood and potentially handled. To set up this example create 2 groups, Group A and Group B, and add the SAS Demo User as a direct member of both groups. Now create 2 ACTs: Grant A and Deny B. In the Grant A ACT add Group A and grant ReadMetadata, then in the Deny B ACT add Group B and deny ReadMetadata. Now create a top level folder and apply both the Grant A and Deny A ACTs to that folder. In the Authorization tab for that folder you will now see a green (ACT) grant for Group A and a green (ACT) deny for Group B. Now to visualize this, add the SAS Demo User into the Authorization tab and remove the automatic white (ACE) ReadMetadata grant for them. You will see a grey (Indirect) deny for ReadMetadata due to the conflict in the 2 ACTs. Now go to the Group A entry and tick the green (ACT) grant to add a white (ACE) grant (the example we are after). Go back to the SAS Demo User and you will see the grey (Indirect) permission for ReadMetadata is now a grey (Indirect) grant due to the higher level precedence ACE you just added. As I mentioned, this is a contrived example and if you follow best practices (the golden rules) and only ever deny permissions to PUBLIC or SASUSERS then this type of scenario should not occur.

 

I hope these examples helped. I would thoroughly recommend reading a blog post by @DavidStern at https://communities.sas.com/t5/SAS-Communities-Library/Which-SAS9-Permission-Wins/tac-p/560050 which contains links to other helpful articles. It also steps you through a great flow chart from some older SAS documentation that I have found very useful when trying to understand tricky permissions issues where you might get an effective grant when you expect an effective denial or vice versa.

 

Finally, if you ever find yourself trying to debug these issues on a regular basis my company has some commercial add-on software for tracing and understanding SAS 9 metadata permissions: https://platformadmin.com/blogs/paul/2016/03/tracing-permissions-sas-metadata-security/

Quentin
Super User

Thanks @PaulHomes for jumping in.  The limited understanding I was able to share was only because you helped me tremendously here on communities about 10 years ago to develop a basic enough understanding of metadata security models that I could set up a simple system that has been working for me, without much additional thought over the years.

 

@Mushy as I mentioned I am not an admin, just a developer.  If I were an admin, I wouldn't want to be an admin without the Metacoda Security Plug-ins Paul's company develops.  They make it super easy to review and validate metadata security, and answer questions like "who can see this object?"  "Why can Jane see this object?" "Why can't Mary see this object?" 

The Boston Area SAS Users Group (BASUG) is hosting our in person SAS Blowout on Oct 18!
This full-day event in Cambridge, Mass features four presenters from SAS, presenting on a range of SAS 9 programming topics. Pre-registration by Oct 15 is required.
Full details and registration info at https://www.basug.org/events.
PaulHomes
Rhodochrosite | Level 12

Thanks @Quentin, it's so nice to hear that I was able to help you on your journey developing your SAS 9 metadata security implementation.

I know you say you are not an admin, but it certainly sounds like you have solid knowledge and experience to me! 😉

Thanks also for your support and feedback on Metacoda Security Plug-ins

 

Cheers
Paul

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 6 replies
  • 1331 views
  • 14 likes
  • 3 in conversation