Note: This documentation gets updated only when necessary, as the product is in sustained mode. For product updates see the Release Notes.

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	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.

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.

Adding Server Rights

Follow these steps to add rights:

Click Add from the Server Rights view.

The Server Rights - Add Users and Groups page opens. Use the image and table below as a guideline for the configuration:

Field	Description
Search	Click the Search drop-down and select to search for users or groups.
Label	Click the Label drop-down and select the Security Provider label you want to search on.
Type	Click the Type drop-down and select the type of search that will be performed.
Search Button	Type a value in the text box provided and click the Search button.
Add Button	The matching users or groups will be returned in the first view. Select a user or group and click Add. The user or group will now be listed in the second view. You can add multiple users or groups by doing a new search and clicking the Add button again.
Remove Button	To remove users, select the user or group from the second view and click Remove.
Next Button	Click Next to continue with the configuration.
Cancel Button	Click Cancel if you no longer want to complete the configuration. This will take you back to the Rights tab.

Select the applicable rights per user or group, and click Finish.