Post Installation Security Considerations

Once K2 has been installed there are various rights and settings that must be configured to allow people access to certain K2 functionality. Listed below are the various areas that require configuration to ensure the K2 installation is functional.

K2 blackpearl

Server Administrators may assign permissions to users/accounts at a Menu Item Level in Workspace. This allows or restricts access of a connected account to the menu items such as Management Console or Event Notifications in K2 Workspace. When an installation completes, no rights are assigned or restricted, meaning all authenticated users will have access to the K2 Workspace website and all of the menu items. When applying the firsts rights within each menu, all other menu items will be blocked until the necessary rights are implemented.

  • Reports: Allows you to access the Report Designer to build workflow reports.
  • Management: Opens the Management Console allowing you to administer the K2 environment.
  • Notification Events: Allows you to use the Notification Event Designer to configure a customizable notification when an event occurs in K2.
  • Security: Allows you to use the Workspace Permissions to allocate rights to menu items in K2 Workspace.
  • User Settings: Allows you to cache credentials when you require more than one set of user credentials to log into backend systems.

Recommendation:
It is recommended that domain users be assigned the right to access the Reports menu Item. This provides access to the Home tab where the Standard Reports can be actioned and they will be able to see any and all information which is controlled by process rights. They will have access to the Report tab, where the browser based Report Designer is accessible to query information from SmartObjects. Other tabs and menus will not be available as the necessary rights may not be assigned.

The Environment Library is a repository of environment-specific values or "placeholders" for each of your K2 environments, these environment-specific values, usually things like server names, connection strings, “from” email addresses can be managed by the Server Administrator, those with Server Admin rights. After installing K2 on your environment, these libraries should be checked to ensure the right model is implemented to support deployments by proper designated and others accounts are not elevated beyond need.

Recommendation: The practices to follow depend on how the set up was completed for Environment Libraries. In any implementation, each K2 Server should name its libraries to distinguish them from all other environments and libraries. The first library template is set and libraries are named upon installation as “Development” and “Production.” Rename those libraries to represent the model and set the one to be the default on each.

If there is configured a single K2 farm/server to house Environment services (Single Source of Truth model) for use by developers and publishers, then those libraries are named for each target environment which will be published to. In this scenario that would be “Development”, “Testing”, and “Production.” Then restrict access to the other K2 Servers and Environment services (i.e. restrict on TEST and PROD) for developers and publishers.

The other servers should then have only one library, the default, and its name reflecting itself (i.e. “Testing [Local]” and “Production [Local]”). Deployments that use MS Build, or run directly from K2 Studio or Visual Studio, will not touch those target server’s environment libraries.

Deployments that use the K2 Package and Deployment tool, may deploy environment fields and values to the target servers’ default library, regardless of its name.

For more information see: Understanding environment libraries

This sections discusses various rights that are used within K2 security and recommendations to the application of these rights.

Server Rights Description Recommendations
Admin An inclusive right to all administrative actions on the K2 Server.
  • An authority group (AD group) be assigned this right such as K2 Administrators. This group may be used across all K2 server environments.
  • The membership of this group be regulated via domain policies. A more robust method would be to create separate groups for administrators on different environments such as K2 Test Administrators , K2 PROD Administrators, etc.
  • End users should rarely, if ever, need this level of access.
Export Allows you to deploy workflow definitions from any of the K2 Designers or the Package and Deploy tool to the K2 Server.
  • An authority group (AD group) be assigned this right such as K2 Developers. In TEST and PROD environments this application should be temporary.
  • Rights be assigned to groups such as K2 DEV Publishers, K2 Test Publishers and K2 PROD Publishers. This allows for the regulation of who can deploy workflows as well as deploy K2 Packages.
  • If a teams of users are relatively small, assign this right to individuals rather than groups. This can lead to more work regarding the maintenance of user rights and is generally discouraged.
Impersonate Allows your account to be used in programmatic implementations to open connections to the K2 Server in various K2 API calls, and pass alternative account names to the Connection object’s Impersonate User method.
  • This right is typically given to Service Accounts rather than user accounts.
  • Only accounts that run in or host other systems and also need to open K2 connections that pass in a user context, require this right.
  • This is likely better assigned as a singule account (service type) rather than an authority group. As an example that illustrates this usage, consider a plug-in assembly that might be added to Microsoft Dynamics CRM system, where the code in that plug-in will run hosted by a special CRM service account and execute K2 API calls to open connections and invoke K2 process instances. The user context who is operating in the CRM application can be passed to the K2 workflow, the CRM service account which first connects to K2 would need the “Impersonate” right to then pass in user context information to the Impersonate method of the K2 connection object.
Process Rights Description Recommendations
Admin Allows you to start and view process instances, and to manage the process rights from Management Console. Assign to the K2 Administrators group.
Start Allows you to start a process - without it, an error occurs.
  • Assign rights to a group or users who require the ability to start new process instances.
  • The K2 Service Account would require this right if another process instance has been configured with an IPC event to call this process instance.
