Data Security

Data Service supports a very flexible security mechanism for restricting access to objects stored in Backendless. Security permissions apply to users and roles. A permission can either grant or reject an operation for a particular asset. In the context of Data Service, the asset is an object which your app can retrieve, update or delete.

Permissions can be granted or rejected globally, where they apply to all tables and all objects in the data store. Additionally, every table may have its own permission matrix and owner policy - a special instruction whether object owners can or cannot retrieve/update/delete the objects they 'own'. Finally, every object has its own Access Control List (ACL) which is a matrix of permissions for the operations applicable specifically to the object:

The security system is multi-layered. For any API call the system goes through several layers where each can trim the scope of the operations. The layered order of the decision making is important and consists of the following points of validation:

1. ObjectACL for the user who makes the call
2. Table permissions for the User account
3. Table permissions for the user-defined roles
4. Owner Policy
5. Table permissions for system-level roles
6. Global user-defined roles
7. Global system roles

Where:

• "User-defined roles" - roles created by the application developer.
• "System roles" - roles built into Backendless (AuthenticatedUser, NonAuthenticatedUser, SocialUser, ServerCodeUser, etc).

Consider the following guide which illustrates the decision making process:

Backend receives an API request to load data from a table (the Find operation). For the sake of the example, user's identity is "bob@backendless.com" and the user belongs to a custom role called "MyRole".

All objects in the table become candidates for the retrieval. Backendless goes through the security permissions layers to determine which objects must be included into the response.

1. [LAYER 1] ObjectACL for the user who makes the call.
   Backendless checks if there are any restrictions for the user account at the object level. Any object in the collection with ACL which rejects access to the user is excluded from the result. To see or modify the permissions for a particular object, click the 'lock' icon in the ACL column in the data browser in management console to see and manage Object ACL permissions for a specific object.
   
   
   
2. [LAYER 2] Table permissions for the User account.
   Every table in Backendless may have its own set of permissions for users and roles. At this point Backendless checks if the currently logged in user is allowed to run the current operation. For example, if the Find operation is denied for the user, no objects would be returned. To see the permissions for a user account in Backendless Console, select a table and click PERMISSIONS, then USER PERMISSIONS menu:
   
3. [LAYER 3] Table permissions for the user-defined roles.
   This step is identical to the one described above with the exception that is checks custom roles for the table. Since this guide reviews the decision making process for the Find operation, Backendless checks the column for Find. If any of the custom roles which the user belongs to deny access, the operation is rejected and no data is returned.
   
   
4. [LAYER 4] Owner Policy.
   When a new object is created in Backendless, the system automatically links it with the account of the user that made the call to save the object. You can see that information in the 'ownerId' column in any of your tables in the data browser.  With the association between objects and users (owners), Backendless provides a way to control whether users can get access to the data they created. This is done through a concept we call 'Owner Policy'. To navigate to Owner Policy, select a table in the data browser and click the PERMISSIONS menu. Click the OWNER POLICY menu item.
   Granting a permission for an operation in Owner Policy, guarantees that the objects owned by the current user will be allowed access for the specified operations. Denying a permission, takes out the 'owned' objects from the collection of candidate objects to return.
   
5. [LAYER 5] Table permissions for system roles.
   This step checks if any of the system-level roles reject the operation at the table level. An exception to this rule are API calls from business logic. In that case, if there is no authenticated user in the context of the call, Backendless assigns only the ServerCodeUser role. The NotAuthenticatedUser role is not assigned and thus is not checked.
   
6. [LAYER 6] Global custom roles.
   Global policy applies to all tables and objects. By default all table level permissions inherit from the global policy. You can configure in the console at: Users > Security Roles. Create a new role and click it to configure the permission matrix:
   
7. [LAYER 7] Global system roles.
   This layer allows verifying if any of the system-level roles reject the operation at the system level. By default system roles have the GRANT permission assigned, but it can be changed to DENY if required. All table level permissions inherit from the global policy.