| Platform SDK: Exchange 2000 Server |
[This is preliminary documentation and subject to change.]
Obviously, when your action table includes scripts and COM objects that will run on your server, security becomes a big issue. How do you prevent these from wreaking havoc on your server while allowing users the flexibility to design their own workflows? CDO Workflow solves this problem by implementing workflow security modes.
The following table summarizes the two modes of security that CDO Workflow implements.
| Factors to consider | Restricted | Privileged |
|---|---|---|
| Script Access | Only the current Web Store item (ProcessInstance) is accessable. | Scripts and objects can access enterprise databases as security context allows. |
| Security Context | EUSER_EXSTOREEVENT (guest privileges) | Workflow System Account defined by system administrator |
| CoCreateable COM objects | None | Unlimited registered components
Allows you to integrate with other systems such as SQL databases and other business applications that provide COM components. Can use LDAP and Active Directory. |
You use the restricted mode for un-trusted workflows. A user needs to set up his own one-off workflow design that will set up a simple document. Users should be free to do this, but you don't want them to be able to run just any script or COM object.
The security mode is a property of the process definition and you set it at design time. You have the option of either setting this property as restricted or privileged. You must also be a member of PrivilegedWorkflowAuthors group for your workflow to run in privileged mode. This is checked at run-time. PrivilegedWorkflowAuthors is a built-in group, and a system administrator has to add you to the group. The following illustration shows the Microsoft Management Console, Component Services view of the Workflow Event Sink COM+ package with the PrivilegedWorkflowAuthors role and its members.
This section includes the following subtopics.