Roles and policy

Below is a diagram that shows relationship between users, roles and policies.

A user can have multiple roles of two distinct types: resource and row-level.

Resource roles give users permissions to specific objects and operations, that are denied by default. A user without resource roles has no permissions and cannot access the system.

Row-level roles, in contrast, restrict access to particular entity instances. A user without row-level roles has access to all instances of an entity (if it is permitted by resource roles).

Each role can define policies of different types. Policies specify a target object (a resource for resource permissions, an entity instance or group of instances for row-level policies) and a permission or restriction to apply to this object.

Role granularity

A resource role can have any number of policies, and a user can have any number of roles. So you can design roles with different levels of granularity:

Fine-grained roles define permissions to closely related resources like an entity, its UI views and menu items. For example, "Full access to Customers", "Can create and update Orders". You would normally assign several such roles to the user.

Coarse-grained roles define all permissions required for a specific job, like "Salesperson". Such a role can define all permissions itself or inherit them from child roles, so a course-grained role can be made as an aggregation of fine-grained ones.

We recommend creating fine-grained roles at design time and using runtime capabilities only for combining them into different coarse-grained roles for simple assignment to users, and for rare ad-hoc changes in your security model.

Row-level roles

Row-level roles allow you to restrict access to particular rows of data, in other words to entity instances. A user without resource roles has no permissions and cannot access the application’s data and UI.

Menu path: System admin > Security > Row-level roles

Inteacc ERP system has easily configurable access control mechanism. It is based on Spring Security and adds the following features

1. Integration with your data model.

• Permissions to invoke CRUD operations on entities and to view/modify specific entity attributes. For example, a user can view documents, but cannot create, update, or delete them, and can view all document attributes except amount.
• Row-level access control restricts access to individual entity instances. For example, users can view documents that have been created in their department only.

2. Integration with UI.

• Permissions to open UI views and see main menu items.
• If a visual component like Text Field is bound to an entity attribute, it automatically becomes read-only or hidden depending on the current user rights to the attribute. Table actions are disabled if the corresponding CRUD operations are denied for the user.

3. Declarative definition of roles and permissions using annotated Java interfaces.
4. Ability to define roles and permissions at runtime and store them in the database.
5. User interface for viewing roles and permissions, assigning roles to users, and for creating runtime roles.

How to

Consider the following rules when writing JPQL policies:

Use {E} placeholder instead of the entity alias in where and join clauses. The framework will replace it with a real alias specified in the query.

The where text is added to the where query clause using and condition. Adding the where word is not needed, as it will be added automatically.

The join text is added to the from query clause. It should begin with a comma, join or left join.

The following screen-shot exhibits, when the row-level security is maintained for the Entity (table) CashAccount, then only declared rows are allowed access to the user assigned with this row-level role.

Use join when more than one Entity (Table) is joined to enforce the role.

The "Check syntax" button helps check if there is any error in writing the JPQL query condition.