Like other configured components, an event class can use role-based security. The most common use of use role-based security for event classes is to control which publisher is allowed to fire events.

However, since roles in COM+ are per application, be sure to add roles and users for each product to the event class application if you intend to share event classes between a few applications and products.

You can use role-based security in another way: to implement a publisher-side filter that calls ISecurityCallContext::IsCallerInRole( ) (discussed in Chapter 7) and controls the order of publishing based on the publisher’s role.

The subscriber can use role-based security to control access to its services. Unlike an event class usage of role-based security (which affects the publishing side and therefore all the subscribers), when a subscriber uses role-based security, only that subscriber is affected by the access checks. If all your subscribers have uniform security requirements, putting the security check on the event class is the right decision because it improves performance (the publisher does not publish at all if it is not allowed to). However, if the security requirements of your subscribers vary (if some require tighter security than others), putting the security access checks on the sensitive subscribers may provide you with the better solution.

From a security point of view, an interesting situation arises when the event class and the subscriber component are both library applications. As a result, when the publisher CoCreates the event class and publishes to it, the subscriber is loaded into the publisher process.

Unlike a conventional library application that is intended to share the address space of its client (and may very well be developed by the same team), the publisher/subscriber relationship is much less trusting and coupled.

Most software vendors would feel uneasy letting an unknown entity into their process. The subscriber may be of dubious quality (and may take the publisher down with it when it crashes) or even malicious (I will leave it to your imagination what you can do if somebody lets you into their process).

To protect the publisher, the system administrator can enforce all subscribers to be created in their own process. On the Advanced tab of the Event Class properties page, if “Allow in-process subscribers” is not checked, the subscriber object will be created in a separate process, even if it is configured to run as a library application (see Figure 9-4).

COM+ allows you to deliver an event to a particular subscriber only if a specific user is logged on to the publisher’s machine. When the user logs off, the subscription is disabled. Per-user subscription requires the publisher and subscriber to be on the same computer, since logon and logoff are only detected locally in Windows.

To activate per-user Subscription you must set the PerUser flag on the subscription record to TRUE and specify a username. You can do that by programming against the COM+ Catalog.

Per-user subscription is an esoteric security mechanism, and I recommend using role-based security instead to achieve similar capabilities with a fraction of the code and restrictions.