Using COM+ Security
Understanding Web application security is more complex than just reading the COM+ security features, but let's see how those features apply to Web applications. Win2K or NT authentication services let you authenticate a component's user and obtain the user's credentials from Win2K; COM+ can handle the rest of component security.
Role-based security lets you define roles in COM+, then assign user accounts to those roles. Roles can control authorization at different levels in a COM+ application or component. After you define a role, you can use the Component Services explorer to assign the role to components at the class or method level. Then, you can check roles in two ways. First, declarative role-checking requires that you use Component Services to assign role-checking to a particular level. If a user tries to access a method and the user's account belongs to one of that method's roles, the call succeeds. If the user's account isn't in one of the method's—or its parent's—roles, the call fails. Second, application program security lets you check security against the COM+ roles in your code. If you choose this approach, you can control exactly what a user can do at any granular level.
You can't assume that COM+ solves all your security needs, however. For example, COM+ applications can interact with IIS in two ways, as Figure 1 shows. A COM+ library application runs inside the IIS process space, and a COM+ server application runs outside the IIS process space in its own process. As a developer, you might not know whether your component runs under a server or a library COM+ application. An administrator can change the setting for the COM+ application that contains your component at the flip of a switch. Then, your component could run differently because the COM+ application's behavior might change.
COM+ Server Applications
A COM+ application that runs as a server process is said to run "out of process." Let's take a look at a COM+ server application. To illustrate how COM+ security works, I created the component that Listing 1 shows. The test application in Listing 2 demonstrates how COM+ security works in a simple environment. You need to get security to work in a simple test application before you try to implement security in a complex application.
To administer COM+ applications, select Start, Program, Administrative Tools, Component Services. Next, expand Computers, My Computer, and COM+ Applications. Then, create a new COM+ application. Select COM+ Applications, right-click COM+ Applications, and select New, Application. Click Next on the Application Install Wizard, and click Create an empty application. Enter a name for your application. The default application type is Server, although you can change the type to Library here if you want. When you're finished, click Next. On the next page, set Identity to a particular account. You select an account by clicking the User button, then entering (or selecting) a username. Enter the user account's password in the Password and Confirm password fields. Then, click Next, Finish. Now that you have a new COM+ application, you can experiment with security options.
The first step in security for components running in COM+ is to control the account under which each component runs. When you created a COM+ application, you entered a user account for the Identity property. COM+ uses this account to run your application. For example, when a user accesses an application that uses a component in this COM+ application, the application runs under the Identity of that COM+ application's account. In other words, the OS thinks the Identity account is the user running the COM+ application. You need to assign to that application an account that has the correct permissions. I usually create a separate account for each COM+ application so that I can assign explicit permissions to that account. For example, if an application contains only components that access a database, those components don't need to run under an account that has open file-system permissions. So by controlling the account that your COM+ applications use, you inherently lock in one security level for all of that application's components. After all, if a component can't do anything bad, users can't do something bad with it.
At this point, your COM+ application can host components, and those components will run under the Identity account you selected. Now, let's add a component to the COM+ application by dragging the component (using Windows Explorer) into the application's Components folder. For this test, you can use my sample application COMPlusSecurity.dll (for download instructions, see "More on the Web," page 39). This DLL includes the class that Listing 1 shows.
Prev. page
1
[2]
3
4
next page 
