I'd like to be able to create an SP to be run from the Portal that can report on secure data, and use Stored Process Server to get efficient execution (don't want each query to start its own workspace) but prevent Enterprise Guide users from running their own code on the same Stored Process Server and circumventing data security by running under the server identity.
If I secure the Logical Stored Process server in metadata I can prevent EG users from connecting to it ... but then if one of those users logs on to the Portal they can't run the canned Stored Process because the server is not available to them. If it's available to the Portal I can't see any way to stop the EG user running an SP there.
Is there some way to set up an SP server that the Portal can use, but which EG users can't see?
This is under 9.1.3 by the way, so a 9.2 method won't help (at least not for a while)
Good idea, but the there is overlap between Portal users and EG users, so I can't segregate them that way.
I was wondering about setting up an SP server running under a different identity (rather than sassrv, something with a bit lower privilege that can't see the data by default) and then use a compiled macro to access the required hidden path, but only if the 'right' _PROGRAM value is present. Seems a bit convoluted, so I was hoping someone had found a better method before I try setting all that up.