Library authorization doesnt propogate to tables.

[lavi]

I am trying to give access to a new user to existing library. I have added the user to Authorization tab and granted them RM,WM,CM,R,W,C rights. But when I check the properties of tables included in the library I don't see that user in the list of authorized users. So my question is:

1) Do I have to add that user to each existing table in the library. In the future for new tables the access will propagate as expected.

2) Even though I don't see the user added to each table the permissions are propagated since they are added to the library.

Thanks.

[jakarman]

There is lot to say, some points:
- do not grant access rights by using discrete profiles. Use:
  + act's applied to resources like a library

  + in the act's grant right's mostly on groups

  + grant users their permissions by adding them in groups.
This is adviced in several papers and the bisecag. Why didn't you do that?

Libaries in SAS metadata are dedicated objects they do not overrule OS security. What does this mean?

- unless you are having a fixed way of running code only using path's that are predefined (maintaining a dictatorship) it will not help you.

Analyst's are needing some freedom doing their work. When you need to protect the data do that on the OS levels with OS layer controls.
The table metadata objects are separate objects in the metadata they can be used to generate SAS code without the need of ever seeing some data. The testing of the generated code will be little bit difficult as that is needing access to data. So what is your goal of your security design?

[lavi]

Thanks Jaap for your response. I am in fact using group for assigning rights and adding this user to the group.  I guess I shouldn't have omitted that detail . So the behavior I observed is for group instead of user. I do have experience with other software but am new to the SAS world.

- I do get the concept of assigning right to groups and controlling access at group level but what do you mean by "discrete profile" and "act's applied to resources like a library"

-  By OS controls do you mean at the DB level?

[PaulHomes · Accepted solution]

I think the confusion here might be due to the fact that table objects registered in metadata pick up their inherited permissions from the metadata folder they are contained in and NOT from their associated library object registered in metadata (as of SAS 9.2 at least - things were more complex in SAS 9.1.3). i.e. If you apply permissions directly on a library you wont see those show up on the table's authorization tab, if you set them on the folder you will (both on the library and table). For more information see SAS 9.4 Intelligence Platform: Security Administration Guide, Second Edition: Object Inheritance

To ensure consistency of permissions it is a suggested practice to put the libraries and tables in the same metadata folder (or within the same branch) and apply ACTs providing appropriate permission to appropriate groups on that folder (or an appropriate parent folder for that branch). You might find the Variation 2: Functional Separation example useful to illustrate this.

[lavi]

Thank you paul. Adding the group to folder authorization tab worked. We have a small group of users (<10) and are not even in the initial stages of setting up a security map. In our current environment all the users log in with one user id and I am trying to get away from that to begin with.

[jakarman]

SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition (Basics of Metadata Authorization)
I meant the DCE's  "Direct control: explicit".  The ACT (Access Control Template) is a concept I have not seen much at other technical systems.

I think ACF-2 (mainframe) did have something like that. AD Windows is also offering very much creativity in defining groups, you could see it similar.

An attention point is that the concept of SAS metadata-security is requiring to set all access by all users open (RW) and you have top close that in a sensible way all is keeping functional including al lot of hidden resources.-control

With OS-controls I mean everything that is not under control of SAS. The can be:
- The OperatingSystem Unix/Windows/Mainframe
   As all processes are run by a sas.exe process using some key/account you can limit that used account to what is really allowed.

   This level of security is more common known and can be trusted and monitored.

All external data not stored on the OperatingSystem but in a RDBMS Hadoop or whatever.
  These have commonly Security Controls common known and also all kind of logging - monitoring.
Are you easily able a user being identified on the OS RDBMs by his personal identity, your security design and all controls is getting more easy.

For example an Oracle DBMS, would it be acceptable to have the Oracle DBMS been uncontrolled and trying to implement that with SAS?
At a moment someone needs an other way to access Oracle what is the impact of that? Change the word Oracle for every type external data you could have as this is a pattern.  Do not make it more complex than doing the security on data as close where it is stored.   

What is your goal/requiment on securing table inforamtion?

[jakarman]

Paul your reference to varition2 functional separation is nice. This is possible technical implementation. Perhaps a different approach is needed as it dependent on the requirements/environment lavi is having.  variation 1 or 3+.  Just being a technical (simian?) not aware of business is the nerdy way.

I am missing some vision behind of what he is doing. That is why I am asking the Who and Why (Where When How).   Lavi did not describe the type usage yet. Are the common users analyst-s (Excel R mining)  or is it a more fixes bi-reporting like a LAMP (Linux Apache MySQL PHP) approach.