Server Rights

The Server Rights node is used to add, edit, remove and refresh Workflow server permissions for users or groups. These rights will determine which users and groups can administer a K2 workflow server, export new workflows or impersonate a user.

The table below explains each permission in more detail.

Permission Description Usually Assigned to
Admin Use the management console (and management tools in Process Portals sites) to administer a K2 environment, Users with this right can fully administer a K2 environment and may edit server rights for other users.
  • K2 administrators/system administrators and (sometimes) helpdesk staff in a production environment.
  • Developers usually have Admin rights to Development environments and (sometimes) Test/QA environments. Depending on your organization’s security, it is usually not recommended to give developers Admin rights to a production K2 environment.
Export Allows you to deploy workflows from within K2 Designer for SharePoint as well as Package and Deploy Solutions in your environment.
  • System administrators/deployment users in production environments, especially in environments that have strict change control procedures.
  • Developers normally have Export rights to development environments.
  • To allow for deployment of workflows created with K2 Designer and K2 Designer for SharePoint, the user account associated with an application pool in SharePoint must also have Export permission to K2.
Impersonate

Impersonate another user account after the initial connection to K2. This permission is normally used when user credentials cannot be transferred between machines and Kerberos cannot be used to address this requirement, and is also used for K2’s Pass-Through Authentication mechanism .

It also allows for connections established in one context to impersonate another user. When the user opens a connection to the server through the client API for an example, you have a method connection ImpersonateUser(Username) which will then open the connection as the userName specified. For example John has impersonate rights. He can now open a connection and impersonate as Sue. With the connection open as Sue, he can do everything as if Sue was logged on.

  • This permission is reserved for the service account and is configured automatically for the account during K2 onboarding.