Authorization Framework Overview

Roles can contain Users and Groups. If you wanted to define authorization for something in your 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 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, and Security 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 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, Create, Modify, and Delete are design time rights, 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:
  • Security rights to the object
  • Modify rights on the source and destination categories
• To see objects or sub-categories in a category you must have View rights on that category

Rights on Objects

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

While it is possible to give Users and Groups rights directly on 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
Create	Allows you to create categories (folders) and artifacts such as SmartObjects, views, and forms in the Designer.	Categories	Security Administrators
Modify	Allows you to update (for example edit, rename, move, create associations and package and deploy) items at design time	Categories, Forms, Views, SmartObjects	Security Administrators
Execute	Allows you to use items at runtime	Categories, Views 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 do not expose runtime rights. Security is controlled through Execute rights at the View and Form level.	Security Administrators
Delete	Allows you to delete items in the Designer and Management.	Categories, SmartObjects, Views, and Forms	Security Administrators
Security	Allows you to give other people the right to assign rights on a specified item.	Categories, SmartObjects, Views, and Forms	Person creating the object or 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 have Security rights to assign Permissions. Members of the Security Administrators group and the creator of an object by default get Security rights. You can also assign Security rights to other roles as required.

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

• To create roles see Management Site> Users> Roles
• To set Role permissions see Add Role Security
• To set object rights see Categories,Views, Forms, SmartObjects
• To set rights on the Designer see Designer
• To set rights on workflow steps see Workflows - Step Authorization

You set rights on Service Types and Service Instances to allow people in your organization to view the item in Management and the Designer and use it in design time. The following table lists the Service Types and Service Instance objects and the corresponding rights that you can set. Keep in mind that View is a design time right and Create, Modify, and Delete are management rights.

Rights on Service Types and Service Instances

When defining rights on Service Types and Service Instances, first determine which roles can manage the Service Type and use it in a SmartObject, and assign the roles the Create and View right. You can use the Service Instances Security node, or the Service Types and Service Instances nodes in Management to do this.

Consider the following when assigning rights in the different nodes in Management:

• Service Instances Security - Serves as the root level from when rights are inherited and is useful where rights must apply 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.

While it is possible to give Users and Groups rights directly on Service Types and Service Instances, 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 in Management and the Designer	Service Types, Service Instances	Security Administrators
Create	Allows you to create Service Types and Service Instances for all Service Types in Management.	Service Instances Security level	Security Administrators
	Allows you to create a Service Instance from a Service Type in Management	Service Types level	Security Administrators
Modify	Allows you to update items in Management	Service Types, Service Instances	Security Administrators
Delete	Allows you to delete items in Management	Service Types, Service Instances	Security Administrators
Security	Allows you to give other people the right to assign rights on a specified item	Service Types, Service Instances	Person creating the object or Security Administrators

Permissions

Permissions are used to specify the behavior of rights on Service Types and Service Instances. 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.

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 hierarchy.
Inherited Allow	Implicitly grants the ability to perform the action based upon settings further up the hierarchy.
Inherited Deny	Implicitly prevents the ability to perform the action based upon settings further up the hierarchy. This permission cannot be changed.

You must have Security rights to assign Permissions. Members of the Security Administrators group and the creator of Service Types and Service Instances by default get Security rights. You can also assign Security rights to other roles as required.

About Inheritance

Inherited permissions are permissions passed down from the parent item to the child item, making it easier to manage permissions. You can break inheritance or turn inheritance back on if previously broken. By default, rights are inherited. See Rights on Service Types and Service Instances for more information about default inheritance.

Inheritance	Description
Break (Off)	Creates equivalent explicit rights based on the current inherited rights. Inheritance can be broken on any item.
Inherit (On)	When reactivating inheritance on an item, where a user, group or role exists on the parent item, 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 Service Type or Service Instance and retains its explicit permissions. The role, user, or group is not removed or rights reset based on the parent settings.

Setting Permissions

• To create roles see Management Site> Users> Roles
• To set Role permissions see Add Role Security
• To set Service Types and Service Instances rights see Service Instances Security, Service Types, Service Instances.

The Security Audit SmartObject allows a member of the Security Administrators role to execute the SmartObject and generate an audit log of all authorization framework security changes in your environment. For more information, see the Security Audit SmartObject topic.

• See the Before you begin topic and best practices section before you start assigning rights
• Security Administrators always have View, Create, Modify, Execute, Delete and Security 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 Package and Deployment role, must have View rights on all the objects in the package, and Modify rights on the source and destination categories. When you create a package that contains objects with explicit deny rights (View: Deny on the Artifact on the source environment), Package and Deployment prevents you from creating the package and lists all the denied objects. This is because Deny takes precedence over the Package and Deployment role. See the Permissions and Common Tasks topic for more information
• Deny takes precedence over all permission settings (except for Security Administrators role).
  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 to set the permissions to None. This ensures that access remains blocked. However, it is easier to grant permission in the future should this be necessary.
  Example:
  If you assign Deny permissions to the Everyone role on an object, there is no way to allow a user on that object as the Deny permission applies to everyone. Even if you assign Allow permissions to User A, User A is part of Everyone, and Everyone is denied, so User A is also denied.
  Best practice is to set the Everyone role permissions to None and then set permissions only for the exceptions.
