On Security in Workflow

It's been ages sinces I've blogged on workflow.  I've been wildly busy implementing a workflow engine in C# that will ride under any .Net app while providing a truly light and easy to understand modeling language for the business user.

One business modeler is now able to go from inception to full document workflow implementation in about 20 hours, including creating the forms, e-mails, model, staging, debugging, and deployment.  The only tools that need to be installed on the modeler's PC are Infopath (for forms, e-mail, and model development) and our custom workflow management tool that allows management, packaging of a workflow and remote installation to the server.

One problem that we've been solving has to do with security.  Just how do you secure a workflow.

For those of you who live on Mars, Microsoft is very heavily focussed on driving security into every application, even ones developed internally.  Plus, workflow apps need security too.

Thankfully, the first "big" refactoring we've done to the design of the workflow engine was in the area of security.  I'd hate to have added workflow security later, after we had a long list of models in production.  As it stands, we only have a handful of models to update.

So what does security in a workflow look like?  Like security in most apps, (common sense) plus some interesting twists. Here are some of the most salient security rules.

a) We have to control who can submit a new item to the workflow. In our models, all new items are added to a specific stage, so you cannot start "just anywhere" but we also have to be cognizant that not all workflows may be accessed by all people.  There are two parts to this: who can open the initial (empty) form and how do we secure submission to the workflow?  We solved both with web services that use information cached from the active directory (so that membership in an AD security group can drive permission to use a form).

b) Once an item is in a workflow, we need to allow the person assigned to it to work on it.   There are two possibilities here.  Possibility 1 states: There is no reason to set permission on each stage, because the system only works if the person who is assigned to the item can work on it. Possibility 2 states: a bug in the model shouldn't defeat security.  We went with the second one.  This means that the model can assign a work item to a person only if that person will have permission to work on the item (in the current stage for entry actions or in the next stage for exit link actions).

c) Each stage needs seperate permission settings.  A person can have read-only permission in one stage, read-write in a second, and no permission at all in the third. 

d) It is rational to reuse the same groups for permission as we do for assignment, since they are likely to coincide.  Therefore, if we assign an item to a group of people (where any one of them can "take the assignment", then it makes sense that the same group of people will have permission to modify the work item in that stage.  Two purposes, one group.

If you have opinions about the proper rules for managing access to workflow stages and the document they contain, post a response to this message.  I'd love to hear about it.

Comments

• Anonymous
  March 12, 2005
  The comment has been removed
• Anonymous
  March 16, 2005
  Hi Lamont,
  
  I honestly haven't run into that issue yet. It's a good point.
  
  So far, we've been viewing the engine has having "special rights" from the standpoint of accessing resources on behalf of a user during the process of running. So far, the rights have been fairly minimal.
  
  Since our system uses plug-ins in order to allow other apps to hook in, we had been assuming that we would tackle this when we hit it, by implementing impersonation in a plug-in. That or we would call a web service that effectively does the same thing.
  
  The problem is that the person who initiates the link into the "resource request" is no more likely, in general, to have permission to access the restricted resource than the original submitter of the work item is.
  
  If I was going to tackle this issue, I'd start with the Microsoft Identity Management Server product, that provides "single-sign on" capabilities to allow access to back-end systems.