When planning to secure the K2 platform, you should establish a methodology using models first, such as STRIDE or VAST. This article describes options and approaches for securing your K2 environment, with links to supporting documentation based on the feature and object you want to secure.

Once you have secured your K2 environment, you may want to review the article KB003338: Securing K2 Solutions for information on solution-specific security considerations. 

If you are looking for compliance information, see the following articles:

Table of Contents

This article is divided into three main sections including tools and features, data contained within or accessed by the platform, and objects you can create with the tools provided. There is also a fourth area that describes additional security measures you can perform that affect the platform but are not features of it, such as IP restrictions and IIS request filtering. Lastly, K2 Five customers can use the Appendix for information about securing on-premises K2 servers.

All links to common behavior for both K2 Cloud and K2 Five take you to K2 Cloud content. If you want to see the K2 Five version of the topic, replace k2cloud in the URL with k2five

Securing K2 Sites and Tools

Use the following information to restrict access or rights to K2 sites, design tools, administration tools, and K2 Mobile.

  • Restricting access to the K2 Designer: You can control who has access to the K2 Designer site (where authorised users can design SmartObjects, forms, and views). See the K2 Designer Authorization section of the Designer topic for more detail.
  • Restricting access to wizards in the workflow designer: You can restrict wizards in the workflow designer by setting View rights to Allow or Deny. Go to K2 Management and then to Categories > Workflow > Steps. Browse for the step you need to restrict and apply the appropriate View right to specific users, groups, and roles. For more information, see the Authorization Framework Overview. If you are using legacy workflow designers such as the Silverlight-based K2 Workflow Designer, see SmartWizard Security (Legacy) for more information on restricting the available wizards.
  • Creating and Editing SmartObjects: To restrict who may deploy SmartObjects, see SmartObject Security. To restrict who may create, update or delete SmartBox-based SmartObjects, see SmartBox Security.
  • Workflow Security: You can set rights for the workflow Server as a whole, or rights on specific workflow definitions:
    • Workflow Server: There are three main rights related to workflows at the server level, namely Admin, Export, and Impersonate. Anyone with Admin rights can, for example, administer all workflows deployed to the server using K2 Management. Anyone with Export rights can deploy workflows to the server. Finally, accounts with Impersonate rights can impersonate other users when connecting to K2. For more information see Server Rights. Note that you cannot use K2 roles for rights assignments on the workflow server.
    • Workflow Definitions: There are five main rights for all deployed workflows that apply to specific workflow definitions. For more information about these rights and how to configure them, see Rights. The rights are:
      • Admin: Allows administering a specific workflow using K2 Management or other management tools. This right allows, for example, a workflow admin to schedule when instances of the workflow start. 
      • Start: Allows starting a new instance of the workflow.
      • View: Allows the ability to see workflow reporting data.
      • View Participate: Allows the ability to see workflow reporting data only for those workflow instances they started or actioned a task in.
      • Server Event: Allows the account to execute a server event (typically limited to the service account)
      • Using Roles: K2 provides several built-in Roles that control who has access to administer the K2 environment, control data, and deploy packages. These roles include:
    • Using Roles: K2 provides several built-in Roles that control who has access to administer the K2 environment, control data, and deploy packages. These roles include:
      • Security Administrators: Role for administering security on the K2 server.
      • Data Administrators: Role for accessing all SmartBox Data regardless of data access settings.
      • Package and Deployment: Role for packaging and deploying K2 items from and to K2 servers.
      • Everyone: All authenticated users. Note that by default, the Everyone role has access to everything on the K2 server until you modify security, except administrative functionality.
You can also create custom roles for use across the platform, and set Role Authorization to control the following rights on roles:
  • Modify: Allows the ability to modify the membership of the role.
  • Delete: Allows the ability to delete the role.
  • Security: Allows the ability to modify the security of the role.