• If you have no rights on views, forms, or the category in which they reside, you cannot run views and forms at runtime and you will receive an error
• Anonymous forms ignore configured permissions and use default execute permissions which are Inherited Allow
• If the Execute:Deny permission is set on a view, users included in the Execute:Deny permission who attempt to open the view (or a form that contains that view) will see an error like:
  "Form '[FormName]' could not be found. Ensure that the form exists, that it is checked in, and that you are authorized to run the form and its views"
  or
  "View [ViewName] could not be found. Ensure that the view exists, that it is checked in and that you are authorized to run the view."
  This error displays because you do not have the correct rights (Execute:Allow) to execute the view or the form (that contains the view) at runtime
  To enable the Detailed Error Message Details option in the error message, please contact Nintex Customer Central for assistance
• The security audit SmartObject only stores security changes set from the authorization framework.
• Service Types and Service Instances
  • Setting rights on Service Types and Service Instances do not affect the runtime execution of SmartObjects that consume any Service Instance and Service Type. The rights only apply to the management of these items and the ability to use it in the design of a SmartObject.
  • Setting rights on Service Types and Service Instances do not apply to working with SmartObjects. For example, denying View rights on a Service Type or Service Instance will not prevent you from viewing SmartObjects generated from that Service Instance. This is because SmartObjects have their own set of authorization permissions and can use multiple Service Instances.
  • When working with custom steps in the Workflow Designer, you need View rights on a Service Instance to select it from the custom step's Connection drop-down list.
  • When you activate a feature in the Features node of Management, you need View and Create rights on the relevant Service Type for that feature to activate the feature. Only Workflow Server Admin users can see the Features node.
  • It is not recommended to remove the Security Administrators role's security rights on the root Service Instances Security level as doing so can cause a lockout scenario if all other user rights are removed with no other security rights assigned.
  • Service Types exceptions - When you save a SmartObject or deploy a workflow in the Designer, the default child Service Instance is modified automatically. By default these Service Types have inheritance broken from the root Service Instances Security level.
    • In this instance, the following rights apply by default:
      • Workflow Server Admin users and Security Administrators role: Allowed all permissions.
      • Everyone role: View and Modify rights are allowed.
    • Due to the default rights allowing the Everyone role to modify the service types listed below, they are excluded from determining if a user is allowed to access the Management site. It is important to take care when changing the default rights as it can cause unintended rights errors in the Designer:
      • SmartBox - Denying modify rights prevents you from creating or modifying simple (SmartBox-based) SmartObjects.
      • Workflow Reporting - Denying modify rights prevents legacy designer workflows from being deployed when the "Create Workflow Reporting SmartObjects" option is selected.
      • Workflow Service - Denying modify rights prevents legacy designer workflows from being deployed when the "Create Workflow SmartObjects" option is selected.

1. Plan out your security category structure before configuring permissions
   Before you start configuring rights and security in 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 to set the permissions to None. This ensures that access remains blocked. However, it is easier to grant permission in the future should this be necessary.
   Example:
   If you assign Deny permissions to the Everyone role on an object, there is no way to allow a user on that object as the Deny permission applies to everyone. Even if you assign Allow permissions to User A, User A is part of Everyone, and Everyone is denied, so User A is also denied.
   Best practice is to set the Everyone role permissions to None and then set permissions only for the exceptions.
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.

8. Restrict view rights on forms
   If a form contains a view that has Execute:Deny rights at runtime the form displays an error at runtime because you do not have rights to execute the view. If a form contains a view that has View:Deny rights, you can still run the form and execute the view on the form in runtime. If you want users to see the form but not a specific view on that form at runtime, it is recommended to add a hide a view on the form rule action on the form initialize rule. If you don’t want users to execute a form or view at runtime, it is recommended that Execute: Deny rights be configured on the views and forms to deny access to certain users and groups.

9. Security Administrators role on Service Instances Security level
   It is not recommended to remove the Security Administrators role's security rights on the root Service Instances Security level as doing so can cause a lockout scenario if all other user rights are removed with no other security rights assigned.

10. Create rights on Service Instances Security level
    When granting rights on the Service Instances Security level (root level), those rights apply to all Service Types and Service Instances. Carefully consider granting Create rights on the root level, and only grant this right to the most trusted users. The ability to create Service Types is considered high risk as it registers a SmartObject broker assembly for consumption through SmartObjects. It is also possible to create more than one Service Type from the same SmartObject broker assembly, which means that any rights applied to the first Service Type no longer applies to the second Service Type.