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.
On our BLOG
Pierre Erol GIRAUDY
Président du Club MOSS 2007 et MUG.
Vice-Président Club UGO2007
Top News Stories SMC implements MOSS 2007 in Middle East (ITWeb) SMC Enterprise has successfully completed
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?
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?
Scenario for SP Designer workflow:
-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?
Dink & Kosher-
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.
Nach längere Zeit habe ich mal wieder die Kaffeetasse hervorgekramt und stelle wieder ein paar interessante
Direkter Download: SPPD-105-2008-11-10 Aktuell SharePoint Guidance - November 2008 SharePointPartner
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?
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.
So what do SharePoint Workflows created in Visual Studio run as?
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...