Microsoft Transaction Server (MTS) is the component management platform that provides the primary Distributed interNet Architecture (DNA) on Windows NT 4.0. (its cousin, COM+ Services, performs the same function on Windows 2000.) The Component Object Model (COM) allows you to create generic units of business logic, which ideally can be used in Active Server Pages (ASP) applications as well as in traditional, form-based Windows applications. MTS provides a common runtime environment for such ambidextrous components. In my May 2000 article, “Processing Transactions with Microsoft Transaction Server”, you saw that MTS facilitates database transaction processing, but this is just one MTS feature related to application security. This article will explore other MTS features that are designed to enhance a component application’s performance in secure environments. Note that COM+ Services for Windows 2000 provides all of the MTS security features and more, although this article will discuss only the common MTS features.

The most important factor in computer security is resource access. MTS maintains access control over COM components, allowing programmers and administrators to determine how and by whom component functions are used. Sets of components can be installed in MTS (via MTS Explorer wizards) as a package that has an associated user context, thus providing declarative security. Components can also be developed by employing a degree of programmatic security, meaning that the component authenticates a user at runtime against a set of predefined roles for the component. A careful combination of declarative and programmatic security is a good solution for most applications.

MTS Packages

The first step to securing components is installing them in an MTS package. An MTS package may contain any number of installed components. An empty package can be created easily with the MTS Explorer tool. Simply right-click the Packages Installed folder in the left pane, then select New Package. As shown in Figure 1, you can either create an empty package to be filled with your components at a later time or create one that contains an ActiveX component already registered on the machine (ActiveX COM components are simply the class of components that implement the IDispatch introspective interface).

Many popular Windows development tools, including Visual Basic, Borland Delphi, and ASNA Visual RPG, can be used to create ActiveX components that are suitable for MTS. These tools give the programmer the means to quickly prototype and test component business logic. Once created, the component must be installed in an MTS package. Installation with the MTS Explorer applet is usually just a few mouse clicks. Right-click on the Components subfolder (under the folder created in the previous paragraph for the new package) and select New Component. Then you can select the file (usually a Dynamic Link Library or DLL file) containing your component or choose from the list of MTS-compatible components already registered on the machine. The components you add to a package should share a common usage or access pattern, since the package provides a context for controlling these behaviors.

Windows NT Security and MTS Roles

MTS user security is based on the NT security platform of Windows NT and Windows 2000, in which individual users and groups of users form the hierarchy of authority to system resources. Membership in a group often reflects a user’s authority in an organization (e.g., the administrators group, the sales group). MTS takes the same approach in assigning component role identities. For example, in an MTS e-commerce environment, you could assign roles to restrict the Web shopping application users from accessing certain components used by the sales staff’s inventory application. As shown in Figure 2, the MTS Explorer applet is used to create roles. In the left-pane tree view, each package consists of two subfolders: Components and Roles. To add a role to a package, simply right-click on the Roles folder and select New Role. A dialog box will prompt you for the name of the new role. The new roles appear under the Roles subfolder. To make a role useful, you should add users to it. Expand the role in the tree view to display the Users subfolder, then right-click on it to select New Users (Figure 2). This brings up the User Manager dialog, familiar to NT users. The dialog displays a list of NT users and groups for the machine and network domain, which may be added to the role. This operation is performed by the system administrator of the application during or after deployment.

To complete the MTS authority mapping, assign the package’s components as members of one or more of the roles just created. Not all components require role membership, only the components that require special authority. Expand the Components subfolder to view the components you want to assign, then expand one of the components to be secured, which reveals the Interfaces and Role Membership subfolders. Right-click Role Membership to assign the component to one of the roles created, as in the previous paragraph.

Programmatic Security

Once the roles-and-users mapping has been established, MTS components can query the role membership of a user at runtime. (This is most useful when it is necessary to limit the component’s functionality.) Using the MTS built-in ObjectContext object, the two methods to use are IsSecurityEnabled and IsCallerInRole. The IsSecurityEnabled method returns TRUE when security is available for the component; it merely tells you that the IsCallerInRole method can be used. The IsCallerInRole method takes a string argument that is the name of a role. If the current user is a member of that role, the method returns TRUE, as shown in the following code:

Dim objContext As ObjectContext
Set objContext = GetObjectContext()
If objContext.IsSecurityEnabled() = True Then

If objContext.IsCallerInRole( “Admins” ) Then

‘ Code here for operations limited to
‘ the Admins role.

End If

End If

The IsSecurityEnabled method always returns TRUE unless the package has been installed as a library package. In the Properties dialog for the package, click on the Activation tab to select library or server process activation. Since library packages run in- process with the client application, they run with the authority of the client. This saves runtime overhead associated with the enhanced security control.

Declarative Security

It may not always be wise to hardcode security roles into the component as you would with programmatic security. The roles-to-components mapping facilitates declarative security, which allows MTS to decide when a user does not have access to the functionality of a component. When declarative security is enabled for the package, only a user assigned to a role that a secured component is also assigned to can access the component. Thus, declarative security provides a measure of fail-safe protection from unauthorized users. To enable declarative security for the package, view the Properties dialog of the package, click on the Security tab, and check the Enable authorization checking checkbox.

Package Identity

MTS roles allow you to specify which users can access which components, but, in certain applications, simple user access control is not sufficient. For example, some components may be required to run under a specific authority. In this case, MTS will provide either a package identity or an NT user that components of the package will run under the authority of. By default, this is set to the Interactive User account (i.e., the user that accessed the package’s components). However, this can be changed to any valid NT account by using the Identity tab of the package’s Property dialog. This is extremely useful when a data source should be accessed with a single, generic account rather than as the connecting user, as it facilitates data source pooling techniques. Beware, however, that the identity of a package affects its use of other packages. For example, if an external package’s roles exclude the identity of the current package, the external package cannot be accessed, even if the original interactive user account is a member of the external package’s roles.

Many DNA subsystems besides MTS participate in distributed application security. To fully appreciate the methods available for securing Web-centric applications, you should also consider other Windows NT, Windows 2000, and Internet Information Server (IIS) security features.

REFERENCES AND RELATED MATERIALS

• Microsoft COM Web site: www.microsoft.com/com
• Professional MTS and MSMQ with VB and ASP. Alex Homer and David Sussman. Olton, Birmingham, United Kingdom: Wrox Press Ltd., 1998
• Windows NT Server Downloads Web page: www.microsoft.com/NTServer/all/downloads.asp

Figure 1: MTS Explorer simplifies the configuration of MTS components, roles, and other component runtime characteristics.

Figure 2: IUSR_HUISACHE, the default user account, is added to the WebSurfers role of an application package.