19.1 COM Security Explained | Programming .Net Security

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:

Library applications: This type of application creates new instances of serviced components within the process of the client application; the client and the component reside on the same computer.
Server applications: This type of application creates new instances of serviced components in a separate process than that of the client application but on the same computer. The client application invokes the methods of the serviced component using a Remote Procedure Call (RPC).
Application proxies: An application proxy allows a client application to invoke the methods of a serviced component on another computer. Method invocations are performed with a remote procedure call transmitted across a network, although the client application is unaware that the serviced component resides on another computer.

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 roles used by COM+ RBS are independent of the user groups supported by Windows. A system administrator must assign COM+ roles to user accounts before they can access components protected by COM+ RBS. If access to a serviced component requires a role, say Developers, then belonging to a Windows user group called Developers will not grant an account access to the component; the system administrator must explicitly assign membership of the COM+ Developers role.

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.

COM+ RBS is independent of, and incompatible with, the .NET Framework role-based security that we introduced in Chapter 10. You should use COM+ RBS when writing serviced components and when writing applications that interoperate with existing COM+ applications.

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.

19.1.2.1 Authentication

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:

None: PAS does not verify the identity claims of the client when this option is used; this option offers the least protection.
Default: PAS uses the default machine configuration to select an authentication option; the None option will never be selected.
Connect: The client presents evidence to support its stated identity, which PAS validates. All subsequent communication is insecure.
Call: The headers of each call from the client are cryptographically signed, but no other data exchanged between the client and component is protected, allowing the communications to be tampered with.
Packet: This option is similar to Call, but the headers of each data packet are signed. This is the default PAS authentication option for .NET serviced components.
Packet Integrity: Each packet of data sent between the client and the component is signed to prevent tampering.
Packet Privacy: Each packet of data sent between the client and the component is signed and encrypted to prevent tampering and to ensure that the entire communication between the client and the component remains confidential.

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.

19.1.2.2 Impersonation

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:

Anonymous: The client is anonymous to the component, and no identity information is available (this level of impersonation is available only when the client process and the component process reside on the same computer).
Identify: Allows the server to identify the client and perform access checks using the client's access token.
Impersonate: The component can impersonate the client identity to access resources on the local computer.
Delegate: This is the highest level of impersonation and allows the component to impersonate the client identity to access network resources.

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.