Lock down EG project?

[railfan1975]

Back when I used Microsoft Access more often, I remember there was a way to create a database with a GUI and lock it down so that I could share it with an end-user and the end-user could not modify it in any way.  It had the added benefit of being able to run without the end-user actually having to install Access.

Is there a way to do something similar with a SAS project?  I'm pretty sure the bit about it running without the user having SAS installed isn't possible, but how about the locking down so user cannot edit and possibly providing the user a GUI?

Thanks!

Jonathan

[Reeza]

Do you have a SAS Server? If so can look into Stored Procedures.

[jakarman]

Your question is about IT governance. (ITIL release management, change management, version management)  In a detailed aspect:

a/ who is allowed to do what actions

b/ how this is technically implemented

c/ the continuous evaluation of a and b  (monitoring alerts/events improvements)

The good news is:  there are a lot of options to implement this.  

The bad news is:  there are a lot of options to implement this.  

You have to describe exactly your needs and environment.

Sometimes it need to be solved as part of a common IT-service (RBAC LDAP AD OS controls)

Sometimes you need to solve it by using the third-party toolings (external RDBMS systems)

Sometimes you can use SAS server services (SAS metadata platform administration)

Sometimes you need to code it into sources (row level access)    

Nice to see the origin of a lockdown questions, MS-Access as readonly version.
There is a lockdown option with SAS it will block a lot of functionality. It something different as you are asking for. 

[SASKiwi]

There is no way to run an EG project without EG being installed, unless you export your project to SAS programs. Regardless you would still need either a local or remote SAS server for running either the EG project or the exported SAS programs.

[Doc_Duke]

As Jaap points out there are lots of ways to attack the Data Governance issues.  We have found that it is partly technical and partly behavioral.

Locking down data and code stored in the OS is pretty straightforward.  Locking down an entire EG project might be something you could do, but you could also cripple it beyond any value. 

EG stores the SAS logs in the project.  Those are always generated, so there is always writing going on.  That means the (temporary) copy of the project that is being run must have write access.  You can lock down the copy on disk, but it won't keep users from messing with it while they are using it.

[ChrisHemedinger]

There are good discussions here about the pros/cons of "locking" an EG project -- it's always a good idea to define exactly what behaviors you're trying to encourage or prevent, and then look to see what technology toggles, if any, can help to achieve that.

From an EG project file perspective, you have these options:

• Encrypt the project file with a password.  (File->Project Properties->Security)  This will require that anyone who opens the project supply a password before being allowed to open it.  There is no "read/write" password concept -- either you can open it or you can't.  It's no secret that the EG project file is a ZIP file format; this password is on the ZIP archive.  Use this option with caution, as SAS Tech Support can't help you to recover a lost password.
• Make the project file READ ONLY.  Use the operating system features to mark the file as Read-only, and then users cannot save/overwrite the file in place.  This prevents unintentional modification of a project file while still allowing a user to run the project and see results.  It does not prevent a Save As operation, where a user makes a local copy of the file in a writable location.
• Use roles/capabilities in SAS Metadata to prevent users from modifying/running/saving projects within EG.  This feature allows a SAS administrator to designate who can use certain EG features, including modifying/saving certain properties of the EG project file.  These role-based behaviors would apply to a user across all project files he/she accessed, not just a select subset.

You can probably imagine using a combination of these techniques to control access.  In my opinion, locking down the EG capabilities in this way would offer only limited effect.  If you truly want a read-only, opaque process that an end-user can trigger without exposing too much IP, it's better to consider a stored process on a central server.

Chris