KB002945

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:

• K2 Certifications and Compliance
• Identity and Data Security in K2 Cloud
• K2 & GDPR

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.

• Securing K2 Sites and Tools
• Securing Data
• Securing K2 application elements (Views, Forms, Workflows, SmartObjects)
• Additional Security Measures
• Appendix: Security Considerations and Information for K2 Five

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.

• 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.
• Restricting what sites/domains are allowed to embed/host K2 sites: 

  As part of general website best practices, K2 websites should be configured in such a way that only trusted websites/domains are allowed to host/embed any K2 site within it through the use of iframes. The following configuration can be made either in the root K2 site's web.config to apply the same restriction to all K2 sites, or can be made in each individual site's web.config for granular control depending on your needs.

  By adding this configuration, the K2 site will add the standard "Content-Security-Policy" header with the "frame-ancestors" directive to all HTTP responses which instructs browsers if the resource should be allowed in a framed context.

  In the required web.config, search for "CustomHeaders" which would be found under the <system.webserver><httpProtocol> node.

  Add the following entry and add all allowed domains after the 'self' declaration:

  <add name="Content-Security-Policy" value="frame-ancestors 'self' *.denallix.com portal.sharepoint.com" />  

  In the above example, K2 sites can host K2 content within themselves due to the 'self' declaration - 'self' is always necessary - Without it K2 Management and K2 Workspace sites will not function.

  All subdomains of denallix.com are allowed due to the wildcard *.denallix.com declaration.

  The Portal subdomain from sharepoint.com is allowed due to the portal.sharepoint.com declaration.

  All other sites/domains will be blocked from embedding/hosting the K2 site.

  It is important to add your company's SharePoint site's domain to the list, otherwise K2 for SharePoint would run into errors.

  With this configuration, if a site that is not in the list embeds the K2 site, the site will show an error like "[your k2 site's domain] refused to connect" and in the browser's development console, an error like "Refused to frame 'https://[your k2 site's domain]/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' portal.denallix.com"."

  If a granular configuration is chosen, keep in mind that sites/virtual directories inherits settings from their parent site, and that each site can only have this configuration specified once - If this configuration is made in a parent site and the child site, then an error will occur when navigating to the child site stating "500 Internal Server Error - There is a problem with the resource you are looking for, and it cannot be displayed." which occurs due to conflicting/duplicate configurations.

• HTTPS is required to ensure communication between a user's browser and the K2 site is secure, for more info see K2 relies on HTTPS to secure communication between browsers and the server.

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.
• For K2 Five, 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.
• For K2 Five, when working with the Send an e-mail rule action in SmartForms, you can configure security settings to minimize the risk of open email relay. See Open Email Relay Prevention Configuration for information about best practices using email and configuration settings. 

• For added security to prevent information disclosure through verbose error messages, a new feature is introduced with K2 Cloud Update 17 and K2 Five 5.6 to handle all errors for anonymous views and forms.  Errors are shown as a generic message containing a CorrelationID. For more information see Change in behavior for error handling of anonymous views and forms for K2 Cloud Update 17 and  Change in behavior for error handling of anonymous views and forms for K2 Five 5.6. 

Appendix: Security Considerations and Information for K2 Five

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

• IIS URL Rewrite rule: To address the risk of the IIS Server's version being disclosed, IIS server administrators should configure a URL Rewrite rule that will remove or change the value.
• Network security: In addition 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.

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:

• K2 blackpearl 4.7: Extending the K2 platform
• K2 Five (5.5): Extending the K2 platform