Authorization Framework Overview

To protect your applications from unauthorized use or unauthorized modification, you may want to control or restrict access to certain application elements (e.g. Forms, Views, SmartObjects, Service Types, and Service Instances) or Categories in your environment. The Authorization Framework allows you to do this, by configuring various levels of rights on elements in your environment. Use this topic to become familiar with the Authorization Framework, the features of the framework, and best practices to use the framework to secure your applications.

On a high level, you can think of the authorization framework as a collection of Roles (people) that have certain rights on Objects (Categories, Views, Forms, SmartObjects) and Service Types and Service Instances in an environment. You can control access to different roles by configuring security on a role, and control access to objects, Service Types, and Service Instances by assigning rights to a role to interact with objects, Service Types, and Service Instances. Permissions are used to define explicit authorization, and inheritance/overrides.

Let’s use an example: suppose that you have a Category called “Human Resources” in your organization, which contains various Forms and Views used in HR applications. You may want to give the “HR App Builders” Role the View, Create, Modify and Delete rights on the “Human Resources” Category so that users in this role can see, create, edit and delete items within that category when they are using the Designer to build applications. Then, you may want to give the “HR Administrators” Role the Execute right on the “Human Resources” Category so that users in the “HR Administrators” role can see and run the Views and Forms stored in the “Human Resources” category at runtime.

Consider the diagram below, which explains the relationships between components of the Authorization Framework. The blue boxes represent Roles and the rights that users might have to administer Roles. (Note that the membership of a Role could include Users and Groups). The Security defined on a Role determines who is able to modify the membership of a particular Role, and who may delete a particular Role. The green boxes represent the objects, Service Types, and Service Instances where you can set Rights. Objects that you can protect by applying Rights include Categories, Views, Forms and SmartObjects. You can set View (this is a design-time right that controls who may view those items in the Designer), Create (this is a design-time right that controls who can create artifacts such as categories (folders), SmartObjects, Views, and Forms in the Designer), Modify (this is a design-time right that controls who can edit, rename and move objects in the Designer), Execute (this is a runtime right that determines who can run that object, or the items contained in that category) and Delete (this is a design-time right that controls who can delete objects in the Designer and Management) rights. You can also protect Service Types and Service Instances by applying rights. You can set View (this is a design-time right that controls who may view those items in Management and the Designer), Create (this is a management right that controls who can create Service Types and Service Instances in Management), Modify (this is a management right that controls who can edit Service Types and Service Instances, and refresh Service Instances in Management), and Delete (this is a management right that controls who can delete Service Types and Service Instances in the Management) rights. As the creator of objects,Service Types, and Service Instances you can assign Security rights to them, which allows others to manage the item's security, including assigning View, Create, Modify, Execute, Delete and Security rights.


See Considerations and Best practices for managing security permissions before you start assigning rights.

 

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.

Default Roles
Role Description
Security Administrators
  • Any person needing to assign permissions to objects must be a member of this role
  • Members of this role always have View rights on Objects and Modify and Delete rights on roles ensuring that they can never be locked out of any object in the system
  • The Security Administrators role does not display when clicking on the security button in Management Site > Roles, because this role’s security cannot be edited
  • Created at installation and automatically includes the admin account specified in the installer.
  • Security Administrators can modify the membership of the role but cannot delete it
  • There must always be at least one user in this role
  • The role can contain users and groups

  • Default permissions for the Security Administrators role are Create, Modify, View, Execute, Delete or Security rights. The modify and delete rights are assigned on roles, while all rights are assigned on objects such as SmartObjects.
Package and Deployment
  • Members of the Package and Deployment role have view and modify rights to all objects in the system. This allows them to package and deploy objects.
  • Any person in this role needs modify rights on the objects that need to be overwritten during deployment.
  • Any person needing to package or deploy solutions must be a member of this role.
  • If a person in the Package and Deployment role has been denied view rights to a specific object, they will see an error message during packaging or deployment.

  • If a person in the Package and Deployment role has been denied modify rights to any category in the SharePoint 2013 sub-tree, they will see an error on deployment after selecting the package and pressing the OK button. This is because the SharePoint name inference process may have to move objects after creating them if they are deployed to a different site collection or environment.

  • Default permissions for the Package and Deployment role is View, Create and Modify rights assigned on objects such as SmartObjects.
Everyone
  • The Everyone role contains all authenticated users for all security labels on the system
  • This role is created during installation
  • This role cannot be modified or deleted
  • The role cannot be deleted
  • Anonymous users are not included in the role
  • Default permissions for the Everyone role are View, Create, Modify, Execute, and Delete rights. The modify and delete rights are assigned on roles, while view, and execute rights are assigned on objects such as SmartObjects. Create rights are assigned to Categories (Allows a user, group or role to create category folders and artifacts in a category)
  • At installation, the Everyone role is added by default to all objects with View, Modify and Delete rights.

  • Service types and service instances - When specifying users, groups, and roles, the Everyone role is added during installation, providing all authenticated users, the ability to view service types and service instances. Best practice would be to modify the Everyone role's view rights to None on the Service Instances Security level, and grant permissions to users, groups, and roles according to your organizations requirement on the service type and service instance.

Security Rights on Roles

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

Right Description Applies To Assigned by
Modify Allows you to add and remove users and groups to a role and the change the description of a role. Roles Role Creator or Security Administrators
Delete Allows you to delete the role Roles Role Creator or Security Administrators
Security Allows you to assign rights to a role Roles Role Creator or Security Administrators

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.

Objects Rights
Forms

View
Modify
Execute
Delete
Security
Views View
Modify
Execute
Delete
Security
SmartObjects View
Modify
Delete
Security
Categories

View
Create
Modify
Execute
Delete
Security
Workspace (Mobile) Apps (Forms) Execute
Workspace (Desktop) (My Forms) Execute
Package and Deployment View (must use Package and Deployment role and have View rights on all objects that will be packaged)
Create (used during deployment of a package, users in the Package and Deployment role get create rights)
Modify (for deployment you must have Modify rights when creating new versions of deployed objects. If deploying SharePoint objects, Modify rights are required on all categories under the SharePoint 2013 Folder in the category tree)
Designer View
Security
Workflow Steps View
Security

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

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 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

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.

Objects Rights
Service Instances Security

View
Create
Modify
Delete
Security
Service Types View
Create
Modify
Delete
Security
Service Instance View
Modify
Delete
Security

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 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

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, edit the <add name="ExtendedExceptionDetail" value="false" /> to true in the SmartForms Runtime Web.config file in the following location: [Drive]:\Program Files (x86)\K2\K2 smartforms Runtime
  • 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.

Related Topics