Thus far, you can check two aspects of security with the CheckIt method: First, if you call oSecurityCallCtx.IsCallerInRole("admin") and security isn't enabled, CheckIt returns True. This behavior is the same as the behavior of Microsoft Transaction Services (MTS), from which many readers might be upgrading. You would expect CheckIt to return False for all roles if security is off, but CheckIt doesn't return False because I don't think it's implemented correctly in either COM+ or MTS. Second, to check role membership properly, you need to call both IsSecurityEnabled and IsCallerInRole, as the pseudocode in Listing 3 shows. The pseudocode first checks to see whether security is enabled, then performs the role check. If either check returns False, the pseudocode calls the PerformErrorHandling function. Packaging both of the role membership checks into one function that takes a role as a parameter simplifies the process. The CheckRole function that Listing 4 shows implements this dual check. You can execute this method, for example, in the following If...Then statement:
If CheckRole("admin") Then
Before working with roles, you must turn on access checking for the COM+ application to enable role checking in the application. Right-click the application name in Component Services, select Properties, then select the Security tab. Next, select Enforce access checks for this application. If you rerun the test application, it now fails because Component Services is checking the user's security and denying access to the component. To use this application's components, you must have at least one role that has users.
Creating and adding roles works the same way in COM+ applications as in MTS. To add a role to the Roles folder, expand the COM+ application in Component Services. Next, click the Roles folder, right-click the folder, then select New, Role. Next, enter the role's name, then click OK. Now you can add users to the role. Expand the appropriate role, then click the Users folder. Next, right-click the Users folder, then select New, User. In the Select users dialog box, select the users or groups that you want to assign to that role. The users should appear in the appropriate roles, as Figure 3 shows. No one can use a COM+ application's components until that application has assigned roles. If a user tries to access the application, that user receives a Permission denied error.
To add roles to a component, right-click each class in the Components folder, then select Properties. Click the Security tab, select the roles that can use the class, then click OK to update the changes. You can use the CheckRole function to determine whether a user is in a specific role. You can also check the roles within your code to add fine-grained security, restrict management functions to management users, and so forth.
COM+ Library Applications
A COM+ application that runs as a library process is said to run "in process." Many, if not most, Web applications that use COM+ run applications as library applications. When an application runs as a library application, it runs in the calling process. The security context for an application comes from the calling process, not the COM+ application.
To enable role-checking in a library application, you must set the application's security to component-level security. Open the application's Properties dialog box, click the Security tab, then in the Security level section, click Perform access checks at the process and component level. The only way to pass the security context to the COM+ application—and, thus, the only way your code can access role status—is to select this button.
If you want to check users with COM+ security, the users must log in with a valid Windows account. If you set up Basic authentication, you can use the following code in your ASP script to force users to log in:
<%
If Request("LOGON_USER") = "" Then
Response.Status = "401 Unauthorized"
End If
%>
I used the Visual Basic (VB) application in Listing 2 for testing because it's easy to use and doesn't use IIS, SQL Server, or other technologies. This VB application lets you test the component—and even some security settings—before moving on to data-driven Web applications. After you load the component into the application, open WinAppSecurityChecker.vbp in VB. On the Project menu, select References to ensure that the COMPlusSecurity component is registered.
Now, press F5 to run the test application. Figure 2, page 37, shows what the interface looked like after I clicked the Check Enabled button. The returned text shows that security is on. If you configure your COM+ application as I did and run the test application, clicking Check Enabled initially returns False. So far, you haven't enabled security for the COM+ application, and the security system isn't picking up the caller's identity. After you click the Check Enabled button, the form executes the CheckIt method that callout A in Listing 2 shows. Then, the test form passes the string "enabled" to the CheckIt function, and the CheckIt function tests to determine whether security is enabled. Clicking the Check Role button causes the CheckIt function to test the component's current user and determine whether that user belongs to the Admin role. Clicking the Check Role button also determines whether security is enabled.
Prev. page
1
2
[3]
4
next page 
