Authorization
An app's authorization domain describes and controls what a user is allowed to do in an app.
Syntax overview
Imagine allows you to represent your app's Authorization rules using the following structure and syntax:
Example
As an example of Authorization in an app, let's take the music app, Musica, that has a few different types of user roles, each with certain permissions in the app:
- A Musician who can add a new song to the album
- A Producer who can pay a musician
- A Director who can publish an album and add a new musician
In this example, the above roles and permissions together define the authorization rules for the app
Representation in Imagine syntax
The Musica app's authorization would be represented in Imagine's syntax as follows:
Settings
There are no settings currently required for the authorization domain.
Domain-specific syntax
Imagine's Domain-specific syntax for the authorization domain supports two main modules: Permission and Role.
We will describe the various elements in each module in detail below.
Permission
The Permission module allows you to define what access is required for various functionalities in your app.
In case of backend, the Permissions defines what access is needed to be able to call a particular API endpoint.
In case of frontend, this would define what access is needed to be able to go to a particualr url in the app.
The elements of the Role module are as follows:
permission-name
Each Permission is followed by a unique user-selected permission-name to describe the permission you are trying to allow in the app. Please see this for rules on selecting a permission-name.
In the example below, can-make-payment and can-publish-album are permission-names
Role
The Roles module allows you to define a user role in your app. An app could have various types of users each of whom have different roles in the app.
Each Role gives a user certain Permissions which in turn allow them to access various functionalities within the app.
The various elements of the Role module are as follows:
role-name
Each Role is followed by a list of unique user-selected role-name to define the role you are trying to allow in the app. Please see this for rules on selecting a role-name.
role-related-permission
In addition to a role-name, each Role includes one or more <role-related-permissions> - these are basically the subset of <permission-names> that are relevant for that Role.
In the example below, producer and director are role-names, while can-make-payment and can-publish-album are <role-related-permissions>.