View Allows you to view all process instances, in designers and reporting, without being a participant in the process instance. The View Flow page is regulated by this permission. Assign to users or accounts that require a reporting role and to observe all information regarding all instances of a process definition such as system administrators.
View Participate Allows a participant, i.e. any person defined in destination rules of process activities, to view the details of the process instance. The person connected to K2 will have access to process instance information once movement reaches the activity instance with the said destination rule. The View Flow page is regulated by this permission. Assign to accounts or users who require the ability to review information in which they have participated in.
Server Event Allows an account to be used in programmatic implementations to open connections to the K2 Server and make use of the ServerItem object, invoking its Finish method. This must have been enabled in code within an Activity’s Server Event item causing an asynchronous event to wait for a call-back from some external system. Assign to service account types instead of user accounts.

The Run As right allows the context to be changed from the default K2 service account to another specified account for certain events. For example for certain Server Events such as:

  • Any server based event
  • Active Directory Wizard
  • Exchange Wizard
  • Data Event

Recommendation:
Generally the K2 Service Account will be used to execute server events in workflow activities. This allows the account to authenticate and receive authorization to other resources on different systems. If the K2 Service Account cannot be used, it is recommended that another account be identified to take on this role. Mminimal privilege authorizations should be given to the K2 account in question on other systems as to provide a more vigorous security policy.

Once a K2 process definition has been deployed, the actions, the choices of outcomes that are available, can be configured to allow for secure access.

The following action rights are available:

  • Allow
  • Deny

Recommendation:
An administrator will determine which users are able to access certain actions. This requires care and awareness as to prevent the possibility of no user being able to complete a workflow due to incorrect rights being assigned. The securing of action choices can become complex and adequate planning and application design must be taken.

Accounts are automatically given access to any worklist item (assigned tasks) via a user, group or role membership being assigned to an Activity's Destination rule. When connecting to the K2 Server or services the K2 worklist will retrieve the logged in users tasks via their identity and the ability to action on a worklist item will become available.

Recommendation:
For the process definition configured destination rules, all resolved users have full rights to any action choice in the worklist item, unless affected by administrators after a process definition is deployed.

If participants or administrators use the Delegate action from any version of the K2 Worklist, additional participants become “shared” into the worklist item, and pick-up the access to the worklist item dynamically. Standard worklist tooling in K2 will retrieve worklist items for these shared users now. Note that the methods in the K2 API for retrieving worklists for destination configured users and for retrieving worklists for shared delegated users differ, and custom solutions on the worklist API should be addressed accordingly.

Configure security for the K2 SmartBox SmartObject data provider, including the ability to control who may create, update or delete SmartObject definitions in this storage area (design-time permissions), as well as runtime permissions to control who may execute what methods for SmartObjects that use SmartBox.

To configure rights for SmartObjects open the K2 Management Console in K2 Workspace.

Rights Description Recommendations
Create and Update Object Allows for the deployment of SmartObject Definitions (SODX) to the K2 Server. It is recommended that this right be assigned to groups such as K2 Developers who will be creating and deploying SmartObjects to the K2 Server.
Delete Object Allows for the deletion of a SmartObject definitions (SODX) from a K2 Server. Assign rights to people who can manage SmartObjects such as administrators. The granting of this right should be restricted, and only Users/Groups that require this right should be considered.

SmartObjects built against the SmartBox Service Broker allow rights to be assigned per method which ensures only those authorized to interact with data can do so. Even though data is stored on a database via SQL Server, it is the broker and SmartObject which allows for authorization configurations within K2. Examples of SmartObject methods are shown below:

  • Create: Adds a row to the data source.
  • Load: Reads a row from the data source.
  • Save: Updates a row in the data source.
  • Delete: Deletes a row from the data source.
  • Get List: Reads multiple rows from the data source.
  • Modify Object: Allows Modify/Deploy revisions to a SmartBox SmartObject.

Recommendation:

It is strongly recommended that Line of Business data be stored in other data repositories, and not be placed in SmartBox SmartObjects.

Most SmartObjects deployed are advanced SmartObjects, the current authorization model for these SmartObjects is always managed by the Service/Data Provider itself which sits under the Service Instance’s connection configuration settings mapping through a Service Broker. Authorization for any data sources that have been registered in K2 through Service Brokers and Service Instances are controlled by the relevant service such as SAP or Exchange.

Recommendation:
Refer to the various service types that can be registered in K2 and view the specific service authentication that is required for each,

See K2 SmartActions Email Security.

K2 smartforms

Currently there are no tools available to regulate authorization of forms and views.

Recommendation:
Despite this limitation a developer can build a form or view to include authorization decisions within its logic. It becomes the responsibility of application architect to plan specifically where forms, views or even controls should be accessed or not by the current user.

Currently there is minimal tooling applied to K2 smartforms when it comes to regulating authorization to resources.

Recommendation:
It is recommended that the use of IIS bindings and website management practices are used to secure access to the K2 smartforms sites. See the following online article which discusses ways to secure the K2 Designer web site.