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.
Comments
Anonymous
September 28, 2008
On our BLOG http://workflowclubmoss.blogspot.com/2008/09/microsoft-sharepoint-designer-team-blog.html -- Pierre Erol GIRAUDY Président du Club MOSS 2007 et MUG. Vice-Président Club UGO2007 http://clubmoss2007.org/ http://www.mugfrance.fr/ http://www.viadeo.com/fr/profile/pierreerol.giraudyAnonymous
September 30, 2008
The comment has been removedAnonymous
October 01, 2008
The comment has been removedAnonymous
October 07, 2008
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?Anonymous
October 08, 2008
The comment has been removedAnonymous
October 13, 2008
The comment has been removedAnonymous
October 22, 2008
The comment has been removedAnonymous
November 03, 2008
Nach längere Zeit habe ich mal wieder die Kaffeetasse hervorgekramt und stelle wieder ein paar interessanteAnonymous
November 03, 2008
Nach längere Zeit habe ich mal wieder die Kaffeetasse hervorgekramt und stelle wieder ein paar interessanteAnonymous
November 10, 2008
Direkter Download: SPPD-105-2008-11-10 Aktuell SharePoint Guidance - November 2008 SharePointPartnerAnonymous
December 11, 2008
There should be a switch or custom action that will override this behavior. This change has drastically lowered the possible workflow scenarios that could be addressed by Designer. At the very least the workflow should run with the rights of the users that created that workflow. Also, if there is a way to elevate permissions with a custom workflow action, can you at least proved the workflow action?Anonymous
February 25, 2009
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.Anonymous
March 02, 2009
So what do SharePoint Workflows created in Visual Studio run as?Anonymous
March 12, 2009
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.Anonymous
April 23, 2009
The comment has been removedAnonymous
May 08, 2009
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?Anonymous
August 10, 2009
Hi, 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.Anonymous
August 12, 2009
>> 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...Anonymous
August 27, 2009
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?Anonymous
August 28, 2009
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.......Anonymous
February 26, 2010
I think what Craig said is very TRUE!Anonymous
March 14, 2010
The comment has been removedAnonymous
April 05, 2010
Thanks, Here is some of the explanation in my terms. http://praveenbattula.blogspot.com/2010/02/declarative-workflows-cannot.htmlAnonymous
July 07, 2010
I really had a great time with your post! I am looking forward to read more blog post regarding this! Well written!Anonymous
September 20, 2010
any news yet?