As you probably know SharePoint Designer 2010 allows you to create an impersonation step in which activities are done in impersonation mode. But what does it mean? And how it compares to Workbox impersonation?
I'll start to describe how the impersonation works in SPD 2010. By default (and it's the only option in SPD 2007) SPD workflows run in the context of the user who started the workflow. What it means that if your workflow is editing an item, checking some value on a list, adding items then this user needs to have permissions to do that in SharePoint. So in other words to edit an item with a workflow you need to make sure that every user who started the workflow has permissions to modify this item. If not, the workflow will fail. Impersonation allows you to run selected workflow activities in the context of the user who deployed the workflow. This approach is more safe, because users who create workflows are usually site owners or site collection admins and have permissions to do everything on the site.
Unfortunately both approaches have a big flaw. Lets imagine that we have quite complex process designed in SPD and it was started few weeks ago by user X. Unfortunately this user is no longer working for our company so his account was deactivated and his permissions revoked. Now if the workflow will try to edit an item it will fail, since the user who started the workflow no longer has permissions to edit the item .We can restart the workflow, but the problem is that we will need to start from beginning and loose all workflow data and progress. We will run even into bigger issues if user X was a workflow author and has used the impersonation steps in the workflow he has published. Now all workflows based on this workflow definition will crash when trying to do something that requires permissions.
Now let's take a look at impersonation in Workbox. By default all Workbox workflows run in the context of the SharePoint system account, in other words as the app pool account. This means that Workbox workflows will have full permissions to do everything on your SharePoint application. Before you start worrying that this is unsafe, lets look at the benefits of this approach.
First benefit is that you do not need to worry about ensuring that workflow starters or designers have all the permissions required for the workflow to run and that those permissions will not change some time (few days, month, year?) after the workflow was implemented.
Second benefit is that in many cases you do not want the users to have access to lists you are modifying or querying with the workflow. For example you would like the workflow to change the number of leave days the user has, but you don't want to allow the user to do that by themselves and you also want to make sure that each user sees only their own records.
Third benefit is that Workbox has a very nice feature in item activates. It allows you to decide if these activities should run as a system account or as a "current user". "Current user" in this case does not mean "user who has started the workflow" but the "user who has launched the action". So you are able to modify the item as the user who for example approved it and this will show in the item history and in the "modified by" column. You have also a third option "Current user with system rights". When you use this option Workbox will work in the context of the system account, but set the "Modified by" column to a current user. This way others will be able to see who has modified the item without the need to grant them additional permissions.
Now for the security concern. Theoretically running the workflow in the context of the system account can be dangerous - someone designing the workflow could do everything on the farm. Fortunately Workbox implements the security on the designer level. It means that users are not able to define or deploy a workflow that can modify or query objects (sites, lists, items) to which they do not have appropriate permissions. In other words - to modify an item on a list, to query a list, to see a site on a lookup tree you need to have "manage list" (for list and libraries) or "manage site" (for sites) permissions for the list or site you want to use. This way we ensure that if you cannot manage an object directly in SharePoint you will not be able to manage it and share it's contents using workflows.
All the above is true for any workflow solution that uses WWF engine and which workflows run as workflow author or initiator (for ex. Nintex).