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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

2 thoughts on “On Security in Workflow”
  1. When you look at defining the rules for managing security, you might want to think about security at basically two levels. The first would involve security around the actual execution of a given stage in the workflow (e.g. what operations are being performed during the stage that requires elevated security permissions in order to complete) while the second would involve sort of a role-based security model for the client that initiated to transition to the stage. It’s kind of hard thinking about these being separate, however, it is conceivable that the engine will have to perform some impersonation in order to, for example, gain access to some resource necessary to complete the current stage and transition to the next but yet at the same time only execute based on who initiated the action.

    Actually, the more I think about it, there could be many instances where in a given stage, a user would have to belong to multiple roles and the underlying engine would need multiple sets of security permissions. Are you planning on introducing some form of security manager to manage this security/role delegation?

  2. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

3 + 9 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.