An app's authorization domain describes and controls what a user is allowed to do in an app.
Imagine allows you to represent your app's Authorization rules using the following structure and syntax:
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:
There are no settings currently required for the authorization domain.
We will describe the various elements in each module in detail below.
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:
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
In the example below, can-make-payment and can-publish-album are
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:
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
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