Hi Bob, That's a great question.  I have pondered this type of thing myself a number of times in the past (in my case with EG, where the EG users had their own dedicated app server for running their projects).  My first choice was to use metadata access controls to effectively hide the SASApp server from the EG users by denying RM to PUBLIC and granting it back to SAS admins, SAS services and those other groups who should see it.  The SAS EG users couldn't see it by exclusion.  Then the other app server (SASEG) was made visible only to the SAS EG users by denying RM to PUBLIC and granting it back to SAS admins, SAS services and the EG user groups.  Whilst that worked fine for EG usage, being purely identity based security, it meant that those EG users couldn't see or use the SASApp server in other SAS clients (in my case it caused issues in their use of the SAS web apps), so I ended up abandoning that approach.  I did set a default application server for EG but since the users could easily/accidentally switch over to SASApp, confusion arose, and assistance was required to help them switch back again, when their projects failed because they were trying to use resources not available on that app server. If you do get an answer to your question I would be keen to hear about it.  I would love to know if there is already a way of robustly implementing this type of client/application level partitioning.  If not, something I'd be interested to see in a future version of SAS would be client/application level security too. Perhaps where SAS clients, in addition to users, have to be authorized to use servers/resources. Perhaps EG can see a server where EM can't and vice versa. Maybe a user could access a library in one client but not in another.  If not security, I have also wondered whether clients could be made to query extended attributes on resources to find out whether it is appropriate for that client to use those resources.  I could imagine a setting that tells EG or EM that the server is unavailable for use by EG or EM.  I know EG already queries the AssignMode attribute on libraries to determine how it should assign them, so this could be something similar: i.e 'EG (or EM) please ignore this server and don't show it to any EG (or EM) users'. Cheers Paul ... View more

Hi Henry, Have a look at Defining User Accounts in the SAS(R) 9.3 Intelligence Platform: Installation and Configuration Guide. It states (in part) ... ... the user account that runs the object spawner must meet the following requirements on the object spawner machine: be the administrator or a member of the Windows Administrator's group have the following Windows local user rights: Adjust memory quotas for a process Replace a process level token Cheers Paul ... View more

Hi Jamie, If you have a small number of relatively static companies, and have those companies users in company groups in metadata, then you could add a number of company filters in the information map and use access controls to force the use of each for its respective company group (authorization-based prefilter). If you have a larger number of companies that might also change regularly and the mapping of users to companies is readily available as a data source, then another alternative is to apply a userid based identity-driven general prefilter to a userid-company mapping table as a mandatory table joined to your main table(s) via the appropriate company key.  The resulting data returned by the information will be subsetted to the company (or companies) that the logged in userid is associated with. You can find more information about this (for SAS 9.1.3) in the SAS 9.1.3 Intelligence Platform Security Administration Guide, Second Edition, Chapter 10 BI Row-Level Permissions Depending on your security requirements you may also want/need to consider the possibility of mediated data access. Whilst you might not actually need it, its still worth reading at least to determine whether it is required for your environment or not. Cheers Paul ... View more

Hi Frank, With respect to the SAS Web Report Studio 4.3 “Allow Direct Access to Cubes” capability, the SAS® 9.2 Intelligence Platform: Web Application Administration Guide, Fourth Edition (under SAS Web Report Studio Administration > Managing SAS Web Report Studio Content and Users > Predefined Roles) at http://support.sas.com/documentation/cdl/en/biwaag/63149/HTML/default/viewer.htm#a003279136.htm has that capability granted by default to the 3 pre-defined roles: Web Report Studio: Report Viewing Web Report Studio: Report Creation Web Report Studio: Advanced I did a blog post a while back in relation to considerations for removing a capability from someone: “Capability Reviewer Preview: who has access to a capability and how?” at http://platformadmin.com/blogs/paul/2011/04/capability-reviewer-preview/ A capability can be provide via multiple paths based on a users multiple nested group memberships, membership of implicit groups and direct and indirect membership of multiple roles that provide that capability.  Since it only takes 1 grant of a capability via any path for that capability to be given, then in order to prevent someone from having a capability, all access paths need to be found and eliminated.  To illustrate what I mean, here is a screenshot fragment of the roles & members tree for the “Allow Direct Access to Cubes” capability in a Metacoda Security Plug-ins report I generated from a  fresh SAS 9.3 EBIEDIEG installation. In an freshly installed SAS 9.3 installation (I assume it would be the same for default SAS 9.2 install but I don’t have one to hand to confirm) PUBLIC is a member of both Report Viewing and Report Creation.  Since you cannot remove someone from the implicit PUBLIC group the 2 ways to resolve this are to 1) remove the capability from both roles or 2) remove PUBLIC as a member of both roles.  It is not recommended to modify the capability sets for the pre-defined roles so that rules out #1 making #2 the recommended solution.  Having removed PUBLIC, to grant the required capabilities back to the required people, you can either create custom roles as variations on the pre-defined ones but without the capabilities you don’t need and make PUBLIC members of those, or use more specific smaller groups as members of the pre-defined and/or custom roles as appropriate for your site. BTW there is an excellent paper on roles and capabilities by Kathy Wisniewski in SAS Global Forum 2010 Paper 324-2010 “Be All That You Can Be: Best Practices in Using Roles to Control Functionality in SAS® 9.2” available at http://support.sas.com/resources/papers/proceedings10/324-2010.pdf I hope this helps. Cheers Paul ... View more