07-09-2014 09:42 AM
If you're looking to simply provide the VIEW and obscure the access to the underlying table, you could encode the LIBNAME statement/access inside the VIEW with the USING LIBNAME syntax. However, that doesn't prevent your end user from spelunking into the VIEW definition and finding a direct line to your table.
07-09-2014 02:01 PM
Unfortunately I dont have the access to SAS Metadata Server and "Using Libname Sintax" goes exactly to the spelunking issue that you mentioned. I'm trying to find a solution to hide sensitive data from the users and the best thing I could think was creating views displaying only the allowed data, it is simple and would save space. Anyways thank you very much. If anybody can give me any other suggestion I would really appreciate!
07-09-2014 10:17 AM
SAS is not like a database. What you intend to do is typical for databases.
For SAS a view is just a query saved in the file system. When you execute the view the query is executed and your users will need access privileges to the underlying table. So it is not possible to do that with SAS datasets.
07-09-2014 10:23 AM
Actually, you can do most things with SAS, have a secured autoexec.sas for instance which sets up permissions, creates things based on username etc. You could for instance put in autoexec the statements:
If user="aaa" then do;
libname aaa_data "...\..." access=read;
libname aaa_workspace "...\...";
proc datasets ... copy datasets from core to aaa_data;
However you would also need IT to protect things on a storage level as obviously knowing the network path to core would allow access.
07-09-2014 10:18 AM
Could you mean some kind of access control to a large dataset. I know what OC does is create a view with a subclause for access:
User Priv Area
aaaa write Dom1
aaaa write Dom2
bbb read Dom1
create view TEST as
where AREA in (select THIS.AREA from ACCESS THIS where THIS.USER="&USER.");
07-09-2014 01:45 PM
You must block all kind of features of SAS to achieve your question.
What you are describing to achieve is the same as once COBOL programmers did. Build the program test it and deploy.
Let the users only user your program in the given ordering of clicks/enters .
I was assuming we are going for use with the goal: BI users, Agile, self service analytics. That is implying a lot of freedom for the users.
I you need to protect sensitive data think about that on the OS level.
07-09-2014 02:07 PM
Yes Jaap, I really need to protect sensitive data, I would like to not have to create separate files with sensitive and non-sensitive information. However I couldnt find anything efficient to do that.
07-09-2014 02:40 PM
It does matter what kind of OS you are using and how comfortable you are organizing security at that level.
- With the common used Windows using the Active directory, you have very advanced options that are well known and fit into common management
The most easiest approach is defining data accordingly in those kind of locations.
- Mainframes are well managed, just find the RACF people and you can solve it.
- Unix/Linux is the exception as often very bad managed and blaming all other tools for complexity.
This is not needed as also in Unix/Linux security can easily managed when all technical prereq are known.
- An external DBMS often has very advanced authentication and security. When the libname to an external RDBM is able to set up with different setting according to you requirements you can solve this at that level.
All this is needing cooperation with those guys. They have the tools to do it.
If all data is in one table and several persons may see just some part you are having an issue.
This is a common issue with OLAP there row-level access has been introduced. It is requiring only mediated access by predefined programs executed.
There is not anything within SAS solving your question to views to isolating those partial datasets.
If SAS with some coding is an option for your users, they always can find a way to access all data. It is becoming like a kids hiding game (obscure = hiding).