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 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.
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 1.
|
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 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.
Although the programmer can define COM+ RBS roles, only the system
administrator is able to assign those roles to Windows user accounts.
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.
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.
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 3 illustrates impersonation.
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.
