SAS Access Control

[Grumbler]

our users do NOT want all SAS accounts to access all applications, programs, and data.  but all accounts by default are part of SASUSERS group and if we deny access to ReadMeta or Read, a lot of the programs won't function properly anymore (especially if we deny libraries and tables).  any suggestions on a smart way to control who can access what data and what program?  it's almost impossible to set authorization to all the libraries and tables one by one by user groups.  new to SAS user control.  thanks.

[Kurt_Bremser]

TANSTAAFL.

The finer the control should be, the more work it will cause. If you want granular security on the level of single objects, then you have to set it on single objects.

The best way to go about it is to first group your objects per wanted access (eg review your library structure, so that access can be handled on the library level, and put program objects in folders), create groups in metadata accordingly and then assign users to those groups, and finally set the access rights on libraries and folders. After that you can remove the SASUSERS access. Lots of testing necessary, of course.

Be aware that real security needs to be done on the OS level; if access is not controlled there, all other means become moot in the long run.

[jakarman]

You should not set security in SAS metadata by setting it on explicitly on every object.

Instead you should design ACT acces control templates that are covering all the possible needs. This is explained in the security administration guide.

There are two ways described that is an organizational model and an application model. You need a combination of both of them.

[MichelleHomes]

Hi Grumbler,

Knowing what the end result/effective permissions of your SAS metadata security implementation can be difficult (whether you are a new SAS admin or a seasoned one) and we've found our customers find the Metacoda Identity and Object Permissions Explorers very useful for this reason, as you can see quickly and easily see the effective permissions of multiple objects and multiple identities. There is some information about these Metacoda Security Plug-ins Explorers at a blog post: Sneak Peek at our new Effective Permissions Explorers. These Explorers will allow you to see the SAS metadata end result on making changes to group memberships to folders, libraries or specific objects. As Jaap mentions, it is good practice to use ACTs rather than explicit permissions on objects (ACEs) and I strongly suggest you read the paper, Best Practice Implementation of SAS® Metadata Security at Customer Sites in Denmark by Cecily Hoffritz and Johannes Jørgensen: http://support.sas.com/resources/papers/proceedings11/376-2011.pdf

If you'd like an evaluation of Metacoda Security Plug-ins to see if it can help you, please register at our website.

Kind Regards,

Michelle

[ronan]

See the blog post mentioned in this announcement, it will redirect you further to several articles and presentations useful for clarifying your goal :

https://communities.sas.com/thread/78382

The default implementation of permissions - also called "Security Model" - in SAS metadata is quite liberal or all-inclusive: implicit groups (SASUSERS or even PUBLIC) are granted almost every permission, perhaps even WM (WriteMetadata) on  root Folders. Its a kind a compensation for a hierarchy of security rules based on "No explicit rule equals Denial applied by default" . If no explicit grants were allowed to SASUSERS or PUBLIC, then at the first launch after installation, there would be a complete deadlock which would require either to create new (explicit) Groups , grant them permissions (the best approach but tedious) or grant rights to implicit groups SASUSERS or PUBLIC at once (unsafe but easier to handle).

You would like to implement a more restrictive (=safer) Security Model based on explicit permissions exclusively granted to accounts already registered in metadata. Go ahead, that's the best way to go imho. This would require a more lenghty process of drafting your specifications, identifying your group memberships beforehand, assigning common resources (servers, folders, SAS clients) to specific groups , creating custom Roles etc., in short : customize your Security Model .

