Role-Based Security

COM+ offers a role-based security model that groups Windows users into COM+ roles. This model relies on the NT user accounts (tokens) associated with executing code as the basis for identity. To gain access, these users must belong to a COM+ role that has been assigned access to the class.

This simple model is used to enforce basic access to your components.

Adding and Associating Roles

You can programmatically add roles to a COM+ application and associate those roles to your methods. The SecurityRoleAttribute attribute is used to mark your component with the appropriate role. When registered, .NET will verify that the intended role exists within the COM+ catalog. If not, .NET will add the role to the application. The following example associates the role TestRole with the classes in your assembly.

<Assembly: SecurityRole("TestRole")>

In addition to the assembly, you can also associate security roles at the class, method, and interface levels. Marking a method with the SecurityRole attribute, for instance, indicates that only those roles marked have access to the actual method. Figure 17.1 illustrates the COM+ catalog interface for setting this information. The example shown is for setting a class-level property.

Note that you can also add roles and users to those roles through the MMC interface. Figure 17.2 illustrates this interface.

Security Call Context

The SecurityCallContext class provides your application access to the COM+ security context. This provides you with the capability to know who is requesting the application, down to the account name and call chain.

To create an instance of the SecurityCallContext, you use the CurrentCall property within your serviced component. CurrentCall is a static property that returns a valid instance of SecurityCallContext. For example, the following code creates a valid SecurityCallContext object:

'local scope
Dim mySecurityContext As System.EnterpriseServices.SecurityCallContext

'call static method to get security context
mySecurityContext = _
    System.EnterpriseServices.SecurityCallContext.CurrentCall()

To know the principal caller (that is, the identity of the person or application that made the direct request for your method or component), you access the DirectCaller property. To return the chain of current callers, you access the Callers property, which returns an instance of the SecurityCallers class. This class is a collection of all callers in the chain leading up to the current call. You also have direct access to the first caller in the chain using the OriginalCaller property. Both DirectCaller and SecurityCallers.Item return an instance of the SecurityIdentity class. Table 17.3 lists the properties available to you through the SecurityIdentity class.

Note that you must turn on authorization at the application level for the security context to be made available to your application. You do this from the Security tab on the Application Properties window. Figure 17.3 provides a screenshot.

Listing 17.2 demonstrates controlling security from within the actual method call. Suppose that all roles have access to the actual method. However, you want to block certain portions of the method to users who are not of a certain level. This example simply gets the security call context and uses it to check the IsCallerInRole method.

Listing 17.2. Security Call Context

Imports System.EnterpriseServices

<Assembly: ApplicationName("rbApp")>
<Assembly: System.Reflection.AssemblyKeyFile("rbSec.snk")>

Public Class rbSecClass

    Inherits ServicedComponent

    <AutoComplete()> _
    Public Function execute() As Boolean

        'purpose: demonstrate COM+ role-based security

        'local scope
        Dim mySecCtx As SecurityCallContext

        'set the current security context
        mySecCtx = SecurityCallContext.CurrentCall()
        'check to see if the caller is in the access role
        If mySecCtx.IsCallerInRole("Access") Then
            Return True
        Else
            Return False
        End If

    End Function

End Class