About Roles¶
Application's user accounts can be mapped to roles using the API documented below. A Backendless backend contains some system roles and may include developer-defined roles. There several system roles available in all Backendless backends. These roles are automatically assigned to every user under various conditions. Each role can configured with global, container and asset permissions.
Core security roles are assigned based on user authentication status and whether the user logged in via "classic" backendless login or through a social network. These roles are:
| Security Role |
Assigned to user when an API request is made by: |
|---|---|
| NotAuthenticatedUser |
...a user who is not logged in. |
| AuthenticatedUser |
...a user who is logged in. |
| SocialUser |
...a user who is logged in via a social network (Facebook, Twitter, Google) |
| FacebookUser |
...a user who is logged in via Facebook |
| GooglePlusUser |
...a user who is logged in via Google |
| TwitterUser |
...a user who is logged in via Twitter |
Additionally the following roles are automatically assigned by Backendless to an API request when a corresponding secret API key is used. By configuring access permissions to these roles an application may allow to custom server-side code (ServerCodeUser role), but completely reject access to the client apps (all other roles).
| Security Role |
Role is assigned when API uses secret key: |
|---|---|
| ASUser |
ActionScript secret key |
| AndroidUser |
Android secret key |
| DotNetUser |
.NET secret key |
| IOSUser |
iOS secret key |
| JSUser |
JavaScript secret key |
| RestUser |
REST secret key |
| ServerCodeUser |
CodeRunner secret key |
Backendless assigns multiple security roles for the same API request. For example, an API request made from a JavaScript application where user is not logged will have the following roles assigned: NotAuthenticatedUser and JSUser.
When an API call originates from business logic (Java, JS or Codeless), Backendless assigns the ServerCodeUser role.
Important
Business logic is the only exception to the rule for assigning NotAuthenticatedUser and AuthenticatedUser roles. When business logic makes an API call and there is no authenticated user in the context of the call, Backendless assigns only the ServerCodeUser role. Otherwise, if there is an authenticated user, then both ServerCodeUser and AuthenticatedUser roles are assigned to the request.
Adding Roles¶
A developer-defined role can be added using Backendless Console:
- Login to Console and select an application.
- Click the Users icon.
- Click the Security and Permissions section.
- Click the Add Role button and enter a name for the role.
- Click OK to save the role.
Role Permissions¶
A role may have multiple permissions assigned to it. A permission may either allow (GRANT) or reject (DENY) an API operation. Every operation which can be restricted with a permission has a subject. For example, the subject of a Data Service operation is a data record. For the File Service operations, the subject is a file.
All permissions are organized into a hierarchy: The global permissions apply to everything in the system. They either allow (GRANT) or reject (DENY) an API operation without distinguishing the subject. For example, a global permission may reject the Data Service's find operations for the users in the NotAuthenticatedRole. As a result, any not-authenticated user will not be able to retrieve an object from any data table in the application.
The asset container permissions inherit from the global ones and apply to a specific asset container, such as a data table. These permissions are scoped to a specific container type. For example, you may reject the get operation on file directory /privatefiles/for the users in role X. As a result, any user who belongs to the role X will not be able to retrieve files from that directory.
Finally, the asset permissions inherit from the ones for the corresponding asset container (if they are available) or from the global set. For example, an asset permission may reject access to a specific data object for one role and grant access to the same object for another role.
The diagram below illustrates the permissions inheritance ladder:
Once a role is assigned to a user account, any permissions assigned to the role (either granting or denying an API operation) automatically apply to the operations executed by the application on behalf of the user.