I may not be entirely accurate on this...but I recently solved a similar problem.
From what I understand...
When EG sends a job to the server it is under your login...when the object spawner gets the request to set up the job, it creates a Workspace Server session (or Stored Process session) using the sassrv login. We needed to create a sassrv user account on the Windows server under Windows in order for this to work. I'm not sure what we did about a password...I don't think my admin set one.
There was a very good SGF paper co-authored by Peter Eberhardt on the use of the Stored process and Workspace servers and the differences between them.
As I understand it, SASSRV is the logon for the Stored process server, while the workspace server uses a process spawner to start processes using the clients authentication.
As we step through a migration from SAS on the desktop to an Enterprise model using EG, this type of query is relevant, and I was alarmed to realise that SASSRV would need to be given broad access to all tables in our foreign data sources if the clients were to be able to read their required data.
Reading your suggestion that SASSRV has this blanket access with a blank password is a little worrying. I didn't think modern security models allowed blank passwords, but if that is the case then you should consider whether having your data open to be read by anybody at all is really a good outcome.
I too was trying to remember what Eberhardt had said (it was a good presentation)....
After seeing his presentation, I tried a simple Stored Process. It would not work because of the sassrv login.
I spoke with my admin, he reminded me that the sassrv was set up with our BI install and it does have a password (however, you can set up a windows 2003 server user without setting an initial password...it may give it a default). We fixed our inability to run Stored Processes by making sassrv a member of certain groups (in SAS Management Console). Unfortunately, neither of us are sure which groups we added but here are the 4 groups sassrv belongs to...
Remote Desktop Users
SAS Server Users
I may have drawn the wrong conclusion, and the original poster provided possibly ambiguous details. However, mentioning server datasets and providing an error message that I have only ever seen from a foreign DBMS suggested to me that the issue was recognition of the server user on something like SQLServer or Oracle.
Where ODBC is used as the connecting method, the user name and password need to be known to the database either as a specific DBMS user, or as a user authenticated by the domain. So SASSRV needs a record in the Active Directory for the domain.
The relevant user groups will then be those on the domain, not those on the management console.
Tha hazard lies in making the SASSRV user available to all users on the SAS application server, which means someone who cannot authenticate to a given DBMS can then use the SASSRV permissions to gain cloaked access. This remains one of the biggest hurdles for our using the Stored Process server in the future.