A security identity is a valid account used to identify a user. The account can be local or an account on a domain server. Every COM+ entity, be it a client or an object, must have an identity associated with it so that COM+ can determine what that entity is capable of accessing. In Windows, all objects in the same process share the same identity, unless they make an explicit attempt to assume a different identity. You can configure a COM+ server application to always run under a particular identity or to run under the identity of the user who is currently logged on that Windows station. Objects from a COM+ library application run under the identity of the hosting process by default.

Authentication has two facets. The first is the process by which COM+ verifies that the callers are who they claim to be. The second is the process by which COM+ ensures the integrity of the data sent by the callers. COM+ authentication relies on the underlying security provider—in most cases Windows 2000 built-in security.

In the Windows default security provider, the challenge/response protocol is used to authenticate the caller’s identity. Given that all callers must have a security identity, if the callers are who they say they are, then they must know the account password. That password is also known to the domain server. The security provider does not want to ask the callers directly for their passwords because a malicious third party can sniff the network to discover the password. Instead, to authenticate the callers, the security provider encodes a random block of data with the account password and sends it to the callers, asking them to decode the encrypted block using the password and send the result back. This process is the challenge. If the returned block, the response, is the same as the original unencrypted block, then the callers are authenticated.

Authenticating caller identity is only one problem. The other problem is that data passed in a method call can be intercepted, copied, altered, or corrupted by a malicious third party. Under COM+, both the caller and the object have a range of choices to determine how secure the connection between them should be.

To authenticate data integrity, COM+ can use one of two techniques: it can append a checksum to every network packet, making sure that the data is not tampered with during transport, or it can encrypt all information in the packet.

Both kinds of authentication (identity and data integrity) are, in most cases, completely transparent to both the caller and the object and done automatically by COM+. However, there is a clear tradeoff between security and performance (when and to what extent to authenticate), and it is up to you to choose and configure the proper authentication level for your application.

Authorization is the process of determining what the caller is allowed to access in the system. Authorization is also called access control. COM+ uses role-based security (discussed in the following section) to let you define access control at the component, interface, and method levels. Access control is used to protect objects and resources against unauthorized access by clients. If a user who is not granted access to a component tries to invoke a method on that component, the method invocation fails with the error code E_ACCESSDENIED (“Permission Denied” in Visual Basic). You configure access control administratively using the Component Services Explorer. Programmatically, you can still fine-tune access and execution of a method based on the caller’s identity and other information such as the method parameters and object state.

Note that authorization is not related to authentication. Authorization assumes that the caller is already authenticated and is only concerned with whether the caller can access this object. It is not concerned with whether the caller is really who he or she claims to be.

Launch security controls which users are allowed to create a new object in a new process. Unlike DCOM, COM+ does not provide a dedicated way to control launch security. This is done intentionally to avoid a common DCOM security pitfall—allowing a user to launch a process, but forgetting to grant the user access to the objects inside! As a result, the user could call CoCreateInstance( ) to launch the process, but would be denied access to methods, including being unable to call Release( ) on the object. The process is ultimately orphaned, and the user has to shut it down manually or rely on COM garbage collection to eventually shut the process down. In COM+, even if the client is not granted access to the object, (but is a member of at least one role defined for the application), the client can still launch a new process with a new object inside and can call the IUnknown methods on the object, including Release( ). The client cannot access methods on any other interface, however.

Authorization and authentication protect the object from being accessed by unauthorized and unauthenticated users. This protection ensures that when an object is asked to perform an operation, the invoking client has permission to access the system and the call was not initiated by an adversary client. However, how should the client be protected from malicious objects? What prevents the server from assuming the client’s identity and credentials and causing harm? Is the server even allowed to learn the identity of the calling client? By setting the impersonation level, COM+ lets callers indicate what they allow objects to do with their security identity. The impersonation level indicates the degree to which the server can impersonate the calling client. Setting the impersonation level can be done administratively and programmatically on the client side; attempting to impersonate the client can only be done programmatically by the server.