Question:
We’ve developed a human resources system based on the principles advocated by Rockford Lhotka in VB6 Business Objects. We used a SQL 7.0 database and stored procedures in conjunction with ActiveX Data Objects (ADO) in the data services tier. We implemented security on the system as part of the stored procedures. The business services tier located in Microsoft Transaction Server (MTS) passed the calling user ID as a parameter to the SP using this code:
mCaller = moCtxt.Security.GetOriginalCallerName
Using a Win32 Visual Basic client and distributing the client objects with the VB front end, this worked perfectly. However, now that we want to develop a Web interface, we’ve run into some problems.
We are using Active Server Pages (ASP) to access the client objects (now located on the Web server, which is also the server where SQL resides). It works fine if the security in the SPs is disabled, but the problems start when the security is enabled. The server objects in MTS are passing “SYSTEM” to the SPs as the OriginalCaller, instead of the Web user (we’re using NT Challenge Response Web Security). Although we could redevelop the server objects to access the ASP ServerVariable – LOGIN_USER, we’d like to stick to the MTS solution. Can you please help?
Answer:
Instead of using GetOriginalCallerName to generate a parameter that will be passed to SQL Server, consider putting the burden of identification on the MTS packages and roles. First of all, ensure that your SQL Server is set up for integrated or mixed security. When setting up your package, create an NT user account designed specifically for that package. Configure that package to run in the context of that user. When your component attempts to access the database, it will do so under the context of that user. You will then map that package identity to a SQL login and give that login appropriate permissions.
This approach has a number of advantages, including easier database administration and consumption of fewer database connections. Further, you should create an NT group designed specifically for each role (for example, “manager_users” and “regular_users”) that is defined in MTS for your application. Each MTS role should have a different NT group dedicated to it. You will also want to make sure that any SQL Server ODBC data sources you use are set to “Use Trusted Connection” in the ODBC setup box.
Finally, create an additional NT group that will be composed of the NT user accounts designed specifically for packages. This will make it easier to map NT user accounts to SQL Server logins. It sounds as if you have done a lot of good things with your HR system. Consider trying my suggestions instead of using GetOriginalCallerName for your SQL Server login.
