Declarative Workflows and User Context

My name is Darren and I’m one of the workflow testers for SharePoint Designer. One of the ways that SharePoint Designer workflows operate that seems to be a point of confusion that I keep hearing about is that certain actions don’t always work when someone expects them too. There are a number of reasons that this can happen, but the main one I would like to blog about is user context the workflow runs under.

The basic thing to remember is that declarative workflows (the one’s created by SharePoint Designer) always run impersonating the user who started the workflow. So if I’m a contributor and I make an edit to a list item and that triggers a workflow then that workflow runs as me and has the ability to do everything that I do. Where this can get challenging is in cases where the workflow tries to do something I couldn’t do on my own, like make a change to a list I don’t have permissions to, since it also has the same limitations I do. The reason we do this is to protect against things like elevating someone’s privileges to something they might take advantage of or get information they shouldn’t be able to see.

Now this seems simple at first, but it is limiting what can be done by a declarative workflow in some more complicated scenarios like triggering a workflow base on an anonymous submission to a list. The main way the people have worked around this (either intentionally or unintentionally) is get a workflow triggered by the SharePoint System account (the account used to run the SharePoint web application) which has full access to everything. This is accomplished by using email enabled lists, running a custom form (i.e. InfoPath) that submits data to a list, or some other custom code (or even custom workflow actions that elevate themselves for certain tasks). This was fine until we discovered a security problem in declarative workflows that we had to fix in SP1. One effect of this change is that the SharePoint System account is no longer allowed to trigger declarative workflows.

This change effectively broke some people’s workflows and we knew it would, but that was better than allowing the security problem to remain. Some of these scenarios can be fixed by changing the custom code or updating the submission form. But one that can’t is lists that have email enabled on them add the items to the list as the admin account. With SP1 those can’t start workflows and administrators have no way of changing the account items get added as. So as part of the SharePoint Infrastructure Public Update we allow for that scenario base on a stsadm.exe command that sets a property to allow emailed items to trigger workflows as the person who last saved the workflow to the site. This will also be rolled up into SP2.

To sum up . . .

· Declarative workflows run as the person who triggered the workflow either manually, or by adding or editing an item.

· Individual workflow actions can be made to elevate permissions.

· The RTM version of the server allowed workflows to run as SharePoint System, but had a security vulnerability.

· In SP1 the security problem was fixed, but declarative workflows can no longer be triggered by the SharePoint System account.

· In the SharePoint Infrastructure public update box administrators can allow email enabled lists to trigger workflows as the last person to save the workflow when an item is created via email. Run “stsadm.exe –o setproperty –propertyname declarativeworkflowautostartonemailenabled –propertyvalue yes” on the patched server to enable this.

So when building a declarative workflow take a moment to consider under what user context the workflow is running so you can better plan what the workflow is able to do.

A very simple fix would’ve just been to add in a ‘toggle’ (radio option) of "run as admin / run as user" in the initial workflow creation screen in SPD to give workflow designers the ability to choose at "design time", how the workflow would operate (the context in which to run under).

Is this too far fetched an idea to develop in future service packs / releases?

-Request list which looks up appropriate approver from another list based on ERP access type requested

-Accept/reject task assigned to approver

-based on decision, task raised on service desk to create user in ERP system

Ran into two serious flaws:

-rights required on task list make it impossible to block requestor from approving own request

-modified by info on task make it impossible to audit who actually granted approval

Attempts to restrict access to the task list itself unsuccessful

-redirect off edit form (edit this task) puts you in the all items list view

-Site Actions/View all site content provides another route to the task list

I can fix this with a Vis Studio custom workflow, but SharePoint is all about empowering users.

The out of the box workflows sound good on paper, but do not measure up to real world considerations. Try explaining that to senior managers who bought the product based on impressive "ease of use" demonstration videos, or to the department head who proudly shows you his seriously flawed creation.

Why not just add a feature to enable the workflow to Run As a specified admin or group with permissions so this isn’t such a headache? It would be great if the workflow wizard provided a selector to specify which user the workflow should run as for items that require elevated permissions. This is something that should have been incorporated in V1. The fact that custom workflows created in sharepoint designer require hacking to get them to run or require that you give the user contribute to the permissions when you really just want them to be able to execute the workflow, really makes the current situation more of a security issue than if it was written with the ability to control the operations that are run elevated.

