COM Authentication

[Previous] [Next]

In this section, we describe in greater detail the relationship of COM+ 1.0 authentication to Windows 2000 authentication and the mechanisms that COM+ 1.0 offers to control authentication.

Client-Application Trust

COM+ 1.0 leverages Windows 2000 authentication mechanisms through integration with Microsoft RPC and the various Windows 2000 SSPs. Note, however, that different SSPs offer somewhat different levels of functionality. For example, Kerberos supports mutual authentication, but NTLM authenticates the client only, not the server. This makes the SSPs' support at the COM+ 1.0 level (through DCOM) not completely transparent. Therefore, although more extensive coverage might be provided in the near future, COM+ 1.0 in Windows 2000 supports only the Kerberos, NTLM, and Negotiate protocols.

This means that for a client and the COM+ 1.0 application to engage in an authenticated communication a trust path must exist between the client and the application domains. In the trivial case, both client and application are members of the same domain. In more elaborate scenarios, interdomain trust must exist between the client and application domains.

However, in many common cases, including the Web scenario that is the primary example in this book, the client identity is not a domain identity or, at least, cannot be directly authenticated as such. In that situation, the relationship between client and application is typically mediated by a Web server—that is, the client is a Web browser interacting over HTTP with logic hosted by the Web server, which in turn dispatches work to COM+ components. It's therefore possible to defer the job of authenticating and establishing a domain identity for the client to the Web server. Once this is accomplished, the Web server can impersonate the client in its interaction with the COM+ 1.0 application.

The COM Internet Services (CIS) and Simple Object Access Protocol (SOAP) (once it becomes available) can also be used to support those scenarios in which the Internet client needs to perform a direct method call against a COM+ application. See the discussions of CIS and SOAP later in this chapter in "Using DCOM over the Internet."

Configuring Authentication

Authentication configuration is provided to control the level of protection, including whether to authenticate, applied to method calls. Both client and application can set requirements for this control. At the outset of a conversation, the client and application engage in what can be thought of as a negotiation to determine the authentication/protection that will be applied to their interaction. The setting applied to method calls between client and application is the more stringent of the two. Figure 7-5 shows the authentication process between the client and the COM+ application.

Figure 7-5. Negotiating authentication and protection in COM+.

For the client, the authentication configuration is machinewide. This is set by using the Default Authentication Level list box on the Default Properties tab of the My Computer object (the compmgmt.msc Microsoft Management Console [MMC] snap-in in Windows 2000), as shown in Figure 7-6. Note that this setting can be overridden programmatically by the client code.

Figure 7-6. Setting the default DCOM authentication properties.

In addition to setting the default authentication level for clients, the default configuration also includes the following settings:

• Enable Distributed COM On This Computer This setting controls whether crossmachine calls using DCOM are allowed from or to the computer. The default setting is selected, or enabled.
• Enable COM Internet Services On This Computer This setting controls whether calls using CIS—see "COM Internet Services" later in this chapter—are allowed to the computer. The default setting is cleared, or disabled.

Each COM+ 1.0 application can independently configure its authentication controls. For the application, this setting applies both to the application when it acts as a server (that is, when it receives client calls) and when it acts as a client (when it originates calls to other applications). In the latter case, the authentication and protection level can also be overridden programmatically. Authentication is set with the Authentication Level For Calls list box on the Security tab of the application's Properties dialog box, as shown in Figure 7-7.

Figure 7-7. Setting authentication requirements for a COM+ application.

In addition to letting you set the authentication requirements for the COM+ application, the Security tab also exposes two coarse controls over authorization:

• Enforce Access Checks For This Application This is the top-level switch that allows you to control whether the COM+ security service will perform authorization checks for the application. The default setting is cleared, or unenforced. Note that even if the authorization checking is disabled, the client can still be required to pass the muster of authentication as determined by the authentication level.
• Security Level This property determines whether the application uses fine-grained role-based authorization or only coarse application-level access control. The default setting is to perform access checks at the process and component levels.

Authentication and protection levels

COM+ 1.0 supports the authentication and protection levels in Table 7-1. Note that these protection levels are cumulative—that is, each level offers its protection in addition to that offered by lower levels.

Table 7-1. COM+ authentication and protection levels.

Setting	Comments
None	No authentication is required.
Connect	Authenticates only on the initial connection between the client and the application.
Call	This level is always promoted to Packet protection.
Packet	Verifies that the data received in the course of a call originated with the correct client.
Packet Integrity	Verifies that the method call data was not modified in transit.
Packet Privacy	Encrypts the call data to protect against on-the-wire disclosure.

A note on library applications

A COM+ 1.0 library application is hosted by another process, and therefore its authentication and authorization settings are, by default, controlled by the hosting process. The hosting process security settings are configured either as a client or as an application, as described earlier.

In some situations requiring callbacks (for example, for notification), this setup can cause difficulties, especially when the hosting process is a client process that is subject to the broad machinewide security settings. In such a situation, callbacks often will fail to pass the muster of the security check and will therefore fail altogether. To handle this scenario, COM+ 1.0 provides a way for library applications to disable any automatic security check for their components. This is done by clearing the Enable Authentication check box on the Security tab of the library application. (Note that this check box appears for library applications only.) Obviously, this facility should be used with care.

Application Identity

A COM+ 1.0 application can be hosted either in its own process—such an application is known as a server application—or as a dynamic-link library (DLL) hosted in a caller process, in which case it's called a library application.

For a server application, it's necessary to configure a principal under whose identity the application will operate. This identity is the one that the client authenticates when using an authentication service, such as Kerberos, that supports mutual authentication. It's also the default identity used when the application acts as a client in the course of its work. We'll see later how an application can use impersonation to temporarily assume the identity of one of its clients while doing work on its behalf.

The application identity can be configured to be that of the currently logged user—also known as the interactive user—or a designated user, as shown in Figure 7-8.

Figure 7-8. Setting a COM+ server application identity.

The interactive user setting is not suitable for a production situation since the application would require a user to be logged on in order to run. Furthermore, an application configured that way exposes the interactive user identity to misuse. This setting is therefore useful only in limited situations, such as in the course of developing a COM+ application.

Finally, note that COM+ 1.0 does not yet support running an application as a service or under the local system account. (The exception to this rule is the COM+ 1.0 System Application, which runs under the local system account.) There is, in fact, something to be said for this limitation because it prevents running application code with system-level privileges.