Server Rights

The Management Console in K2 Workspace is superseded by the K2 Management Site and you should use the K2 Management Site to administer your K2 environment, rather than Management Console in K2 Workspace. (In certain cases you may need to use the Management Console in K2 Workspace to perform tasks that are not exposed in the K2 Management Site.)

The Server Rights settings under Workflow Server will determine which users and groups can administer a K2 environment, export new workflows or impersonate a user. The table below describes each right 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 Export/Deploy new workflow definitions to the K2 environment from K2 Studio, K2 for Visual Studio or a K2 deployment (.msbuild) package.
  • 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 the 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 usually reserved for system accounts and is usually configured automatically for these accounts during a K2 installation.
  • If any custom-code application uses the ImpersonateUser(“username”); method in the K2 connection object, the user account executing the code must have Impersonate rights on the K2 server.