Architecting, installing and maintaining your SAS environment

Preventing direct access to cubes from WRS

Accepted Solution Solved
Reply
Contributor
Posts: 41
Accepted Solution

Preventing direct access to cubes from WRS

Hi,

I want to ascertain that WRS (Web Report Studio) users can access data only through Information Maps.

I thought it would be enough to remove the 'Allow Direct Access to Cubes' and 'Allow Direct Access to Tables' capabilities from the role that is assigned to those users.

However, from a Web Report they still can open cubes and tables. That is, only if they have Read access, of course, but the point is that the Information Map might limit their access to certains rows or slices.

I have made certain that they are not a member of any group that has a broader role.

Of course, they still are member of the SASUSERS group, but that group has no role assigned.

I stumbled onto Usage Note 40599: "Assigning users to a custom role that has limited capabilities might still have access to additional capabilities even after applying the custom role". But what does that mean?

That I can never give a user less capabilities then SASUSERS has, and that I can never remove those capabilities from SASUSERS? That would be very disappointing!

Anybody any experience?

Frank Poppe


Accepted Solutions
Solution
‎11-10-2011 03:19 PM
Super Contributor
Posts: 356

Preventing direct access to cubes from WRS

Posted in reply to FrankPoppe

If you are using the standard security set-up, I think you may need to look at Public as well, in our case public had the WRS Consumer role assigned... ''Barry

Barry

View solution in original post


All Replies
Solution
‎11-10-2011 03:19 PM
Super Contributor
Posts: 356

Preventing direct access to cubes from WRS

Posted in reply to FrankPoppe

If you are using the standard security set-up, I think you may need to look at Public as well, in our case public had the WRS Consumer role assigned... ''Barry

Barry

Contributor
Posts: 41

Preventing direct access to cubes from WRS

Posted in reply to twocanbazza

Right.

The PUBLIC group still had the original "Web Report Studio: Report Viewing" role assigned, which includes the "Allow Direct Access to Cubes" capability.

I choose not to change the original role, but created custom roles as copies of the original ones, plus or minus a few capabilities. But overlooked the fact that you still get the capabilities I removed through the PUBLIC group.

There is another tricky behaviour, it seems. Identities that have no role assigned, because SASUSER and PUBLIC no longer have any explicit role and because they are not member of any group that has a role, seem to get a set of default capabilities, including the "Allow Direct Access to Cubes" one.

Perhaps the paper Paul refers to (below) will clarify that - I haven't read it yet.

Thanks all.

Frank

PROC Star
Posts: 426

Preventing direct access to cubes from WRS

Posted in reply to FrankPoppe

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.

allow-direct-access-to-cubes-cap-members.png

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

🔒 This topic is solved and locked.

Need further help from the community? Please ask a new question.

Discussion stats
  • 3 replies
  • 349 views
  • 0 likes
  • 3 in conversation