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.

Cheers
Shane

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)