COM Support in Distributed Environments

As previously examined in the COM programming model, COM components can run on remote computers with little or no extra effort from the programming model perspective. COM's location transparency extends across apartments, processes, and computers. Some practical matters must be considered when communicating across computer boundaries. In this section, we'll discuss Distributed COM (DCOM), and also how location transparency operates.

Technically, DCOM refers specifically to the wire protocol for making COM calls between two computers. However, the term DCOM is often used to refer to the entire concept of COM communication across computers. Our discussion in this section focuses on what should be understood, on a general level, about how distributed applications based on COM operate.

Cross-computer COM calls introduce several issues that wouldn't normally be considered in a single-computer scenario. First, for security reasons, it may not be desirable to allow universal access for components installed on a particular computer. Second, users allowed to access such components—or on a larger scale, to access their own computers in which the components would reside—need to be educated as to the proper care of those components.

COM Security

The COM security model defines a standard means for COM objects to interact with operating system-provided security services. The COM security model is independent of the specific security services that may be available.

COM security primarily addresses two issues: who is allowed to launch components, and how calls are secured through interface pointers by providing activation security and call security.

Activation Security

The server computer's Service Control Manager (SCM) applies activation security whenever it receives a request to activate an object. Activating an object means either creating a new object or getting an interface pointer to a published object, such as a registered class object or an object in the running object table. We won't cover published objects in this book; instead, we'll focus on activation security as it applies to creating new objects.

The SCM uses information in the registry (or information obtained dynamically from published objects) to determine whether an activation request should be allowed. First, the SCM checks a computer-wide setting to determine whether any remote activation requests are permitted. If the computer-wide check succeeds, the SCM looks for component-specific security settings. We'll discuss these settings in more detail in the "Registration Revisited" section later in this section.

In essence, the registry can contain an access control list (ACL) that indicates which users can activate specific components. The SCM checks the client's identity against the ACL to decide whether the activation request can proceed. If there is no component-specific setting, the SCM looks at a default ACL.

If the access check succeeds, the SCM will launch the component, if necessary, and activate the object, otherwise access is denied. The SCM uses information in the registry to determine the security context, user identity, which the object should use to run. This identity becomes the client identity for any activation requests the object may make.

Call Security

Once an interface pointer to an object is obtained, a client can make calls to the object. COM also applies security to each method call through an interface pointer. Per-call security has two separate aspects. The first aspect is caller authentication and authorization, which is virtually identical to the activation security check described in the previous section, except that a different ACL is used and the component and client have moderate control over how often the check is performed. The other aspect relates to data integrity and privacy—that is, ensuring that network packets containing COM method calls have not been violated, and also preventing data in the packets from being read during transmission.

As is imaginable, performing security checks on every method call can have considerable overhead costs and involve unnecessary and redundant work. Thus, COM lets applications configure when and how to apply per-call security. Both client and server applications can establish process-wide defaults for per-call security by calling the CoInitializeSecurity function. Settings involved in calling this function include an ACL for authorization checks and an authentication level that determines how often authentication is performed, as well as whether data integrity and/or privacy should be enforced. If an application does not explicitly call CoInitializeSecurity, the COM run time will call this function, using information from the registry and on the application's behalf, before any objects are activated. As with activation security settings, COM will first look for component-specific settings; if COM does not find any component-specific settings, the default settings for COM components are applied.

In addition to setting per-call security at a process level, applications and components can tune security settings on individual interfaces and method calls using the standard IClientSecurity and IServerSecurity interfaces. Using these interfaces represents a more advanced technique than those found in this book. For additional information see the two titles by Guy and Henry Eddon, Inside Distributed COM (Microsoft Press, 1998) and Inside COM+ (Microsoft Press, September 1999). For many applications, process-wide settings are sufficient. As we later discuss, MTS offers a role-based security abstraction on top of the COM security model that further simplifies securing access to components.

Registration Revisited

COM security relies on a number of registry entries. On Windows and Windows NT, these settings are usually configured using the DCOM configuration tool, DCOMCNFG.EXE, shown in Figure 8.2. DCOMCNFG lets developers set computer-wide and per-application settings involving actual registry keys.

click to view at full size

Figure 8.2 DCOM configuration tool used to configure DCOM security

Several key DCOM settings can be configured at the computer level. These settings are stored as values under the registry key HKEY_LOCAL_MACHINE \Software\Microsoft\Ole. Table 8.2 lists the major values, their purpose, and how to set them using DCOMCNFG. The values specified using DCOMCNFG will be used by default if no application-specific values are provided.

Table 8.2 Computer-wide DCOMCNFG registry entries

Registry value Purpose Configuration
EnableDCOM Global activation policy for computers On the Default Properties tab, select the Enable Distributed COM On This Computer check box.
LegacyAuthenticationLevel Default authentication level applied to network packets On the Default Properties tab, select a setting from the Default Authentication Level combo box.
DefaultLaunchPermission Default ACL for activation security On the Default Security tab, click Edit Default in the Default Launch Permissions area to edit which users have launch permission.
DefaultAccessPermission Default ACL for per-call security On the Default Security tab, click Edit Default in the Default Access Permissions area to edit which users have access permission.

DCOMCNFG also allows settings for specific applications to be specified. In COM, an application is nothing more than an identified process that hosts one or more components. Applications are identified by GUIDs, called AppIDs.

