Which SAS9 Permission Wins?

[#1]

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.

Legend

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.

 

1. Settings on an item have priority over settings on the item's parents

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!

Example 1

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.

 

2. Conflicting settings on an item are resolved by identity precedence

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.

Example 2

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.

3. In an identity precedence tie, explicit settings have priority over ACT settings

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.

Example 3

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.

4. In an identity precedence tie that isn't resolved by the preceding rule, the outcome is a denial

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.

Example 4

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.

Simplify the words

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. 

Shrink to fit

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

legible:

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! 

[jakarman]

In this approach there is a major pitfall, those are:
-The ordering of security settings is easily different as of the setting on the item (artifact) explictly or being inherited.

- outsmarting some nasty and dumb expected grouping on items work by adding roles and other levels will make it worse.
When the security and/or work for promoting is very complicated most likely the grouping and ordering of artifacts ha been done in a wrong way. In that case the advice should be redesiging that area.

I like the concept of using only some ACT's protecting grouped way of artifacts of the same security classification and same security rights. There is no problem on then number of ACT's (well designed naming convention) or is there. So what is the issue sticking to that?

[PaulHomes]

@jakarman What do you mean by "The ordering of security settings is easily different as of the setting on the item (artifact) explictly or being inherited" Can you post a concrete example that shows the pitfall you are talking about? It would then make things easier to discuss.

[jakarman]

https://www.owasp.org/index.php/Security_by_Design_Principles  There are lot principles for security in that.

“The need for application security in the form of security architecture is every bit as great as in building or bridge construction.”

I would like to start with one I propose and than going to what is often happening.

My proposal:

- start with a folder structure categorization (containers) on projects/applications

- Within those containers segregate on the artifacts like Jobs(DI) Tabels(DI) Miner (models and the pointers to the externals stored EM projects) flows deployedjobs etc.
- When there is some information flow that needs segregation within that project define additional folders.

  This can happen in data science projects having different flows for delivering the data as  modelling purpose or as scoring purpose.

   In the latter one there is some parallel development in cooperation to solve.

- Having all those folders define for each two ACT definition one for read-only purpose and one for updating maintenance.

- Having the ACT’s only giving grants and never denials.
- As last:  never (only some exceptions) define access for users or groups by explicitly on those folders/resources only do it by maintaining the rights by groups membership at the ACT’s. For the high privileged accounts (project limited least privileges) it can be dedicated non personal accounts.

The result:

- a very simple way to implement maintain.

- I can’t see any mistakes or confusions when strictly doing this.

The challenge to explain to others is that obviously hidden layer by ACT’s.

Another challenge is the an additional clear need for the sponsor / line of business as it not visible in this concept.

Heaving multiple line of business sharein something is no issue at all as those groups can mentioned in the ACT’s   

The common approach I often seeing.     

- start with folder structure naming the lines of business unit.

- put all kind of different artifacts mixed in some folders. This is a result of following the ownership named conform the business-line

- have the smart IT add some denials/ grants named like DI-developer Modeler or whatever.

The result:

- The complexity is becoming a headache as

    . requirements of securing artifacts are coming in.

    . additional business lines are also allowed to use some parts, security to be changed   

With this the temptation of using explicit ACE’s on each folder/artifact is that is going to be used.

The first will look to be working and more will come in adding more complexity as humans are able to understand.  

In the last situation:

Now add some  subfolder or going to move some things.

Look at the precedence the settings explicit have priority on the ACT’s an the inherited.
In the new folder everything is inherited there is no automatic copy of all ACE’s.

The new folder is seeing groups like Act’s and all stuff as inherited the on the Item box is vanished.  

Will the security give the same results?

An other is having this one:  “then the access control for the group the user is more closely a member of will win”
Having conflicts in right that are as equal in distance there will be a random affect (unpredictable undefined outcome).

I have seen this kind of issues in real life even more weird ones.
The owasp never got really to life  

[PaulHomes]

Hi @jakarman,

If I understand your proposal correctly, then it appears at a high level to be somewhat similar to the practices discussed in David, Cecily and Angie's papers. I'm wondering if an area of difference is the use of ACEs? You don't mention ACEs in the proposal, but given you say your ACTs only grant, I am assuming an implied use of ACEs to deny permissions (to PUBLIC or SASUSERS) when you need to hide/protect folders. Is this correct? Whilst I personally prefer to use ACTs when I can, ACEs can of course also give you to outcome you need, if you are thorough. However ACEs are more difficult to find/manage (unless you have software to help). ACTs also give you the opportunity to encapsulate common patterns in a single location, so that if those patterns change in future they only need to be changed in a single location rather than multiple. Following the best practices will also make an implementation much easier for other/future workers to understand.

Regarding the last points/questions:

Now add some subfolder or going to move some things.
Look at the precedence the settings explicit have priority on the ACT’s an the inherited.

In the new folder everything is inherited there is no automatic copy of all ACE’s.

That's right - the subfolder will not have any direct access controls (ACTs, ACEs) unless they are specifically added. However any access controls on the parent will still have an indirect effect. Without any direct access controls on the subfolder, the effective permissions on the subfolder will be the same as the parent folder (except for any potential WMM on parent > WM on child related differences).

The new folder is seeing groups like Act’s and all stuff as inherited the on the Item box is vanished.
Will the security give the same results?

The presence of any groups and permissions on the parent folder will be seen as indirect on the subfolder. As mentioned on the previous point, the effective permissions on the subfolder will start out the same as the parent folder (save possible WMM > WM differences). The "on the item" box has not vanished, it is just only considered when direct access controls on the item (subfolder) cannot determine the effective permissions on their own and in that case the items on the parent are then considered. For a newly created subfolder with no additional direct access controls the parent folder will determine the outcome. This is as most people would expect I think.

An other is having this one: “then the access control for the group the user is more closely a member of will win”
Having conflicts in right that are as equal in distance there will be a random affect (unpredictable undefined outcome).

There is no random effect. When there are conflicts the outcome is determined. It might appear to be unpredictable without a full knowledge of the implementation and precedence rules. However, if you follow the flow chart David discusses above you will always get a determined outcome. A major benefit of following the best practices he described in his papers is that you don't need to keep all of this in your head to know the outcome as those practices simplify matters greatly and you won't end up with apparent unpredictable outcomes.

Cheers

Paul

[jakarman]

You don't mention ACEs in the proposal, but given you say your ACTs only grant, I am assuming an implied use of ACEs to deny permissions (to PUBLIC or SASUSERS) when you need to hide/protect folders. Is this correct?

Yes they are the exceptions to do at a high level as possible so no need to adjust them afterwards.
The default installation is/was open for public/guest by default causing real security audit issues.

However any access controls on the parent will still have an indirect effect. Without any direct access controls on the subfolder, the effective permissions on the subfolder will be the same as the parent folder (except for any potential WMM on parent > WM on child related differences).

I am sorry, but real life experiences (9.4m3 latest) seen this not being true. Not anything set at subfolders and behaving differently wiht a far too complicated setting on the parent  

There is no random effect. When there are conflicts the outcome is determined. It might appear to be unpredictable without a full knowledge of the implementation and precedence rules.

I left a detailed situation example away because it is rather complicated. But here it comes.
Suppose the conflict is in the "closest group" access ones, there is no clear definition order of that.  Also this one real life experience and only being proven by removing and adding exactly the same rules in a different order.

The same kind of pitfall experienced by the way with dynamic prompts. When the library and you have several different of those for different apps-servers and the prompt is searching the app-server the app-server selection is by-passed and the first in a technical order is opened, No problem when there is only one app-server and one library definition but with parallel groups you get surprised.     

[PaulHomes]

Hi @jakarman,

Whilst I'm aware of random/undetermined outcomes in some aspects of SAS metadata, such as fetching outbound logins in the same authentication domain from a user's identity hierarchy in SAS 9.1.3, I have never see random results for effective metadata permission determination. This includes many years of working with SAS metadata security, both with consulting projects and development/testing of our Metacoda Security Plug-ins. The area that gives me most confidence about this relates to the unit tests we run for our Permissions Tracer plug-in. In that plug-in we have an algorithm to prioritise relevant access controls and derive and highlight the definitive ones - those that determine the effective permissions. Our tests for that algorithm compare our derivation of the definitive permissions with the effective permissions (as returned by the SAS APIs). These tests have been run thousands of times for every combination of user/group and public type object in our test metadata. Our test metadata includes and exercises deliberate conflicts for "closest group" as well as some of the more obscure setups like missing repository ACT, repository ACT with PUBLIC grants, repository ACT with no PUBLIC grants/denials, multiple-inheritance, role-implied permissions etc. There are lots of examples of both good and bad practices in that metadata. From all of that testing, we have never yet seen a random result with effective permissions.

Of course there is a possibility we don't exercise a scenario that exhibits random results but, given all of the testing we have done so far, I would be very surprised to see one. If you can provide a more concrete example of a setup that demonstrates a random effective permission result then I would be happy to add it to our testing scenario and run a few thousand rounds of testing to see if I can replicate your random result. We already have closest group examples that don't show random outcomes, so perhaps you can be more specific in your example.

Cheers
Paul

[jakarman]

Well Paul SAS metadata is not that long present as being working in IT and SAS (technical based) far longer as that.
The most difficult things is getting data information security according policies wheras the ISO27002 is the challenging but basic one.
Do you have those references?  As there we go.

The need is building an environment whereas all this with code/business logic and data should well seperated for daily business usages and at the same time release-management (code promotions version controlled) . And  data manipulations by somebody else being prepared (segregation of duties).  The testing should be done that all needed access is granted and time the required denies should be active.

Even the famous Danish "best practice" never getting correct as of the mixing of code/data by the DI-developers grouping ignoring those other activities. This may be the whole issue as the random security behavior was always in that settings.
I cannot create an example of that as not having acces at that level now.
Mu question: Do you have that kind of structures to that level of compliancy (Iso27002) underpinned and audited?

Som frustrations from the past:

- The dynamic prompt random behavior was nicley replayable but even with that shown to SAS staff they still not seeing the issue.

  That was a result of parallel testing multiple goups of persons sharing logic but wiht segregated data to be chosen as option. 
- Getting the shared server to work on Aix it was working at first sight well (user/password checked) that found by surprise that without password all was accepted. Surely not the way but the only answer "upgrade to the next release" (still  B at that moment).       

     
 

[DavidStern]

Hi @jakarman, I've been following this discussion closely over the past week. I'm finding it a little hard to understand some of the things you state in your comments, and would very much appreciate it if you could give us some more specific examples of what you mean.

In reading the discussion above, Paul asked you for examples, but it seems that you changed the subject slightly, and introduced some new concerns in some of your replies, rather than explaining what you meant in earlier comments. This is making it a little hard for me to follow exactly what your concerns are, but I'd very much like to understand them, and to resolve any misunderstandings, or raise defects with the SAS design and development teams as appropriate, if I can. It's not really feasible to do that without having something more concrete to illustrate the issues you have referred to, though. If you introduce new subjects which you think we have not covered well, or where there are issues, please would you similarly give clearer examples of what you see being the problems?

In your first comment, you wrote about a 'major pitfall in this approach' (though the above post is not really an approach: it is explaining how part of the software functions), but I am not clear what pitfall you are referring to. None of the subsequent replies seem to return to this subject, but perhaps I misunderstood them; forgive me if I did.

You say that say 'Having conflicts in right that are as equal in distance there will be a random affect (unpredictable undefined outcome)', which I think is claiming that the way that multiple inherited metadata permissions settings - some granting a permission, some denying it - from groups the same distance away from the user are not resolved in a predictable way, but that is emphatically not true in my experience: they are resolved in a very predictable and deterministic way. I'm sure you appreciate that you cannot consider the distance between the user and the groups from which those permissions are being inherited - the user and group hierarchy - in isolation of other things; you have to also consider

• what object the permission settings are applied to, and
• if multiple permissions are set on the object itself, what type they are

...as the decision flowchart shows. I'm sure you would be the first to agree that behavior one does not understand correctly is not (necessarily) random.

Paul is correct to mention that the way outbound login credentials are inherited by a user from multiple groups the same distance away from the user is a concern: if multiple outbound login credentials in an authentication domain are available to a user (through inheritance from groups the user belongs to) when he tries to access an external resource such as a DBMS, and they come from groups the same distance away from the user (e.g. two groups where the user is directly a member of both), then only one of those logins is presented to the external system. However, which one is used is undefined. It is deterministic: it is always the same one, of you connect multiple times - so it is certainly not random. But since you cannot reliably control which one is used when there is more then one with the same precedence, we strongly recommend against a user being a member of more than one group at the same level away from the user which have a outbound login credentials in the same authentication domain.

But this is the ONLY example of an undefined result in a conflict that I am aware of. I have worked on security model designs for many customers (my own designs and theirs) and have yet to see, or hear of, any random behavior, or any behavior which is in any way influenced by the chronological order in which security settings were applied to an object.

In your last, you say "Even the famous Danish "best practice" never getting correct as of the mixing of code/data by the DI-developers grouping ignoring those other activities. This may be the whole issue as the random security behavior was always in that settings." Perhaps you have seen the SAS Global Forum 2011 paper: Best Practice Implementation of SAS® Metadata Security at Customer Sites in Denmark by Cecily Hoffritz and Johannes Jørgensen, which in Table 7 on pages 8 and 9 clearly separates out these things in folders named '1. Libraries', '2. External data', '3. Source data', '4. Jobs' and '5. Transformations' within a parent folder structure for one particular line of business. The authors are clear in this paper (and in others, some published internally within SAS, some also shared with customers with whom they - and I - worked) that this is not the only way of designing folders, and one must adjust the design according to what is required for a particular customer or set of SAS software being used, but nevertheless it is perfectly and consistently clear that they to not recommend mixing code/data by the DI-developers in the same folders. And nor would I. I wonder what you can mean?

I would very much welcome some examples, or a demo, or some references to practical illustrations which we can use to reproduce the behavior or design features you mention. Again, by all means introduce additional concerns to this conversation, but we would be able to respond more usefully if you can similarly give references and examples or illustrations of what you mean so that we can better understand them.

Best wishes,

David Stern

[jakarman]

David,  "it is perfectly and consistently clear that they to not recommend mixing code/data by the DI-developers in the same folders. And nor would I. I wonder what you can mean?" The Danish best practices is having a nice rule setting how to architect something. 
But what is in the example (2009) is the organisation of the Danish office focussed on their structure.
What happened in that time (210) as (not SAS) architects did not understand that difference to the client local situation is trying to copy (the example) and that organisation into the local situation. It was followed by subfolders as of step 1,2,3 of some development process actions and getting data and code artifact being mixed up. Having the requirements for release manager later getting a lot of growing exceptions.  The situation getting unsolvable as at some point far too much of exceptions being needed with unpredictable behavior.

Making a clear statement: determine local client requirements starting with security of artifacts not working with tools would solve a lot.

I see you are in that direction, we can agree on that. .     

"However, which one is used is undefined. It is deterministic: it is always the same one, of you connect multiple times - so it is certainly not random." 

That was the key behavior as previous described  deleting and adding the same definitions was showing that. I am indicating it as random as at the moment someone is updating that (delete/adding eg groups) and it is not getting the same results as the internal order is different. It realyy happened that way ne department new group name and …. . 
I my first case it was on folder access and as far I am remembering it in the inheritance of subfolders with multiple access right groups in the same distance but with different rights and there were different denies added as argument for auditing being more clear.

In the second one also many organisational groups and is this one global tool roles mixing up access rights allow and denies on the same distance. (because you are Eminer / Eguide / DI user you have right to and not) Because you are part of that and that department getting access right to .. and not to ..  

I would like to reinvest such things again but as not having the needed access rights now (admin rights local isolated SAS environment) it is for the time being not possible.

For some surprise experienced some time: adding authdomains by some normal user (login manager) should that be possible?
The DI failed access needing too mucht richts was at 9.1.3 and was confirmed by sas support, should be fixed now. 
At that moment and existing user could work on folders getting more restricted a new user crashed on security. Only after a first login with higher admin levels at the user it worked thereafter it could set more restricted again. No change on folder security in between was done. The only conclusion is some invisible administration was done at the first usage.                                
 

       
    

[Sajid01]

Thanks for such a nice info.
I have some confusion regarding example 1. Can you please help me understand it?
1.My understanding is that member of PUBLIC group will not be able to see Library A. Members of other groups will not be impacted by this setting.
Therefore I would write the statement as" A user who is a member of PUBLIC will not be able to see Library A."

2. Further the group PUBLIC has those users who have an account in the OS and can access SAS but have no user definition in SAS metadata server. They should not be able to see anything even without these settings

[PaulHomes]

Hi,

1) In example 1 "LibraryA has an explicit denial for PUBLIC and LibraryA’s parent folder has an explicit grant for the user." The (ReadMetadata) grant on the parent folder is overridden by the denial to PUBLIC on the library object itself. Everybody is a member of PUBLIC and so nobody will be able to see the library unless there is something of a higher precedence on the object that grants the permission back (or they are a member of the unrestricted role). You are correct in your statement "A user who is a member of PUBLIC will not be able to see Library A." but also that everybody is a member of the PUBLIC group so it applies to everybody. When considering effective permissions on an object you have to consider the complete set of applicable identities - the user themselves and every group they are a member of - direct, indirect and implicit (SASUSERS, PUBLIC).

