Before you begin

Read the Authorization Framework overview topic to gain an understanding of how authorization functions in a K2 environment. Before you begin configuring rights and permissions you should be aware of the following:

  • Role security is different than K2 object permissions and Service Types and Service Instances permissions. These are different types of authorization and by keeping them separated in your mind makes it easier to understand authorization.
  • Rights are different to Permissions. Rights define what you can do, Permissions define whether you are allowed to do it.
  • Create a written plan of the roles in your environment and the security that must be assigned to each role before you create and configure them.
  • Create a written plan of the K2 objects, Service Types, and Service Instances in your environment and the roles, users, and groups that can view or execute these items before you configure permissions.
  • You must be a member of the Security Administrators role or have Security rights to be able to configure permissions on K2 objects, Service Types and Service Instances.
  • As the person creating a category, SmartObject, view or form you have the rights (Security rights) to assign rights to others, including the ability to assign Security rights to others.
  • To manage Service Instances and Service Types in K2 Management, you must at least have Create, Modify, Delete or Security rights on at least one Service Instance or Service Type. The SmartBox, Workflow Service and Workflow Reporting Service Types are excluded when determining if a user can access K2 Management because the Everyone role is granted Modify rights by default.
  • To create and deploy K2 packages you must be a member of the Package and Deployment role, have View rights on all the objects in the package. Modify rights are needed on the objects that need to be overwritten during deployment. If deploying SharePoint objects, Modify rights are also required on the SharePoint 2013 Folder in the category tree. If you have explicit Deny rights on any of the objects to be packaged, you will be stopped when creating the package with a list of denied objects as deny takes precedence over the role.
  • You must have View rights to be able to access and use the K2 Designer.
  • The Everyone role is added by default to custom roles, which ensures that, on upgrade, your environment functions as it did before.
  • Setting the Everyone role's view rights to None on the parent object, the Categories node, will remove the Everyone Role from the children objects and the Everyone role will not be displayed in the Rights pane.
  • To remove the Everyone role, you must break inheritance first, select Everyone then click on the trash can.
  • Removing a role from the rights pane using the trash can will clear the explicit permissions, this is the same as setting the rights to None.
  • Set the Everyone Role view rights on the highest category node to None, this will inherit down to the children. Note when you set the Everyone Role rights to None you will no longer see the Everyone role in the Rights UI.
  • When restoring inheritance on a node where you previously removed the Everyone role, if the Everyone role has rights higher up in the category system, when you inherit permissions again the Everyone role will be added back to the node’s rights with View – Inherit allow permissions.
  • Deny has the highest priority when determining effective rights.
  • To view an object, you must have View rights on the parent category. If you do not, you cannot see the object in the category tree even though you have View rights on the artifact.
  • SmartObjects and views by default are open at runtime (no security) and have view rights which allow you to view and use them at design time . You cannot grant execute rights for SmartObjects and views and will not see the execute right displayed in the Management site UI for these objects. To secure SmartObject data see Data Access.
  • Modify rights must be assigned to the SmartObject you want to create an association with if a new property is created as part of the association configuration.
  • Modify rights are required to edit, rename and move objects in the designer. If you do not have Modify rights the relevant menu options will not be displayed in the menu pop up or the object's properties page.
  • By default all objects' rights are open from the root object down, meaning inherited permissions are passed down from the parent object to the children and you need to secure the objects by modifying the object rights. This can be achieved by either breaking inheritance and assigning rights or removing the Everyone role and assigning specific roles with rights to the objects.
  • Breaking inheritance is applied to all roles, users, and groups assigned to the category or object. You cannot break inheritance on an individual role, user, or group.
  • If your account is included in the Execute: Deny right on a view and you attempt to run a form that contains that view, the form will display an error because you have been denied the right to execute a view contained in that form.
  • Service Instances Security - Serves as the root level from where rights are inherited and is useful where rights must apply for certain users across all Service Types and Service Instances.
  • Service Types - Inherits rights from the Service Instances Security level.
  • Service Instances - Inherits rights from its associated Service Type.

Setting permissions

  1. To create roles see K2 Management Site> Users> Roles
  2. To set role permissions see Add Role Security
  3. To set object rights see Categories,Views, Forms, SmartObjects
  4. To set rights on K2 Designer see K2 Designer
  5. To set Service Types and Service Instances rights see Service Instances Security, Service Types, Service Instances.
  6. To set rights on workflow steps see Workflows - Step Authorization
Related Topics