Authorization Model¶

Overview¶

Authorization or access management for resources and data is a critical function for any organization that is using the Sequel's products. Role-based access control (RBAC) helps you manage who has access to resources and data, what they can do with those resources, and what data they have access to. Our RBAC system provides fine-grained access management.

Our RBAC system is mainly based on two concepts:

• Roles, is what someone can do with some resources.
• Groups, is what someone can do with some data. Groups defined the access control level (ACLs).

A permission is a pair of one role and one group; defining what a user can do, based on its role, with some data protected by access control defined by the groups. Although, all permissions are applied always for an specific group and role; there are no concept of highest permissions as permissions are always clearly specified.

Domain model¶

Under the authentication model we include all domain models required to manage the authorization process: securables, permission, roles, groups and user types.

Also, in this section we will cover aspects related to authorization like entities, membership sets, LDAP synchronization,...

API first¶

All models and actions described in authorization are API first, that means all possible actions and data is exposed through a Rest API. This API is used by the Administration website. The API is fully documented using OpenAPI 2.0 specs (aka Swagger).

Applications¶

Authorization configuration is organized by applications. Configurations of different applications cannot be mixed or related; this isolation of the application's configuration allows us to manage and organise better the configuration. In most of the cases, it does not make sense to relate data of different applications. There is a single exception, it is the data entries flagged as IsGlobal that is allowed to be referenced from data owned by other applications: this is useful for applications like Workflow, where the data managed in their process belongs to other application.

We can think on this segregation as a "multi-application" repository, where all data is stored together in the same "table", however the data is never shared between different applications.

Process like data exchange (import and export) exposes a lot of flexibility on moving authorization data for all applications or just for an specific application.

System configuration¶

There are some entities that models configurations provided by each application and we consider them as system configuration that cannot be modified by the users. Those models are: Group, Role, User Types and Securables. There are some business rules that we can infer from this relationship:

1. Instances flag as IsSystem=true are considered System configuration and cannot be edited. Creation of System instances is not allowed as well using the API.
2. All "System configurations" are linked to an application.