Authorization Framework Overview

Roles can contain Users and Groups. If you wanted to define authorization for something in your K2 environment, you would normally create a Role first, and then assign members to that role by adding Users and Groups to the Role. (Eventually, you will give this role rights on the items they should have access to). You can manage the security of editing K2 roles by granting Modify permission to users who should be able to add or delete users from a role, and granting Delete permission to users who should be allowed to delete that role.

By default, three system roles are created during installation, but you can create as many additional ones as needed. Note that the default Roles cannot be deleted.

Security Rights on Roles

Security rights on roles determine who may edit and delete a Role.

Custom Roles

You can create custom roles and assign security to people who should be allowed to manage the role. As the role creator, you automatically get Modify, Delete rights on the role. When you create a new role, the Everyone role automatically inherits modify and delete rights.

For more information on creating roles and setting security on roles, see Roles.

You set rights on K2 objects to allow people in your organization to view the object in the category tree and use the object either at runtime or design time. The following table lists the objects and the corresponding rights that you can set. Keep in mind that View is a design time right, and Execute is a runtime right.

You can move objects around in a category by copying and pasting or by performing a direct move. Rights are required to perform these actions.

• Copy and pasting objects to a different category requires View rights on the object to be copied, and View rights on the destination category.
• Moving objects to a different category requires View rights on the object to be moved, and View rights on the destination category.
• To see objects or sub-categories in a category you must have View rights on that category.

Rights on K2 Objects

When defining rights on K2 Objects, first determine which roles can browse to that object in the category structure and modify the object using K2 Designer, and assign the roles the View right. You can use the category node in the K2 Management Site to do this .

While it is possible to give Users and Groups rights directly on K2 Objects, you should preferably create roles, and then assign rights to roles, because this will make subsequent security administration easier.

Right	Description	Implemented on	Assigned by
View	Allows you to see and use items at design time	Categories, Forms, Views, SmartObjects	Security Administrators
Execute	Allows you to use items at runtime	Categories and Forms You cannot execute a category, but you set execute rights on the category so that the child objects inherit the right to execute forms in the category. SmartObjects and views do not expose runtime rights. Security is controlled through Execute rights at Form level, because Forms contain SmartObjects and views.	Security Administrators

Permissions

Permissions are used to specify the behavior of rights on objects. Permissions allow or deny roles, users, and groups the ability to perform a right. Or, to put it differently: Rights define what you can do, Permissions define whether you are allowed to do it.

Consider our hypothetical “Human Resources” example, and suppose that we have a Form called “Ratings” that you want to protect. You may want to Execute > Allow “HR Admins” the Execute right on the Rating Forms so that members of that role can run the Form, but for all other users the permission should be Execute > Deny, so that other users are explicitly denied the ability to run that sensitive Form.

Permissions	Description
Allow	Explicitly grants the ability to perform an action.
Deny	Explicitly prevents the ability to perform an action. Note: Deny takes precedence over all permission settings.
None	Implicitly prevents the ability to perform an action. Can override this permission further down in the category/sub-category.
Inherited Allow	Implicitly grants the ability to perform the action based upon settings further up the category tree.
Inherited Deny	Implicitly prevents the ability to perform the action based upon settings further up the category tree. This permission cannot be changed.

You must be a member of the Security Administrators group to assign Permissions

About Inheritance

Inherited permissions are permissions passed down from the parent object to the child objects, making it easier to manage permissions. You can break inheritance or turn inheritance back on if previously broken. By default, rights are inherited.

Inheritance	Description
Break (Off)	Creates equivalent explicit rights based on the current inherited rights. Inheritance can be broken on any object.
Inherit (On)	When reactivating inheritance on an object, where a user, group or role exists on the parent object, any existing rights are replaced by the inherited permissions from the parent. When turning inheritance back on, only Inherited Allow, Inherited Deny, or None are applied to the roles, users, and groups. If the role, user, or group does NOT exist on the parent, the role, user, or group remains on the object and retains its explicit permissions. The role, user, or group is not removed or rights reset based on the parent settings.

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

• See the Before you begin topic and best practices section before you start assigning rights.
• Security Administrators always have View and Security Management rights on all objects. This ensures that they can never be locked out of the system.
• People needing to package or deploy solutions must be a member of the K2 Package and Deployment role and 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.
• Deny takes precedence over all permission settings (except for Security Administrators role).
• Anonymous forms ignore configured permissions and use default execute permissions which are Inherited Allow.

1. Plan out your security category structure before configuring permissions
   Before you start configuring rights and security in K2 Management, create a plan that describes what objects are to be accessed by which roles, users, and groups. Knowing this beforehand makes it easier to configure permissions.
2. Configure and test the permissions and rights in a development environment first.
   To avoid people in your organization from seeing and accessing objects not meant for them, configure and test your planned category security structure in a development environment. This allows you to correct the structure to ensure that the intended people have access to objects in the categories. Once you are satisfied with the configuration, you can configure your production environment to mirror the development environment.
3. Create test accounts in each role to test effective rights
   Create test accounts for each of the main roles in your organization to test out the effective rights. Log in as the test account user and ensure that the rights have been applied correctly and it is working as expected.
4. Assign rights to roles and / or groups rather than individual users
   Company roles, such as HR managers, are relatively static, whereas individuals may frequently join or leave the company, or change positions. To accommodate this movement of people, best practice is to assign permissions to roles or groups. When you do this, you can manage rights by adding or removing people from these roles or groups without having to revisit how permissions are currently working.
5. Block access by not granting permission, rather than explicitly denying rights
   Deny has the highest priority when determining effective rights, and this can make it difficult to allow an exception if a person needs access to an object but they belong to a group or role that has been denied permission. If a group or role should not have access to an object, then it is best not to set permissions. This ensures that access remains blocked. However, it is easier to grant permission in the future should this be necessary.
6. Set permissions at category level
   All securable objects must belong to a category, and then set security on the category level. By default, all objects within a category inherit permissions from the category. As the number of objects generally exceeds the number of categories, this simplifies your permissions configuration.
7. Use additive rights rather than breaking inheritance
   The nature of your solutions and category structure determines when you need to change the assigned permissions for various objects. Breaking inheritance should be kept to a minimum. Using an inherited model and the ability to view items is the recommended way to lock down objects and keep maintenance to a minimum. The Everyone role is added by default and it is recommended that you set the Everyone Role view rights on the highest category node to None, this will inherit down to the children. You can then set the required additive rights on roles that can be inherited by the children. Note when you set the Everyone Role rights to None you will no longer see the Everyone role in the Rights UI.