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.
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?
We are facing a problem after installing SP2 on MOSS 2007.
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??
Any help is appreciated.
>> Is there any way, within Sharepoint Designer, to determine the name of the person that started the workflow? That is, to determine what context it is running under?
Man, I wish someone would answer that one...
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.
Which makes more sense?
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.
No fix here at all.......
I think what Craig said is very TRUE!
This leaves me screwed. And utterly pissed off.
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.
Here is some of the explanation in my terms.
I really had a great time with your post! I am looking forward to read more blog post regarding this! Well written!
any news yet?