Personally, I was able to go all the way to an "ex-ex" exclusively explicit Security Model back in 9.1, even Denying basic ((ReadMetada) permissions to SASUSERS  in the default permission set (Foundation default ACT). But, unfortunately, I wasn't able to do it in 9.2 and 9.3 so easily. Inheritance rule prevented me to block SASUSERS altogether  because of (1) the unified hierarchy of folders where the SASUSERS permission assigned at the folder root level ( Authorization Manager / Ressource / By application / SAS Folder) cannot be fully controled and (2) the Content Server counterpart hierarchy, root folder, requiring specific additional assignments ... I'd be very much interested if anyone had much success "squaring the cycle" in 9.3 or 9.4. :smileyconfused:

[jakarman]

Ronan a good security isn't that difficult. It is about data modeling understanding the business requirements at that level. That level of understanding is possible needing a special mind setting. The same kind of alpha and beta science.

Aka already mentioned that one.

Going into some technical details. Not all records in the metadata are having got autorzation options. Still all records are being checked for autorization. The result of this is that weir requirement that the sasusers group is needing to have update access Wm in the public act. After that you close all other act's to revert that and at the same time opening with the wanted users. This approach is well documented.

With some tools you get weird behavior. With 9.1 DI got the contradiction closing group administration at the user level blocked adding new users as at first time usage some updates are done. Allowing users their group membership is a break for all security. It was not fixed. With 9.3 that part was implemented different by SAS. As the real thing was not documented or solved I am not convinced of a trustworthy approach of SAS metadatasecurity.

The webdav or contentserver is a technically different environment. Not really metadata although there are pointers of metadata to webcontent. You should not think of SAS  tools being the only way of acessing that kind of data.

Try to think like a hacker to start like a pen - tester.

[Grumbler]

Thanks all.  I think we need to re-design our metadata structure.  Original designers didn't seem to consider different departments.  This is going to be a pain. 

One additional question, if there are 2 departments each needs to access some tables in the same database.  I setup 2 libraries by pointing to the same database (register different set of tables in the metadata) and set the permission by department to the libraries, that should be enough to prevent each department from accessing the other's data correct?

[Kurt_Bremser]

I would advise against it.

- new datasets will always inherit access rights of the library by default, so you need to do extra action when a dataset is added to the common physical library to make it visible for both departments; not good.

- datasets in the common physical library will have two links in the metadata, doubling all maintenance; not good.

Instead have three physically separated libraries (Department A, Department B, Departments A&B).

[Patrick]

What you want to do is to "get it right" from the beginning. I've seen at least one bigger organization which got it wrong and it took a long time to clean up the mess. It's basically: You apply ACTs to folders, ACT's have groups and groups have users. A lot of organisations then manage their users and groups in LDAP/AD and just sync into SAS Metadata. SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition

I strongly recommend that you get the necessary SAS Admin training and read as much documentation and whitepapers as possible, then create a security design/model and only then actually apply it to Metadata. If it is not possible to get this done in the time given then consider engaging SAS professional services or another capable consultancy to get this work done for you. The 3rd party tool Metacoda as suggested by has a very good reputation and can certainly be very helpful - but you still need to understand what you're doing.

[jakarman]

It is surely not the SAS metadata that is leading.

Start with your organization. There are 4 kinds of objects 1 users (any type including service and test accounts). 2 groups to organize access being the technical ones allowing tools or some business application or some department. 3 the business applications getting technical organized by groups for code and data with technical accounts  4 the tools like Sas oracle or whatever.

The os is irrelevant. A business application can have empty code data storage allowing self service.

That is a generic data model.

There are two exams by SAS for a metadata security design. One is application driven the other organizational. They should be mixed.

For your question for two departments sharing a library, that doesn't make sense. Most likely you are into a business application where data should be read shared. Implement it that way. With self service building could be done at a personal or department way but that approach is not correct. Let them build those in normal dtap approaches. Get no ict involved claiming development by selfservice is not allowed. They should cooperate. May be that is the rootcause you are in.

[Grumbler]

again, thanks all.  i am not going to have time to study all of the details.  however, we do have a testing environment for me to play around.  sas may also offer help directly.  obviously i don't have enough experience with this as i am just a programmer and analyst.  just got thrown into this mess since no one else knows sas in the project at the moment.

[jakarman]

Sas might offer to help you. They have access to all technical details of sas stuff.

You issues most obviously more an organizational question also indicated as data governance.

The mess you are into is commonly caused by mis alignment of that. As a pity sas is ignoring that area. There you have a dog tail chase. Good luck with that.