As you saw in Chapter 7, security is an essential part of any distributed application, and COM+ provides you with a rich, user-friendly security infrastructure. When a client makes a queued call, the queued component may still require the same level of security services and protection as if it were invoked synchronously, and rely on COM+ to provide authentication and authorization.
However, the underlying method call invocation is different, and the synchronous security mechanism simply will not do—by the time the actual object is invoked, the client may be long gone (with its security identity and credentials). The synchronous authentication that uses the challenge-response mechanism cannot be used.
The idea behind queued component security is simple—have the recorder capture the security identity (and other security-related information) of the client as it records the method calls. The security information is bundled in the message along with the method calls and sent to the queued component application queue. Before the player makes the call on the component itself, COM+ uses the captured security information to validate that the client is allowed to access the component.
The underlying implementation of this idea relies heavily on MSMQ security services to capture the client security details in the message and transfer it securely to the application queue. To ensure authenticity of the message, the messages can carry a digital signature from the client. MSMQ can even encrypt the message for transfer. If, on the receiving side, MSMQ encounters a message with insufficient security credentials or a message that was tampered with, then MSMQ puts it in the application’s dead queue.
The default call
authentication level actually depends on
the queued component application settings.
If the application uses role-based security, then during the call to
CoGetObject( ), COM+ captures the information
required to authenticate the call during playback in the message. The
queued component client can explicitly specify the desired
authentication level for the queued call and the required privacy
level by providing the queued moniker with additional parameters.
If the client requires authentication, MSMQ digitally signs the message with the user’s security certificate. If this is the case, your application administrator has to issue an MSMQ security certificate for each potential user by using the MSMQ administration applet in the Control Panel.
In Example 8-3, the Store object explicitly turns on authentication and instructs MSMQ to encrypt the message body.
Example 8-3. Explicitly setting authentication and encryption levels for a queued call
IShipment* pShipment = NULL;
HRESULT hres = S_OK;
DWORD dwOrderNumber = 123;
hres = ::CoGetObject(L"queue:AuthLevel= MQMSG_AUTH_LEVEL_ALWAYS,
PrivLevel= MQMSG_PRIV_LEVEL_BODY
/new: MyApp.Shipment", NULL,
IID_IShipment,(void**)&pShipment);
hres = pShipment->ShipOrder(dwOrderNumber);
pShipment->Release( );Exceptionally paranoid clients can also specify the encryption algorithm to use and a cryptographic hash function (see the MSDN Library for details on these advanced parameters for the queue moniker).
Insisting on high security carries with it the usual performance/security tradeoff. Decide on your security setting wisely. For example, you may want to authenticate only the actual order shipment call, but not less sensitive method calls.
Despite
the fact that under-the-hood COM+ uses a
drastically different mechanism for queued components security, the
queued component can, once instantiated, take advantage of role-based
security with the same ease as if it were invoked synchronously. You
can configure your component administratively to use role-based
security on the component, interface, and method levels, and even use
programmatic role-based security calls such as
IObjectContext::IsCallerInRole( )
.
The only requirement for using role-based security is that the call be authenticated. If the client explicitly turns authentication off while role-based security is in use, the call will fail during playback, since COM+ has no way of authenticating what role the client belongs to.
A queued component developer has access to similar security features and services as a nonqueued component, and from a security standpoint, your code will be the same as if you were developing a normal synchronous component. However, some differences do exist, especially if you plan to use the more advanced or esoteric security services. You should be aware of the following limitations:
The queued component developer is discouraged from performing low-level security manipulation, such as interacting directly with the Kerberos authentication service, because the Kerberos cookies are not part of the MSMQ message. Generally, if you want to do low-level security calls, you are restricted to whatever MSMQ supports.
Queued components do not support impersonating the client. This is done (by design) to close a potential security hole in which an untrustworthy source has generated a message whose format resembles that of a message to a queued component and placed it in the application queue. COM+ requires the original client’s security identity to compare with the message sender identity to verify that the message came from the client. By doing so, however, COM+ inhibits impersonation.
If you install MSMQ using the Workgroup configuration, MSMQ cannot authenticate queued calls. As a result, you should turn off security access checks at the application and component levels.