To use Roles to restrict access to SmartBox data, see the next section, Securing Data.
  • Mobile Security: If you do not want users of the K2 Mobile to stay signed in, see the Automatic Lock section of the Mobile topic. There are also some other configuration options on this page.

Finally, see Permissions needed for common tasks for a summary of the permissions needed for various tasks.

Securing Data

You may want to restrict access to data stored in, or accessed through, K2 SmartObjects. 

  • Controlling Access to Data: The Data Access feature allows you to control access to data stored in the K2 database in SmartBox SmartObjects. For more information about SmartBox data security, see SmartBox Data Access. Note that you have the choice of three types of data access, including Full, Limited, and Included.
    • Full data access level allows someone access to all data in a SmartBox SmartObject
    • Limited allows you to configure a filter on the SmartObject so that people with this level can only see data that matches the filter.
    • Included allows you to configure security across associated SmartBox SmartObjects.
  • Accessing Line of Business Systems: For controlling who has access to line-of-business data, such as SQL, SharePoint, and data services, set the applicable Authentication Mode when creating connections to these LOB systems. See Authentication Modes for more information about what type of authentication methods are available to LOB systems. Note that it is up to the LOB system to apply security based on the Authentication Mode used. Also, note that some service types allow you to configure the connection to use SSL such as SQL Server.

Securing K2 Application Elements (Views, Forms, Workflows, SmartObjects)

  • Authorization Framework: For securing items that you create with K2, such as views, forms, and SmartObjects, you use the Authorization Framework. This system, which is based on inherited rights, enables you to configure Allow and Deny permissions for rights that differ based on the type of item you are securing. For more information see Authorization Framework Overview. Note that these rights apply to both design time and runtime.
  • App Framework: If you are creating apps using the App Framework, see Administer the App Framework for information about securing this feature.

Additional Security Measures

In addition to common security approaches like encrypting backups and network communication, there is some additional configuration that you may consider doing.

  • For K2 Cloud and K2 Five, if you use SmartForms in a kiosk scenario where a user's login should not persist across browser sessions, add a button to the form to logout. Configure a rule for the button and use the Navigate to URL action with the following URL: https://<your tenant or K2 site>/Runtime/_trust/logout.aspx
  • For K2 Cloud, if you need to lock down access to your K2 Cloud tenant to a range of IP addresses, please log a support ticket.
  • For K2 Five, you can limit the exposure of deployed forms by setting up Request Filtering on your SmartForms Runtime sites. See Configure Request Filtering to Secure a Secondary SmartForms Runtime Site for more information. You can control who can execute forms using the authorization framework, but this would add an extra level of security.

Appendix: Security Considerations and Information for K2 Five

When installing K2 Five, take into consideration network and infrastructure-related security, such as:

  • Network security: In additional to general security best practices, it is important to use SSL throughout your network so that traffic is encrypted. See Bindings button and pop-up page for more information.
  • Use Kerberos if you need constrained delegation. This allows you to lock down network access to systems based on service accounts. For more information see Kerberos
  • If you don't need Kerberos, K2 includes a feature called Pass Through Authentication that allows you to more easily configure the K2 Platform to integrate with other systems.
  • Anonymous Sites allow you to create separate SmartForms runtime sites to expose SmartForms to users outside of your organization. There are also security settings you can change in the web.config file of the runtime site.
  • Accounts used in K2 contains a list of the types of accounts and their required permissions for various features and parts of the K2 platform.
  • Required Permissions is also a good resource for learning more about what rights are necessary in Windows and Azure for configuring K2. Note that you should not use the same account for the Windows and IIS-related accounts necessary to install K2. Using separate accounts limits the scope of system permissions that K2 requires. For more information see K2 Web Applications.
  • In the planning section of the Installation and Configuration Guide, read the Security Considerations topic for additional detail on security options you may want to leverage.
  • See Tips and Best Practices for additional information on installing and configuring K2 Five.
  • If you have questions about securing your K2 environment or have specific requirements, you may want to contact K2 Professional Services to help plan your security approach.