This is how we managed it: In Citrix we shared Internet Explorer as an application (but restricted clients from external web navigation via IE security settings with a login script). We did not want a client using our servers a means to surf the Internet or generate attacks to competitors. The home page of IE was set to our web portal. Using delegation and impersonation we took the Citrix Authenticated user and passed the credentials to the loader code class of the portal. That class kicked off an authentication process to an "authenticate" SQL DB. In this DB we had all the client DBs and client users and roles mapped. Once the loader authenticated this was an active user in the system, the loader would get the appropriate DB connection information and then pass it along in the user's web session. Did we encrypt it? Yes, we found that cross-site scripting attacks could be used to capture session information of other users. Encrypting the connection information in session meant the hacker would need to be on the physical web server and get to the page file or memory block at exactly the time any decryption algorithm was executed. Since this is not very likely, we supported the client requirements of data security at the DB connection level. In the DB, all connection strings and setting are stored in an encrypted form using a client-specific private key (the encrypted data comes from the "authenticate" DB).

So, now that the DB connection info was always available to this authenticated user, we had a way to marshall what DB connections were made. Note: We stored users' roles & other security settings in the session too. Once all this front-loaded logic was done the loader would make a connection to the portal home page and use the DB configuration data from the user. The loader would build out the user specific home page & content.

Now, when the user began to interact with the system by requesting and updating data, the request would hit a "controller" code first. This code was used by the service calls to marshall the execution of all system events. It defined the specific stored procs [??] being called via a configuration file. Then by using that name value would make calls to DB layer and request the stored procs execution. The stored procs we geared to roles by setting the SQL Server users allowed to execute them. So, if the user was not in the "Item Users Group" that user would not be allowed to execute "GetActiveInventoryItems" stored proc. In SQL server 2008 you can couple #C code within a stored proc, so we marshalled the specific data fields returned based on the mapped user role. The controls on the web page were dynamically built to support the user-specific content being returned. Meaning if there was a grid of items but only two columns were allowed for, this user the control would be adjusted to that role-specific data.