19.1 COM+ Security Explained
A .NET class that uses COM+ services is called a serviced component or a configured class. A COM+ application consists of one or more serviced components, which are administered together; there is no requirement for the components within a COM+ application to interoperate, although typically a COM+ application comprises components that offer related functionality.
A serviced component makes functionality available to a client application by implementing one or more interfaces. The client application creates a new instance of the component class and consumes the functionality exposed by invoking the component members. The use of COM+ is not visible to the client, which uses a serviced component in the same way as any other .NET class.
There are three types of COM+ application, illustrated by Figure 19-1, where the application type affects the way in which instances of serviced components are created. We summarize the application types as follows:
The type of application affects the COM+ security services that you can apply. COM+ security consists of role-based security (RBS) and process-access security (PAS). RBS controls access to components and their methods, and is applicable to all types of COM+ applications, irrespective of the number of processes or computers involved. PAS is responsible for coordinating security between different processes, and can be applied only to server applications and application proxies.
Figure 19-1. COM+ application types
19.1.1 COM+ Role-Based Security
The most widely used aspect of COM+ security is RBS, which determines which clients may access the functionality provided by a serviced component.
Access to a serviced component is based on the identity of the user account that is executing the client application. COM+ applications define roles, which the system administrator assigns to Windows user accounts. Roles can grant a user access to the entire component or to individual methods within the component. Both the component developer and the system administrator create COM+ roles and associate them with components or component methods, as shown in Figure 19-1. We demonstrate how to define roles programmatically in Section 19.2 and how to use the COM+ administration tool in Section 19.3.
The COM+ RBS system acts as a "gatekeeper" between client applications and serviced components, as illustrated in Figure 19-2. When a client application invokes a serviced component method, COM+ determines the identity of the user account executing the application, assesses which roles have been assigned to the account, and permits or rejects the request based on the access granted by the assigned roles. For example, if the user account "Alice" is executing an application that invokes a method that requires the Developer role, COM+ RBS will grant access only if the system administrator has assigned the required COM+ role to Alice's user account.
Figure 19-2. COM+ role-based security acts as a gateway between the client and the serviced component
Although the programmer can define COM+ RBS roles, only the system administrator is able to assign those roles to Windows user accounts; see Section 19.3 for more details.
19.1.2 COM+ Process-Access Security
PAS applies to server applications and application proxies only; PAS is responsible for the trust relationship established between the processes that contain the client application and the serviced component. There are two aspects of PAS: authentication and impersonation.
PAS authentication verifies the identity of clients trying to invoke serviced component methods; in the previous section, we explained that COM+ RBS uses the client identity to grant access to serviced components, and it is essential that we are able to identify a client accurately if we are to rely on COM+ RBS.
In COM+ server applications and application proxies, the client and component reside in separate processes; a malicious client could attempt to assume another identity in order to bypass role-based security. COM+ PAS provides a range of authentication levels that you can select for your project; we summarize these options below:
In general, the more security provided by an authentication option, the more system resources required to perform the authentication checks. It is important to select an authentication option that is appropriate for your project; always selecting the most secure option results in the needless consumption of computer resources and places an unwarranted burden on client applications.
The authentication level used between the client and component processes depends on the configuration of the client as well as the COM+ application. The client and the serviced component declare their desired authentication options, and the most secure option is used; for example, if a component is configured to request Packet Integrity and the client is configured to request Packet Privacy, then Packet Privacy will be used.
In a COM+ library application, the issue of authentication does not arise; instances of a serviced component are created within the same process as the client application, and the identity of the caller is always known to be the owner of the client process.
It is common for serviced components to perform tasks on behalf of the account that executes the client application. For example, consider a serviced component that defines a method to write a record to a database. The client application calls the component method to write the record; the component may need to connect to the database and write the new record using the account identity to gain permission to write to the database and to create the audit trail correctly. When a component adopts the identity of a client, it is impersonating the account identity. Figure 19-3 illustrates impersonation.
Figure 19-3. A serviced component can impersonate a client account in order to carry out tasks on behalf of the user
COM+ PAS defines several levels of impersonation, which we summarize in the following list:
The level of impersonation is specified by the client application and is an expression of the level of trust that the client has in the integrity of the component. When a client specifies the Anonymous impersonation level, the component cannot access the client identity; when specifying the Delegate impersonation level, a client must fully trust the integrity of the component, because it can act on behalf of the user to perform any kind of task.
There is no direct .NET support for a client application to specify a COM+ PAS impersonation level; a native method must be used consult the Windows Platform API for full details. In the next section, we demonstrate how a component can specify an impersonation level for when it communicates as a client.
For a serviced component, the value of impersonation becomes apparent when invoking the methods of another COM+ component, where the calling component becomes, in effect, a COM+ client application. Under these circumstances, the calling component specifies an impersonation level to define the level of trust that is granted to the called component. In the next section, we show you how to use the ApplicationAccessControl attribute to set the impersonation level your component will use when acting as a client of other COM+ components.