2) Ordinarily yes, a PUBLIC-only user (someone that has no SAS identity of their own) would not be able to login due to the denial of permission to PUBLIC in the repository ACT (usually named Default ACT). One does need to consider the possibility that this may have been changed, either accidentally or deliberately, and PUBLIC-only users have been given the ability to login. That is why I prefer to deny permissions to PUBLIC rather than SASUSERS. Even in the normal situation, when PUBLIC-only users cannot login, the PUBLIC (or SASUSERS) group is still the best group to use to wipe out access for everybody (except unrestricted) and then grant back permissions selectively to other narrower groups (this is one of the best practices).

I hope this helps.

Cheers
Paul

[DavidStern]

Hi Somename, thanks for reading and your kind comment and question.

As Paul says, everyone is in PUBLIC. It's SAS 9 Metadata Server's implicit group to which all users belong, including all anonymous or guest users if you have configured your system to allow anonymous/guest users access to it.

Therefore the statement "Members of other groups will not be impacted by this setting." is not correct. Members of other groups must be impacted by the setting because members of other groups must always also be members of PUBLIC.

Kind regards,

David

[Sajid01]

Thanks PaulHomes and David
I have got a better understanding now.

Thanks once again

[Heleen]

Hello all,

I was wondering if there were a vm ware setup or a lab environment around anywhere with which we could test to see if our understanding of the above is complete ? (am I the first to ask this?) I guess by doing this is learnt far better than by watching video and/or reading (albeit highly instructive) posts...

Thanks & best regards,

Heleen

[Sajid01]

If you do not have access to test on a server this book should help.
https://support.sas.com/content/dam/SAS/support/en/books/sas-administration-from-the-ground-up/71228...

[MichelleHomes]

Hi @Heleen,

We understand the complexities visualising and verifying the rules and developed a Metacoda Permissions Tracer within our third-party commercial Metacoda tools to help SAS administrators to trace through the permissions, visualise and verify what they expect. You can read about the plug-in at https://platformadmin.com/blogs/paul/2016/03/tracing-permissions-sas-metadata-security/ and feel free to register for a free 30 day evaluation to try it out in your own environment. The installation takes 5 minutes (if that) on the SAS Management Console client machine.

Metacoda will also have a booth at SAS Global Forum in DC in March where you can come talk to us further if you’re going, we are also happy to arrange a web meeting.

Kind Regards,

Michelle

P.S. Anja, the author of the SAS admin book @Sajid01 mentioned also describes the benefits of Metacoda Plug-ins in the book in the security chapter.