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.