The code in the class that Listing 1 shows uses COM+ for all its work. The class's VB project has a reference to the COM+ Services Type library, which contains security objects. The code segment at callout A in Listing 1 dimensions the oSecurityCallCtx variable as type SecurityCallContext. The code segment at callout B in Listing 1 calls the GetSecurityCallContext method to set the oSecurityCallCtx. Callout C in Listing 1 performs the actual work. When the code passes "role" to the CheckIt method, as callout B in Listing 2 shows, CheckIt determines whether that user belongs to the Admin role:
oSecurityCallCtx.IsCallerInRole("admin")
When the code passes "enabled" to the CheckIt method, CheckIt uses the following function to determine whether this application has COM+ security enabled:
oSecurityCallCtx.IsSecurityEnabled()
Controlling Security with Custom Code
Suppose your components aren't running in COM+, your server is behind a firewall, or you don't use Windows security. You can still control security in two ways. First, you can—and should—assign an identity to the COM+ application. This identity can limit system-resource access to the component's user account, thereby controlling what the component can access. Second, you can create a granular security scheme for your components.
Controlling your own security requires major planning. You must decide whether you want to simply authenticate users or also control access to component features. Or perhaps you want to ensure that only your application code calls the methods in the components. Each approach controls security differently and with varying degrees of difficulty. I suggest setting up a database with a table structure, as Figure 4, page 39, shows. When a user logs in, check the username and password against the Login table to authenticate the user. Then, look up the user's ID in the LoginRole table to find the user's roles. The LoginRole table provides the role ID and names. Finally, retain the user's roles in your application and check them as you'd check COM+ roles.
The main problems with controlling your own security are twofold. First, you must create all the code to authenticate and authorize users—not a trivial task. Second, you must create the management tools to update users and roles—again, not trivial.
Trading Overhead for Custom Security
Whenever you apply security to an application, you have to make trade-offs. Custom security requires a good bit of coding overhead and lots of administrative overhead. Custom solutions usually require more overhead than packaged solutions, and you can't rely on the "plumbing" that COM+ provides because you're not using it. However, COM+ adds its own security overhead: All application users who use COM+ components must have valid Windows accounts and must log in correctly. But, because COM+ provides a valuable security system that ties into the OS, it has many advantages over custom solutions.
You also pay a performance price for security management. When you turn on security in COM+, COM+ manages your security information. But, security management adds a lot of overhead, which can adversely affect performance, especially on a heavily loaded server. The bottom line for component security is to analyze your requirements carefully, then plan your security system to meet those requirements. You don't want to use more or less security than you require.
End of Article
Prev. page
1
2
3
[4]
next page -->
