In the previous section, we compiled and installed a COM+ application that contained our example component. We used .NET attributes to specify the COM+ security settings, but we need to complete the component configuration before the component can be used. In this section, we demonstrate how to assign roles to Windows user accounts and then continue to demonstrate how the COM+ administration tool can be used as an alternative to .NET attributes or as a means to alter the security configuration specified using attributes.
The collection of COM+ applications installed on a computer is called the COM+ Catalogue. The catalogue is administered with the Component Services tool, which is included in the Administrative Tools section of the Windows Control Panels. Figure 19-5 shows the Component Services tool as it appears when first started.
Expand the Component Services tree and drill down to the COM+ catalogue for the local computer; Figure 19-6 shows the list of COM+ services for a standalone computer. The list of applications includes our example application (called SecurityProTracker, named after the assembly we created) as well as system applications that operate as part of Windows.
Expand the SecurityProTracker item, and you will see details of the COM+ application that we created in the previous section. The Component Services explorer provides information grouped into Components, Legacy Components, and Roles. Expanding the Roles item lists the roles defined by the application, as shown in Figure 19-7.
You will see icons representing the roles that we specified with the SecurityRole attribute; these roles are Developer, Manager, Tester, and User. You will also see another role, named Marshalersee the sidebar for details. The COM+ system processed the attributes from our assembly to create these roles, but they are not yet assigned to user accounts, and so clients cannot access our component. In this section, we demonstrate the simple process of assigning roles to user accounts in order to complete the configuration of our example component.
The COM+ Marshaler Role
When you install a serviced component that uses the SecureMethod attribute, the COM+ system will automatically create the Marshaler role. The SecureMethod attribute indicates that you wish to apply RBS access control on individual methods defined by the component, so that, for example, users assigned the User role are able to access only the ViewAllDefects method.
The problem this creates is that users with this role have not been granted permission to create new instances of the component or to manage the disposal of component instances (because the constructor and the methods of the IDispose interface are not exposed to the Developer role).
When assigning a role that has been applied to individual methods, you should also assign the Marshaler role. Assigning the Marshaler role to a user account grants that account permission to create new instances of a component, and to call the methods defined by the System.IDisposable, System.IManagedObject, and System.EnterpriseServices.IServicedComponentInfo interfaces; in essence, assigning this role confers the right to create and manage instances of a serviced component.
To assign a COM+ role to a user account, expand the role to reveal the Users item, and right-click to display the menu shown in Figure 19-8.
Select the User item from the New menu to display the dialog box illustrated by Figure 19-9. Assign a role by typing the name of the user account into the text boxyou can specify multiple accounts by separating the account names with a semi-colon. A useful feature is the ability to assign a role to a Windows group, which is equivalent to assigning the role to all of the individual accounts contained within the group. Figure 19-9 illustrates adding the users Tim, Tom, Tammy, and the group "QA Group" to the COM+ Tester role.
Pressing the OK button in the Select Users or Groups dialog assigns the roles to the specified accounts and groups; Figure 19-10 shows the effect of adding Tim, Tom, Tammy, and the QA Group to the Tester role.
You can see what access has been granted to individual roles by expanding the Components section of the COM+ application display. Our example application contains the single component we created earlier in the chapter; expanding this item shows the Interfaces and Subscriptions items. You can see which roles have been granted access to the SecurityProTracker component by right-clicking on the component icon, picking the Properties menu item, and selecting the Security tab, illustrated by Figure 19-11.
You will see that the Manager role is checked, meaning that user accounts assigned this role are permitted to access all of the members defined by the SecurityProTracker component. If you expand the Interfaces item, you will see a list of the interfaces that the SecurityProTracker component implements; most of these are created by the COM+ system automatically. Expanding the IDefectTracker item lists the individual methods defined by our functional interface, shown by Figure 19-12.
You can see which roles are granted access to a specific method by right-clicking on a method icon, selecting the Properties menu item and choosing the Security tab from the properties window; Figure 19-13 shows the roles granted access to the ViewAllDefects method.
You will see that the Developer, Tester, and User roles are checked, indicating that they are granted explicit access to this method, which is in accordance with our application of the SecurityRole attribute earlier in the chapter. The Manager role is listed in the Roles inherited by selected items(s) section, because the role was assigned to a parent objectin this case, to the component itself, which has the effect of implicitly granting access to all of the members defined by the interfaces it implements.
You can change the role configuration for a component by adding or removing check marks from the Security property page. For example, if you were to uncheck the Tester role for the ViewAllDefetcs method, the Tester role would have no access to any of the methods defined by the SecurityProTracker component, because the ViewAllDefects method was the only one to which you applied the Tester role.
COM+ allows both the component developer and the system administrator to manage the scope and application of RBS. In effect, this means that the configuration provided by the component developer provides an "out of the box" baseline configuration, which can be adapted to provide a customized configuration by the system administrator. It falls to the component developer to provide clear documentation explaining the baseline configuration and the effect of altering it. It falls to the system administrator to read this documentation and consider carefully the impact of making changes to the RBS configuration.
In the final section of this chapter, we will show you how the configuration options supported by the Component Services tool equate to the .NET attributes we used in Section 19.2.3.
Figure 19-14 illustrates the Security properties for our COM+ application example, which you can view by right-clicking on the application icon, choosing the Properties menu item, and clicking on the Security tab. These properties specify the settings for the security of the entire COM+ application, which applies to all of the components in the application. The options displayed in this window are equivalent to the functionality provided by the ApplicationAccessControl attribute.
The Enforce access checks for this application check box (indicated by the number 1 in Figure 19-14), enabling and disabling RBS and PAS at the application level, equivalent to the Value property; bear in mind that access controls must also be enabled individually for the components within the application. The Security Level radio buttons (indicated by the number 2 in Figure 19-14) specify whether PAS or PAS and RBS will be enabled for the application; this is equivalent to the AccessChecksLevel property.
The Authentication Level for Calls and Impersonation Level combination boxes (indicated by the numbers 3 and 4 in Figure 19-14) are equivalent to the Authentication and ImpersonationLevel properties; the drop-down list contains the definitions represented by the AuthenticationOption and ImpersonationLevelOption enumerations.
Figure 19-15 illustrates the security properties for our serviced component, which you can obtain by right-clicking on the component icon, choosing the Properties menu item, and clicking on the Security tab. These properties specify the security settings for the component, and each component within a COM+ application can be configured individually.
The Enforce component level access checks (indicated by the number 1 in Figure 19-15) enables RBS for the selected component and is equivalent to the ComponentAccessControl attribute that we applied to the SecurityProTracker class. If this checkbox is not checked, then RBS will not be applied to this component, irrespective of the application-wide setting.