With the AppID key in place, DCOMCNFG can be used to establish security settings on a per-application basis. These settings will be used if the application does not call CoInitializeSecurity explicitly. The per-application settings are stored as named values under the HKEY_CLASSES_ROOT\APPID\{appid-guid} registry key for the application on the server computer. Table 8.3 lists the security values, their purposes, and how to set them using DCOMCNFG's Application Properties window. To open the Application Properties window, select an application to configure in the Applications list box on the Applications tab, and then click the Properties button.

Table 8.3 Per-application DCOM security configuration registry entries

Registry value Purpose Configuration
RunAs Identity used to run the server process On the Identity tab, select the user account to use to run the application.
LaunchPermission ACL for activation security On the Security tab, select the Use Default Launch Permissions check box, or select the Use Custom Launch Permissions check box and click Edit to select specific user accounts to give launch permission to.
AccessPermission ACL for per-call security On the Security tab, select the Use Default Access Permissions check box, or select the Use Custom Access Permissions check box and click Edit to select user accounts that will have access permission.
AuthenticationLevel Authentication level applied to network packets. (Windows NT Service Pack 4 or greater) On the General tab, select a value from the Authentication Level drop-down list box to set the per-application authentication level.

It's important to register an AppID for DLL components that will be used remotely because DCOMCNFG can not be used to modify component settings unless the components have an AppID.

In addition to security settings, the registry also contains information about the component's location. On the server computer, this information is usually written to the registry by the component when it is installed. All that's needed on the server computer is the path to the COM component, stored under the InprocServer32 or LocalServer32 key for each CLSID. If the component runs as a service, some additional entries are needed.

It is also necessary to put information in the registry of remote client computers for those computers to be able to request remote objects, unless client applications are written to specify the server computer name when CoCreateInstanceEx is called. In particular, the client computer needs an AppID with a RemoteServerName value. The client may also need registry entries for proxy/stub DLLs used to marshal interfaces exposed by the objects. The remote component itself can't write the registry information because it isn't installed on the client computer.

There are two common ways to create the client-side registry entries on Windows computers. If no proxy/stub DLLs are required by the component, a .reg file containing the registry settings can be distributed to client computers and merged into the local registry. Otherwise, an installation program can be distributed that would write appropriate registry entries and install any proxy/stub DLLs required for the components to work correctly. In some cases, the installation program or .reg file will create the AppID key, but it won't specify where the component is located. If this is the case, DCOMCNFG can be used on the client to set the AppID's RemoteServerName value.

Remote Activation and Marshaling

With the security and component location information in place, objects can be created remotely. Let's look at how this process works.

As previously mentioned, creating objects is simple: an IClassFactory pointer is first directed to a class object, then IClassFactory CreateInstance is called to direct an interface pointer to an object that has been created. The SCM is responsible for locating the class object.

In creating remote objects, two SCMs locate class objects: the client computer SCM detects that a remote object has been requested and contacts the server computer SCM. The server computer SCM locates the class object as it normally would, then returns the interface pointer to the client computer SCM (assuming that all security checks pass).

The client computer SCM detects that a remote object has been requested in one of two methods. In one method, an application can specify a remote server computer name in the call to create an object. In a second method, when the SCM looks in the registry for component location information, the SCM might be pointed to a remote computer (typically, by using the RemoteServerName value on the AppID). Using either method, the client SCM ends up with a computer name, which in turn communicates with the SCM on that computer to retrieve the interface pointer. Once the interface pointer to the object is passed back to the client application, the application makes regular method calls through the interface pointer. The client's application is simply responsible for calling an in-process object—this is the beauty of location transparency.

Multitudes of mechanisms can be designed to create the illusion of an in-process call and can be located within the application's code. The actual interface pointer from the remote computer can't be handed to the client application; the memory address in that pointer has no meaning on the client computer. Instead, the client application is handed an interface pointer to a proxy object, which is in effect an in-process object. This object must do whatever is necessary to communicate with a corresponding stub object in the component's process.

A client application making a method call actually calls a method in the proxy. In what is known as marshaling, this proxy takes parameters passed to the method and packages them in a standard format.

Next, the proxy sends a request via an appropriate communication mechanism to the component process. The component process hands the request to the stub, which unpackages the parameters and calls the method on the real object. This process is called unmarshaling. After the method completes, any return values are passed back using the same process in reverse.

One of COM's goals is to hide the complexity of cross-computer and cross-process communication; proxy and stub objects perform exactly this process. Marshaling occurs not just across computers, but also across processes and apartments. Typically, implementations of proxies and stubs are generated automatically from IDL interface definitions using the MIDL compiler. These DLLs call system functions that encapsulate all details of marshaling and unmarshal-ing calls, as well as actual call request details. If a cross-computer call is requested, COM uses a remote procedure call (RPC) to make the call. If a cross-process call is requested, a lighter-weight inter-process communication mechanism called Lightweight RPC (LRPC) is used. If a cross-apartment call is requested, COM switches apartment contexts and synchronizes access appropriately—all automatically.

Normally, developers need only ensure that proxy/stub DLLs are installed and registered on appropriate computers. For a given interface, the proxy/stub DLL must be registered on all computers that use that particular interface. The proxy/stub DLLs generated by MIDL can be built to be self-registering, so developers only need to run REGSVR32 on the DLL to define the correct registry entries.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182 © 2008-2017.
If you may any questions please contact us: