Roles and permissions¶

Modelling what a user can do is done with the concepts or securables, roles and permissions.

Securables¶

A securable, in terms of the Sequel's security model, defines a resource or action that requires special authorization to be accessed or executed. There are mainly two types of securables: the built-in securables defined in the system, and securables created by the user. Built-in securables cannot be modified or deleted. Also, securables must be defined within an application.

Property	Description
Key	String. Unique Key. Required.
ApplicationKey	String. Application.Key where this scope is defined. Required
Name	String. Friendly name to refer the Securable. Required
Description	String. Provide details about the purpose of this securable. Optional.
IsSystem	Boolean. Flags if this securable is defined by the system or customized by the user. Required. System securables cannot be edited using the Security UI.
IsGlobal	Boolean. Flags if this securable is defined as global. Default value is false. Global securables can be assigned to roles of a different application.
IsCreateAllowed	Boolean. Indicates if action is allowed
CreateDescription	String. Description for action. Optional
IsReadAllowed	Boolean. Indicates if action is allowed
ReadDescription	String. Description for action. Optional
IsUpdateAllowed	Boolean. Indicates if action is allowed
UpdateDescription	String. Description for action. Optional
IsDeleteAllowed	Boolean. Indicates if action is allowed
DeleteDescription	String. Description for action. Optional

Securables are always associated to a specific application.

System's securables cannot be created, edited or deleted from the Security API and must be specially managed from the CLI import application (as we don't want the clients to change those configurations using the import tool).

Properties IsCreateAllowed, IsReadAllowed, IsUpdateAllowed and IsDeleteAllowed do not apply any extra logic and are used just for improving user experience during configuration.

Custom securable¶

Users can create its own securables (custom securable) and use it to customize functionalities; this will depend on each application customization level. As a sample, Workflow is highly customizable in terms of applying securables to workflows (steps, transitions,...). In other applications like this one, Security, it does not make sense to create custom securables as there are no options to protect resources with custom securables.

How to manage securables¶

Securables can be managed from the API resource \Authentication\Securables and also from Administration website (/applications/{ApplicationKey}/securables). Both offers the same functionality and are protected by securable Sec.Securable.

API¶

Administration site¶

Roles¶

A role describes a set of securables and actions over those securables. Users will be assigned to a role in order to define the effective permissions.

Roles can be part of a system configuration for an application.

All groups created by a user must be assigned to a specific application; for custom groups (not IsSystem) the Key must starts by the ApplicationKey+"."

Property	Description
Key	String. Unique Key (within the application) . Required.
ApplicationKey	String. Application.Key where this role is defined. Optional
Name	String. Friendly name to refer the role. Required
IsSystem	Boolean. Flags if this role is defined by the system or customized by the user. Required. System groups cannot be edited using the Security UI.

Also, a role is composed by a set of permissions.

Permissions¶

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. A permission allows to specify which CRUD actions (Create, Read, Update and Delete) are allowed over a specific securable for users assigned to a specific role.

Property	Description
Id	Integer. Unique id to refer the permission . Internal. Autogenerated
RoleKey	String. Role.Key where this permission is defined. Required
SecurableKey	String. Securable.Key which this permission is configuring. Required.
Create	Boolean. Create action is allowed. Required
Read	Boolean. Action is allowed. Required
Update	Boolean. Action is allowed. Required
Delete	Boolean. Action is allowed. Required

Same application rule¶

All roles belongs to an Application; we just can include permissions from the same application; with the exception of global securables that can be added to roles of a different application.

How to manage roles¶

Roles can be managed from the API resource \Authentication\Roles and also from Administration website (/applications/{ApplicationKey}/roles). Both offers the same functionality and are protected by securable Sec.Role.