Security Considerations

When planning your environment, take the security considerations discussed in the following section into account.

Service Accounts

Review the topic Accounts used in a K2 Installation for details of the various accounts used in a K2 installation and some practice recommendations for these accounts to comply with the STRIDE security model .

Kerberos vs K2 Pass-Through Authentication

When planning an environment whether it be Standalone, Distributed or Farm, the topic of a secure method of authentication is of paramount importance. When it comes to the K2 product stack as a whole, there are two available options: Kerberos and K2 Pass-Through Authentication.

From a K2 perspective it is recommended that Kerberos authentication be used as a the primary form of authentication to pass user credentials between physical or logical machine boundaries. If Kerberos is not available or cannot be configured, K2 Pass-Through Authentication can be used.

K2 Site Authentication

K2 Site uses Nintex K2 security mechanisms for users (more on that in the topic SmartForms Authentication), but can also be set up to allow anonymous access to sites, Views or Forms. The two methods of allowing anonymous access are:

Separation of the Designer and Runtime sites

An option is to separate the K2 Designer and Runtime sites on different physical machines in an environment. This allows for an extra layer of security, so that if a site or machine is brought down by an attack, the other K2 components are able to continue function. One draw back of such an approach is the performance impact when separating components across multiple machines. It is recommended that if this approach is taken, adequate resources are applied to the machines that will host theses sites and network communication between them, to ensure acceptable levels of performance.

PDF Converter Server-Side Request Forgery Prevention Configuration

When working with the PDF Converter Service or Save as PDF control, you can configure security settings to restrict which hosts and IP addresses it is allowed to load any type of resource from. See PDF Converter Server-Side Request Forgery Prevention Configuration for more information.

K2 for SharePoint

When considering security with K2 for SharePoint, the focus should be placed on SharePoint itself. Ensure that all necessary rights and permissions are set up correctly and any SharePoint security requirements are met prior to integrating with K2.

Custom K2 extensions and unauthorized assemblies

It is possible to customize K2 using custom components like SmartBrokers, Controls, OAuth Extensions, User Providers, and others. This customization loads installed custom assemblies dynamically. A risk exists that unauthorized assemblies can be installed into certain folders on the server which will then be automatically loaded by K2. To prevent this security risk, it is essential to follow the principle of least privilege and use Windows Server administration best practices.

Focus on these best practices:

  • Only allow accounts with administrators access to log into the K2 Server machine.
  • Do not give write/modify access to the K2 installation directory, to any users that are not automatically assigned rights by the K2 Setup Manager. Make sure that only server administrators can make changes to any folders within the K2 installation directory.

For specific information about folder locations for custom components, refer to the following documentation:

Installations of versions before K2 Five (5.6), configured the ServiceBroker folder with full control for the Authenticated Users role. In environments with K2 versions older than K2 Five (5.6), and environments upgraded to K2 Five (5.6), the folder permissions must be manually updated, and all permissions removed except the Read permission for the Authenticated Users group.