Page #86 (The COM Security Model)

< BACK  NEXT >

[oR]

Declarative Security

As with many other aspects of COM+, an administrator can configure COM+ security setting by manipulating the COM+ catalog. Though COM+ security settings can also be handled programmatically, manipulating the catalog gives the administrator more flexibility in terms of customizing the security environment.

The COM+ catalog can be manipulated either programmatically or by using the Component Services Snap-in. We will use the latter approach for our current discussion. Manipulating the COM+ catalog programmatically is covered in Chapter 12.

Declarative security can be further divided into default settings and application-specific settings.

Default Settings

Default settings are used for those components that do not provide their own settings. These settings are local to a computer and can be changed using the properties dialog box of a computer. The properties dialog box is shown in Figure 7.4.

Figure 7.4. Default COM+ settings.

As shown in Figure 7.4, the default settings include default protocols, default security, and default properties.

The default protocols property page lists the set of network protocols (such as TCP/IP, NETBEUI, etc.) available for distributed computing on the machine. The ordering of the protocols reflects the priority in which a client application ^[3] will use them. When the client application initiates connection to the server application, it uses the first protocol on the list for the connection. If the server machine does not support the same protocol, the connection will time out. The client uses the next protocol on the list until it eventually succeeds.

^[3] The term client application is used loosely here. It is the underlying RPC infrastructure that needs to use the network protocol.

By default, Windows 2000 uses TCP/IP as the top protocol and Windows NT 4.0 uses NETBEUI (UDP) as the top protocol.

Consider the scenario where a client application on an NT 4.0 machine communicates with a server application on a Windows 2000 machine. Assume that the client machine supports UDP and TCP (in that order) whereas the server machine supports only TCP. The client application tries to connect to the server using UDP, unaware that the server does not support it. The application waits until the connection eventually times out (after 30 to 60 seconds) before it tries the second protocol on the list. Changing the order of protocols on the client machine so that the first protocol on the list is the one that the server supports could dramatically improve the initial connection time.

Classic COM applications can be individually configured to use a specific protocol sequence using DCOMCNFG.EXE, a system-supplied program. There is no such configuration option for COM+ applications.

The default security property page can be used to configure the default launch and access permissions for a classic COM application. The administrator can explicitly allow or deny permissions to selected users or groups. When the OS is installed, the default launch permissions are for administrators, the system account, and the interactive user account. The default access permission list is empty indicating that everyone is denied access to a classic COM application. A classic COM application can override the default security settings by using DCOMCNFG.EXE.

Note that the default access and launch permissions do not affect COM+ applications.

The Default Properties property page lets the administrator set the default authentication and impersonation options on a machine-wide basis. These properties are valid for both classic COM as well as COM+ applications as long as the values are not overridden programmatically during run time.

The Enable Distributed COM on this computer is the main switch for DCOM. If this box is not checked, all remote calls to and from the machine are rejected. This option is enabled by default.

The Enable COM Internet Service on this computer option determines whether COM+ Internet Services (CIS, also known as DCOM over HTTP) is available on the machine. This option is disabled by default. Enabling this option allows DCOM to operate over the Internet in the presence of most proxy servers and firewalls. Covering CIS is beyond the scope of this book, but more information about CIS can be found in MSDN article COM Internet Services [Lev-99].

The Default Authentication Level setting specifies the authentication level used on the system. The possible authentication levels are shown in Table 7.1.

The Default Impersonation Level setting specifies the base impersonation level that clients running on the system will grant to the servers.

The Provide additional security for reference tracking option helps keep track of the distributed reference count on the computer. The SDK defines this option as EOAC_SECURE_REFS authentication capability. This option is disabled by default. When enabled, an object and its stub exist as long as there is at least one client that has a reference to this object, even though some other client may call one too many Releases on the object. Though this option protects the server from a malicious client, it comes at the expense of decreased performance.

Application-Specific Settings

The focus of this section is for COM+ application settings. Classic COM applications specify their security needs through a system provided utility, DCOMCNFG.EXE. For more information on DCOMCNFG settings, see Professional DCOM Programming by Richard Grimes [Gri-97].

Identity

A server application can be configured to run under the identity of a specific user account. Figure 7.5 shows the identity setting for the application.

Figure 7.5. Identity settings for a server application.

The application can be made to run under the interactive user account or a specific user account. Windows uses the credentials of the selected user when accessing a securable object, that is, if the calling thread is not under impersonation.

Roles

An administrator can define one or more roles to be used with the application and assign users and groups to each role. Note that the application may be shipped with some pre-defined roles. However, it is still the administrator s responsibility to assign accounts to each role.

Security Settings

Figure 7.6 shows the security setting property page for the application.

Figure 7.6. Security settings for a COM+ application.

Assigning accounts to a role does not automatically enable access checking. The administrator also needs to enable the Enforce access checks for this application option.

Access checks can be performed at the process level or at the component level. When the second option is selected, the administrator can associate specific roles at the components level, the interfaces level, and the interface methods level. At these finer levels, not only can COM+ do explicit role checking, it can also make an interface IServerCallContext available within the context of a method call. We will see how to use this interface later in the chapter.

The administrator can also specify the authentication level and the impersonation level to be used for the client-server communication. The impersonation level setting is used only when the application s object acts as a client to some other object.

Though many security settings can be configured declaratively, there are certain features of a COM/COM+ security model that can be accessed only via COM interfaces. For example, a server can only impersonate a client programmatically. Also, there are cases when a client has to specify a security setting during run time. For example, when passing sensitive information such as a credit card number, the client may wish to temporarily boost the authentication level to packet-level encryption.

Let s look at how we can deal with security programmatically.

< BACK  NEXT >