Help! – Accessing Informaps and securing Libnames/Tables

So looking for some help from the SAS community.

On a project we have focused on delivering content via Web Report Studio and Infomaps.

We now want to allow users to access the content via Office Addin and Enterprise Guide.

But (there is always a butt ;-) we only want users to access data via Information Map, we don’t want them to access the base libnames or tables.

Why you ask, because we have all the business rules embedded in the Information Maps so we don’t want users bypassing these and defining there own business rules on the base data.

Of course if we deny access to the libname then the Infomaps will fail. We can’t restrict access to all data types (i.e tables) in AMO or EG.

So any ideas out there?

Things we are going to try:

  • Implement workspace server pooling (grant access to tables trusted user, but not actual use)
  • Create a workspace server for WRS reports with full rights inherited and a workspace server for AMO/EG users with linbame rights restricted

But we are pretty sure that neither of these will work.

As the title says, Help!


2 Responses to Help! – Accessing Informaps and securing Libnames/Tables

  1. Chris on April 3, 2009 at 2:30 am


    That is a tricky issue. SAS Enterprise Guide and SAS Add-In for MS Office rely on the INFOMAPS library engine to access Information Map data. When accessed through this engine, the data access adheres to your business rules. However, the engine can do its work only when the end user also has read access to the underlying data sources, which means they can also get to the libraries directly if they know how.

    In EG and AMO 4.2, there are features to control which features an end user sees based on roles that you can define in SAS Management Console. You can “lock down” data access from the file system and SAS server, effectively guiding users to access to data in SAS Folders. But this is a user interface affordance, and not a true secure way to prevent users from getting to data in another way.

    Creating a workspace definition for EG/AMO users is not a bad idea — that way you can control what folks see a bit differently than how you do it for WRS users.

    You could associate the information maps with another workspace server — one that doesn’t show up in the EG/AMO user’s list. But even if that works, it would degrade the data access performance signficantly, because it would force the information map result set to travel from one workspace session (the remote session with the info map) to another (the session that the user sees in EG/AMO).

    Chris (works at SAS on SAS Enterprise Guide and SAS Add-In for Microsoft Office)

  2. Shane Gibson on April 10, 2009 at 10:26 pm

    Thanks Chris

    Actually control at a tool level (i.e AMO or EG) would be enough for this project, but they are a SPM site so a wee while before they can go 9.2

    The INFOMAPS engine has given me an idea though, so will test it first before I post an update.