01-12-2015 05:34 PM
USI noticed that out of the box implementation, has the SAS delivered rold of Add-in for Microsoft Office: Advanced properties having one member - which is the user 'PUBLIC'. Why does SAS provide PUBLIC user access to the Advanced Properties role, rather than the OLAP or Analysis role?
Does SAS recommend that users in general be given the Advanced role, rather than the 'Analysis' or 'OLAP' variations?
01-14-2015 11:08 AM
PUBLIC is a standard group used with the default ACT not an user!!!!!
This is confusing as some other system are using a public/guest account for that. Your are needing a good well understandable security design.
The PUBLIC group - default ACT is used to control the level of the REQUIRED "default open access" for all hidden objects.
It can be deny as the one for closing the access. The groups SASUSERS being used for the required default "all open access" rights (Read metadata)
01-14-2015 12:43 PM
Thanks for the explanation. I incorrectly referred to PUBLIC as a User.
So from your comments, I infer that by granting PUBLIC any role, the system is in effect preventing PUBLIC access to metadata,to an individual who does NOT have a SAS identity.
This is because PUBLIC's authorization level is DENY for both Read and Write metadata.
Is this understading correct ?
01-14-2015 01:05 PM
Yes that is the direction to understand. SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition (PUBLIC Access and Anonymous Access)
The security model with is rather complicated but working with that can be simple
The concepts are at: SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition (Example: Business Unit Separation)
There are two variations given there. In the real world there is always a combination of both them. You have an hierarchical approach (region) and a functional.
Both are to be part of a RBAC process. I mention these concepts here knowing that SAS institute is very weak in covering this.
01-15-2015 11:08 AM
The metadata security model is not in play here when it comes to group membership of a role. Roles determine the user-interface elements that a user sees when he or she interacts with the applications. (Security, on the other hand, dictates what metadata a user has access to within the interface, via the folder structure, such as tables or stored processes.) So I guess you could say that roles demonstrate security on the interface. SAS by default has PUBLIC as a member of the advanced roles for both SAS Add-in and Enterprise Guide, with the assumption that SAS users with these applications will have all the functionality that the application offers (menu choices, modifying options, visually seeing certain tasks, like sorting data, etc., in the interface). But these same users are under the metadata security model regarding access to the metadata. However, you can change that by removing PUBLIC, and adding a metadata group whose members are the only ones who should have full capabilities of the application. The PUBLIC group is used throughout the platform to represent the largest and most inclusive group, anyone authenticating to the metadata server.
That being said, regarding security, PUBLIC IS locked out of all metadata (and this is the security model), based on the repository ACT's denial pattern for PUBLIC. The group SASUSERS, a subset of PUBLIC, is not. And as mentioned above, a the best resource is the SAS Platform Security Administration Guide.
Hope this helps regarding roles. Sheila
01-15-2015 05:48 PM
Thanks for the explanation from both Sheila and Jaap. It has helped me understand how the Roles and metadata access relate to each other.
When you say ' anyone authenticating to the metadata server', I assume you mean anyone who has an OS level identity on the SAS metadata server. This is in contrast to someone how has a SAS Metadata identity itself (one that is defined using SMC). Is this correct?
SAS documentation appears to associate multiple meanings to the term Metadata server, and metadata, that it can get very confusing.
01-15-2015 05:20 PM
Sheila you are right to classify the capabilities not as security question but as a menu-tailoring concept.
SAS(R) 9.4 Intelligence Platform: Desktop Application Administration Guide, Fourth Edition (Administering Roles) links to default capabilities.
The group Public is part of the metadata security concept. The security of the metadata is granted to tailor those roles for menu-tailoring.
As the MENU-TAILORING DOES NOT SHOW THE REAL SECURITY you are open for changes going outside these tools or menus.
That it is not visible somewhere in a menu does not mean there are now ways to do those changes.
This is probably one of the bad sales stories being practiced. "What you cannot see is not there" ...humbug!
01-15-2015 06:56 PM
Rgulm every metadata identity does not necessary there must be an OS identity. For auditability traceablilty this would be more easy.
The sasadm@saspw is an internal sas metadata defined identity not existing on the OS. Maybe you can find the user an password in some config file ans is sometimes needed for solutuions.
For segregation of duties it is adviced not to use sasadm but a dual account. Avoiding the issues to get this in RBAC (OS identity) you can do that internal also.