Microsoft Transaction Server (MTS) simplifies managing component and interface security by using roles. A role is a symbolic name that defines a logical group of users for a package of components. Roles determine which users are allowed to invoke interfaces in a component. A role is similar to the idea of user groups in Windows NT.
MTS security also uses the concept of packages. Packages are groups of in-process components (DLLs) that compose your application's business services. You can configure security for the package and not the individual components. This makes the administration of component access much easier. All components in a package run with the same security.
As you plan the components in your enterprise application, you need to understand that there are two ways to protect component interface access: client impersonation and client authorization. For the reasons described here, client authorization is the preferred method.
Tip The Microsoft Management Console (MMC) provides a framework for configuring and managing Microsoft Transaction Server. You can administer Microsoft Transaction Server with the Transaction Server Explorer found in the Microsoft Management Console.
Consider the situation where you've created a server providing file access. Without impersonation, any user accessing your application through your server has the identical access rights as your server, probably administrator access rights. This can be a security problem: the access rights should be no greater than those rights already assigned to the user.
Windows NT lets a process take on the security attributes of another process through impersonation. With impersonation, the server uses the client's access rights to complete a task involving objects, which the server does not normally have access.
Client impersonation means that access is provided explicitly to each client for only permitted interfaces. This means that when developing your application’s components, you need to code each interface to be aware of and check each client’s access privileges.
This presents an administrative challenge for your enterprise application because, as clients are added, you must continually modify the component's interfaces to recognize the new client permissions.
With object pooling, another consequence of client impersonation is the extra time required to complete the interface method. For example, changing the user ID of a database access component causes additional connect and disconnect time because the previous connection belonged to another client.
Client impersonation is not a good choice for setting up and maintaining component interface security.
Client authorization means that the component runs with its own user ID — not one temporarily borrowed from the client. During development of your application's components, you define permissions to each interface using roles. When a component checks for access permission, all it has to do is determine if the client is a member of the permitted role. You can assign users and groups of users to roles.
A major performance benefit of client authorization is that the connection to a database is done only once. There is no need to connect and disconnect for every different client.
If your enterprise application uses Microsoft Transaction Server, you should use client authorization and roles to configure the component access security.
For More Information For more information on the security features of Microsoft Transaction Server, search for "Enabling Package Security" in MSDN Library Visual Studio 6.0.