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 to K2 object 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 in your environment and the roles, users, and groups that can view or execute objects before you configure permissions.
• You must be a member of the Security Administrators role to be able to configure permissions on K2 objects.
• 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. 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
• 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.

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 Views, Forms, SmartObjects
4. To set rights on K2 Designer see K2 Designer
5. To set rights on workflow steps see Workflows - Step Authorization