The amount of time you guys have 1) spent explaining the issue 2) spent debugging it without a solution and 3) spent on the phone with people and responding to them by email, is probably in the upwards of millions of dollars if you do the math on the time*salary rate. The lesson here is, rather than make it some obscure bug/feature that completely breaks the workflow, why not finish out the feature by including the right stuff?

Your approach leaves a problem so it isn’t really a fix – malicious users could then run a workflow as an admin and do things they are not allowed to do normally (in fact, you just made it really easy for them). This is a huge security hole. Just build the workflow in Visual Studio and all of your problems go away.

I’m shocked how Sharepoint team solved this issue. They started more problems then they solved. To have a option to specify "run as" for sharepoint designer workflow is a must. No one will use SPD for workflows, they will start coding it and I think more problems will arise.

I have to agree with Kosher above. We use SPD workflows to process infopath forms and move them into the appropriate libraries afterwards. Since the workflow runs as the user submitting the form, we are basically forced to give that user write access to the libraries. This causes a much greater security concern for us then the original loophole ever would have.

At this point we have two options – don’t use SPD workflows or use them and allow users access to libraries that they wouldn’t have otherwise. A simple "Run As" screen on the SPD workflow wizard would solve this problem for us.

I agree completely with the above comments, i.e. there needs to be an option for SPD workflows to execute under the system account. We’re having exactly the same challenge – now we have to grant contributor rights to all of our users. In the original scenario it’s not a problem as we don’t let anyone but developers / designers have access to SPD & related privileges. It is becoming painfully obvious that if you want to get any real work done you still have to write custom code. Which is exactly what we were trying to get away from by moving to MOSS in the first place…

These changes give our developers quite a lot of headache. Workflows are an awesome functionality and in theory these provide users (anonymous and view only) the ability to start a workflow (which for example increases a viewcount). Right now we have to open these libraries/lists for all users. Fortunately we need to make these changes in an isolated environment but I shiver on the thought of having to implement this in a less controlled environment…

Any update on when the real issue is solved and workflows can once again run as system account?

After installing MOSS 2007 SP2, SharePoint designer workflows are not starting up automatically. Start option of workflow is “Automatically start this workflow when a new item is created”.

Same workflow run normally if I start it manually. Can’t find any entry related to this issue in logs. Before installing SP2 Workflows were working fine.

According to our requirements we cannot give a user who is creating item permission on Document library. So our workflow use to run by system account. Now it is not getting triggered we have many such workflows in system so can’t change all of them.

Is there any workaround for running workflow using system account and triggering automatically??

So, let me understand the situation. You took away the ability for a workflow to perform properly in SPD utilizing the system account because some saavy and/or malicious people could find a way to gain information they shouldn’t normally be able to access. I understand that. However, giving normal users the ability to edit/contribute to lists/libraries they shouldn’t have access to is a much higher security problem. You locked the front door, but gave everyone in your neighborhood keys to your house.

This is a giant concern for us. We don’t have Visual Studio developers on site to code workflows that they shouldn’t have to do in the first place.

Most people don’t let the masses create their own workflows, they are usually created by admins and/or designers that are TRUSTED to perform the right functions within the workflows. What you have done by removing the system account ability and instead forcing the ENTIRE workflow to go off of the INITIATOR, is force companies to give unwarranted rights to entire companies of people just to get the workflows to act as they should.

This is not a fix to a security problem, it is a rash fix to a bug that causes a SEVERE security issue in implementing. The ability for EVERYONE in my company to now be able to edit lists/libraries they shouldn’t have access to, is 100,000,000 times more destructive than the ability of one of my SPD designers and/or admins to be able to craft a workflow to get to information they shouldn’t be able to.

I cannot allow my users write access to a destination list. All I want to do is increment a couple of fields in a list item, and with proper privilege separation of workflows, it would have worked perfectly.

However now, since the workflow permission level is trimmed to that of the initiator, what can I do??? Answer — open up my data to the users, i.e. abolish security altogether. What utter rubbish.

I don’t want to hear about how this will work in SP2010 — I want it to work the way it should now.

The explanation is doublespeak BS. To plug the above security hole, you just need to trim the permissions to that of the workflow creator, not the initiator. Instead, you went and wrecked it for all of us.