Can I control access to workspace servers by function?

[BobD]

Hi,

To correct an issue with respect to RSA authentication with Enterprise Miner (which uses expiring passwords), I created a workspace server in a new "Application Context" named SASEMApp and set it up to use SAS Token Authentication.  That fixed our problem and works just fine as long as the user selects the second workspace server from the drop-down list when the log into EM.

Is there any way to configure EM so that the correct workspace server is the only one available?  If they forget, the default is the "normal" server (SASApp), which will let them in okay, but any tasks they perform will fail.  Users start EM via Java Web Start.

Similarly, is there any way to prevent this new workspace server from being displayed as an available server from within Enterprise Guide?

In other words, I want all Enterprise Miner sessions to use the SASEMApp workspace server and I want all other clients (like EG) to only use the SASApp workspace server.

Is that possible?

Thanks!

Bob

Message was edited by: bob duell BTW - This is SAS 9.3 TS1M1 and Enterprise Miner 7.1

[PaulHomes]

Hi Bob,

That's a great question.  I have pondered this type of thing myself a number of times in the past (in my case with EG, where the EG users had their own dedicated app server for running their projects).  My first choice was to use metadata access controls to effectively hide the SASApp server from the EG users by denying RM to PUBLIC and granting it back to SAS admins, SAS services and those other groups who should see it.  The SAS EG users couldn't see it by exclusion.  Then the other app server (SASEG) was made visible only to the SAS EG users by denying RM to PUBLIC and granting it back to SAS admins, SAS services and the EG user groups.  Whilst that worked fine for EG usage, being purely identity based security, it meant that those EG users couldn't see or use the SASApp server in other SAS clients (in my case it caused issues in their use of the SAS web apps), so I ended up abandoning that approach.  I did set a default application server for EG but since the users could easily/accidentally switch over to SASApp, confusion arose, and assistance was required to help them switch back again, when their projects failed because they were trying to use resources not available on that app server.

If you do get an answer to your question I would be keen to hear about it.  I would love to know if there is already a way of robustly implementing this type of client/application level partitioning.  If not, something I'd be interested to see in a future version of SAS would be client/application level security too. Perhaps where SAS clients, in addition to users, have to be authorized to use servers/resources. Perhaps EG can see a server where EM can't and vice versa. Maybe a user could access a library in one client but not in another.  If not security, I have also wondered whether clients could be made to query extended attributes on resources to find out whether it is appropriate for that client to use those resources.  I could imagine a setting that tells EG or EM that the server is unavailable for use by EG or EM.  I know EG already queries the AssignMode attribute on libraries to determine how it should assign them, so this could be something similar: i.e 'EG (or EM) please ignore this server and don't show it to any EG (or EM) users'.

Cheers

Paul

[BobD]

Thanks for the reply, Paul.  I should have given credit for solving my SecurID problem; it was your suggestion to my original question that led to the solution.

I'm also eager to hear if this can be done.  I keep thinking, with all the hundreds of pages of documentation about things like this, surely there is some way to set this up.  I have a track open with SAS Tech Support where (among other things), I've asked the same question.  If we come up with an answer, I'll be sure to post a follow-up.  The initial suggestion was also to define ACLs, but it looked complicated and possibly difficult to maintain.  Your experience trying that route tells me to keep looking.

Thanks again, and here's hoping there are some other SAS BI "administrators" following this group and willing to jump in.

Bob

[BobD · Accepted solution]

I just want to provide a follow-up on the solution we came up for my problem. (Kudos to Andy at SAS Tech Support for all the help).

The first thing we did was create a SAS metadata "group" and add all our Enterprise Miner users to that group.  Next, we modified the new SASEMApp workspace server in SMC and "denied" all permissions to the "SASUSERS" group.

The other thing we did was modify the properties of the "SASApp" workspace server defined in metadata using the "Enterprise Miner" plugin.  We changed the "path" in the options tab to a phrase "Do not use this server for EM, use SASEMApp" and checked the box to prevent users from changing that location.  This way, if someone attempts to start an EM project using the wrong server (SASApp), the initialization will fail becasue that "path" does not exist.  It's a bit of a kludge, but at least it gets the job done.

This is not a completely satisfactory solution, but it solves a least one major problem:  Now when users that are NOT in the "EM Users" group connect to the server with Enterprise Guide (EG), they do not see the other workspace server (which we defined with token authorization).

At this point it's a "coaching" issue with our EM users.  We need them to be aware that when THEY use EG, they must never submit tasks to the "SASEMApp" server.  I wish we had a solution for this one as well, but at least the risk of this error is limited to a small group.