To take advantage of the security and configuration technologies that MTS brings to the party, you should seriously consider using declarative security. This is the technique we described in the previous section of the chapter, where each component within a package checks the validity of each user against a set of roles defined for that package. It also uses its own special account to access other components.
MTS defines the concept of roles for each package installed within it. These roles are simply lists of NT user groups and accounts that should have access to components in that package. If the user isn’t authenticated as one of the users in the list, or as a member of one of the groups, they are denied permission to use the component.
In general—as with traditional Windows NT security methods—it's best to create groups and assign individual users to the appropriate groups, rather than assigning permissions directly to user accounts. This is the technique we'll be describing. Bear in mind that user accounts can be assigned to objects as well, if this is required in your application—such as the IUSR account or specific special user accounts. Be sure to use DOMAIN accounts and groups, and not local machine accounts which may not be available when the application is moved to its final location.
When a component calls the services of another component or service, it does so using a 'user' account. As we've seen, this doesn’t have to be the original user's account. In declarative security, we allow the component to act on the original user's behalf by defining a different account to be used in this context. This account is the identity of the package that contains the component.
As an example, which shows more clearly what the identity of a package does, take the Wrox Car Co application. Here we might have two types of user. One would be the sales staff in the showroom using an interface that allows them to query customer and car details, and place orders with the head office. The second would be anonymous users out on the Web who could place an order for a car, but could only query car details and not customer details.
The two types of user could access the application through different sets of components. However, as the act of placing an order is identical, the main components would be the same. The difference would be only in the 'top-level' components that they accessed directly. This means that we can set up roles and identities that allow each type of user access only to the appropriate components:
In the diagram, you can see that we have created three NT account groups. The group WCCShowroom contains the individual accounts for the sales staff in the showroom and the system administrator. The group WCCWebUsers contains three accounts. The first is the anonymous IUSR account, and the second is an account that is set up solely to be used with mappings from client certificates (you'll recall from the previous chapter that IIS can map selected parts of a users client certificate to a Windows NT account). Finally, the third account is that of the system administrator.
The last account group, MTSPackages, also contains three accounts. These accounts are the identities that are assigned to the different MTS packages in the application. As you'll see next, this group makes it easier to set up the access permissions for 'second-level' packages, and specify the login information for SQL Server or any other data source.
The MTS package containing the component accessed by showroom staff has only the WCCShowroom group assigned to its roles. Therefore only users in this groups will be able to access the component. The identity of this package is WCCShowroomProcess, which is a member of the MTSPackages group. This account will be used to access the components in the third package.
Likewise, the MTS package containing the Web user component will only be accessible to members of the WCCWebUsers group. The identity of this package is WCCWebProcess, which is also a member of the MTSPackages group—and this account will be used to access the components in the third package.
The third package has the group MTSPackages assigned to its roles, and has the account WCCPlaceOrder as its identity. It will use this account to access SQL Server. In SQL Server we give this group access to the tables and stored procedures required to actually place the order.
The end result of all this is that showroom staff and Web visitors can only access and run the components in their own 'top-level' package, i.e. Package1 or Package2. They don’t have an account in the MTSPackages group, so they cannot directly access either the second-level components (in Package3) or the database.
We could also have used an intermediate group, say WCCOrderProcess, and assigned the WCCShowroomProcess and WCCWebProcess accounts to it. Then we would specify this group in the roles for the third component, instead of MTSPackages. This may be appropriate in a more complex application. It's also appropriate to have more than one group assigned to the roles of a package if you want to allow different permissions to members of each group.
After assigning groups (or individual users) to the roles of a package, we define the mapping between individual components in the package and these roles. When declarative security is enabled, only the components that are mapped to the roles of the package will be able to perform authorization checking.
Using MTS Explorer we define this mapping for each component. This means that if a package has more than one role defined for it, each component can be mapped to a different role—allowing a finer level of control than when there is a single role defined for a package. You'll see we create roles, add users to them, and map them to components a little later.
Components don’t have their own identity. They always assume the identity of the package that they are contained in when declarative security is in use.
There is one other benefit of using a single NT account (or a limited number of accounts) to access the data source. Most ODBC and OLEDB data store drivers implement connection pooling, which greatly increases efficiency when regular access to the data is required—something very likely in a Web-based application.
Normally, the user name and password are part of the connection string used to access the data store, and this means that each connection can only be reused by the same account. On an Intranet where you have a large number of user accounts, the different username and password combinations will require a new connection to be created each time. One way round this is to create account groups based on the permissions required, and allocate all users to an appropriate group—reducing the number of different connection strings. However under MTS, where the data access components can all run under the same identity for all users, connection re-use is much more likely and so the connection pooling feature provides a real performance boost.
MTS provides a special package named System, which controls administrative access to MTS Explorer itself. By default, any user who has access to the machine where MTS is installed (or another machine if remote administration is enabled) can change the configuration of packages and components. We can prevent this by enabling security on the System package, so that only the users who appear in the roles of the System package will be able to administer MTS.
There are two pre-defined roles for the System package, Administrator (full access) and Reader (read-only access). You should add your administrator account to the System package's Administrator role, and any other relevant accounts to the Administrator and Reader roles, then enable security on the System package in the same way as you would for any other package.
Once declarative security is enabled, only members of the System package Administrator role will be able to administer MTS and the other packages installed in it. It's vitally important to ensure that you have assigned at least the Administrators group to the System roles, otherwise you will be locked out. After changing the settings, restart the package or reboot your server to initialize them.
Read this twice and remember it—always add the Administrators group or your own group or account to the System package Administrator role before enabling declarative security for a package. Otherwise you will be locked out and will have to re-install MTS to regain control.
To perform package and component configuration, we use the MTS Explorer snap-in for the Microsoft Management Console (MMC). Here we've opened out the tree to show the WCCFinanceTest package we installed back in Chapter 3. You can see that MTS Explorer provides our package with two main folders, Components and Roles:
The MTS Software Development Kit (SDK) contains a set of scriptable Automation objects that you can install into MTS. These allow you to write scripts to automate the operations that you normally carry out in MTS Explorer. For more details see the Automating MTS Administration section of the MTS Administrator's Guide.
This first step is to add the roles we need to the package. In our case there is just one, WCCWebUsers. Role names must be unique within a package, though the same role name can be used in different packages. To open the New Role dialog right-click the Roles folder and select New | Role, or use the drop-down Action menu in the toolbar:
Once the role is created we can add the appropriate users to it. Here, we're adding the IUSR account directly, plus the two groups Administrators and Certificated users. To open the Add Users and Groups dialog right-click the new Users folder for the appropriate role and select New | User, or use the drop-down Action menu in the toolbar:
Here's the result with our three users added to the WCCWebUsers role. Of course the real reason for including this screenshot was just to see the hats:
Now that we've created the roles and added the users to them, we can specify which components in the package will use each role for authorization checking. To open the Select Roles dialog right-click the Role Membership folder for the component and select New | Role, or use the drop-down Action menu in the toolbar. Only components selected in this dialog will use the roles to check that users have valid access permission:
The final step is to activate declarative security for the package by enabling authorization checking. This is done in the Properties dialog for the package itself. To open the Properties dialog right-click the name of the package and select Properties, or use the drop-down Action menu in the toolbar. The Security tab contains the checkbox that enables authorization checking. We also have a choice of five levels of authentication, with the default being Packet:
The other settings are only really useful with remote components, and in general you can use the default setting for all your applications. For more details look at the Setting MTS Package Properties topic in the Creating MTS Packages section of the MTS Administrator's Guide.
By default all components in a package will use declarative security once it is enabled for the package. However, we can change this setting for individual components. This is done with the Properties dialog for the component itself. To open a component's Properties dialog right-click the name of the component and select Properties, or use the drop-down Action menu in the toolbar:
We use the Properties dialog of a package to assign an identity to that package. In the Identity tab, the Account setting defaults to Interactive User—in other words the package will use the account that accessed it in the first place to access other components and resources. To set the package identity we specify the account we want the package to use by selecting This User and filling in the details:
Components can be run either in the client's memory space (as a library package) or within the dedicated server memory space (as a server package). This is defined in the Activation tab of the Properties dialog for the package. The default setting is Server Package. Running components in the client's process improves performance, especially when many calls are made to the component. However, you can’t use declarative or programmatic security when a component is being run within a Library Package.
And here's the final result showing all the roles, role members and users for the WCCFinanceTest package. Our component has only the default interface, but if it had more than one interface we could assign users and groups to each interface separately. This gives the finest level of control of all, but it is not usually required except in the most complex of components:
As we saw earlier, each package identity is a valid Windows NT account. To enable MTS to use the account to access other components or services, you must ensure that it has the appropriate settings. This is done using the Windows NT User Manager application (which we saw in the previous chapter). In the New User dialog, when you create the account, make sure you enter a suitable password to prevent users from being able to log on and impersonate the account if they know the username. In the same dialog set the User Cannot Change Password and Password Never Expires options:
Then click the Groups button and add this account to the Users group, as well as to the group you created for all MTS packages—in our earlier example this was MTSPackages.
Back in the User Manager main window, open the Pollicies | User Rights dialog, turn on the Show Advanced User Rights option and select 'Log on as a batch job'. Assign this user right to the accounts that will be used as identities, so that MTS can instantiate and execute the components and log onto other resources as part of a transaction:
If you have installed remote packages on other machines (something we haven’t tackled in this book), you also need to set the appropriate permissions using the DCOM configuration utility. Run
from your dcomcnfg.exe
directory, and make sure that you assign the correct default authorization and impersonation levels.Winnt\System32
Unless you have a thorough understanding of DCOM authentication levels, it is recommended that you leave the Default Authentication Level setting of your package at the MTS default of Packet. The Default Impersonation Level must be set to Impersonate:
For more details about the DCOM options available in MTS, check out the Setting MTS Authentication Levels section of the Creating MTS Packages topic in the Microsoft Transaction Server Administrator's Guide.