Security and User 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:

permission-inheritance

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.

Retrieving Available User Roles¶

This operation returns a list of the roles associated with the user account currently logged in to the Backendless application. If the request is sent without logging in, the system will return only one role - NotAuthenticatedUser.

Non-blocking Method 1: With the Callback

public void Backendless.UserService.GetUserRoles( AsyncCallback<IList<string>> callback )

Non-blocking Method 2:

public async Task<IList<string>> IList<String> userRoles = await Backendless.UserService.GetUserRolesAsync();

Blocking API

public List<String> Backendless.UserService.GetUserRoles();

where

Argument	Description
`callback`	an object which is notified when the server returns a list of user roles or an error.

Examples¶

Non-blocking Method 1: With the Callback

Backendless.UserService.Login("YourEmail@gmail.com", "123234");
        Backendless.UserService.GetUserRoles(new AsyncCallback<IList<string>>(
            response =>
            {
                foreach (string role in response)
                {
                    Debug.Log($"UserRole: {role}\n");
                }
            },
            fault =>
            {
                throw new BackendlessException(fault);
            }
        ));

Non-blocking Method 2:

Backendless.UserService.Login("YourEmail@gmail.com", "123234");
IList<String> userRoles = await Backendless.UserService.GetUserRolesAsync();

foreach (String role in userRoles)
  Console.WriteLine($"User role: {role}");

Blocking API¶

static void GetUserRoles() 
{ 
  Backendless.UserService.Login("YourEmail@gmail.com", "123234");
  IList<String> userRoles = Backendless.UserService.GetUserRoles(); 

  foreach( String roleName in userRoles ) 
    System.Console.WriteLine( roleName ); 
}

When retrieving available roles without logging in, the server returns only one role - NotAuthenticatedUser.

Retrieving Users By Role¶

This operation works only with custom roles, otherwise an error message will be returned in response body. By invoking the getUsersByRole method, a client sends a request to the server which returns a response body with an array of users found by a specific role.

Non-blocking Method 1: With the Callback

public void Backendless.UserService.FindByRole( String roleName, Boolean loadRoles, DataQueryBuilder queryBuilder, AsyncCallback<IList<BackendlessUser>> callback )

where

Argument	Description
`roleName`	is a string name of a particular role.
`loadRoles`	is an optional boolean parameter that can be true/false.
`query`	an optional parameter that can be a plain object or an instance of `Backendless.DataQueryBuilder`. The returned list of users will satisfy the query.

Here is a detailed explanation of the parameters that can be used in the queryobject:

where

Argument	Description
`pageSize`	sets the page size - which is the number of objects to return in the response. Maximum value is 100.
`offset`	sets the offset - an index in the server-side storage from where the data objects should be retrieved.
`properties`	sets the names of the properties which values must be retrieved from the server.
`excludeProps`	column names that should be excluded from a query.
`where`	sets a search query. A query must be in the SQL-92 syntax (the "where" clause part).
`having`	used with Aggregate Functions. Sets a condition on a aggregate function to filter groups.
`sortBy`	sets an array of column names to sort the data objects in the response by.
`groupBy`	used with Aggregate Functions. Sets the name of a column to group the results by.
`relations`	sets an array of related columns names. Objects from the related columns are included into the response.
`relationsDepth`	sets the number of "levels" in the hierarchy of related objects to include into the response.
`relationsPageSize`	A number of relation objects returned in response body.
`fileReferencePrefix`	when FILE_REFERENCE column is in the table, then fileReferencePrefix can be used to change the initial link to a file. For instance, a user can replace the current base path, to their custom domain where a file is stored, without updating any data in the table.

Non-blocking Method 2:

public async Task<IList<BackendlessUser>> Backendless.UserService.FindByRoleAsync( String roleName, Boolean loadRoles, DataQueryBuilder queryBuilder )

Blocking API

public IList<BackendlessUser> Backendless.UserService.FindByRole( String roleName, Boolean loadRoles, DataQueryBuilder queryBuilder )

Examples¶

Non-Blocking Method 1: With the Callback

Backendless.UserService.FindByRole(roleName, loadRoles, queryBuilder, new AsyncCallback<IList<BackendlessUser>>(
  result =>
  {
    foreach (BackendlessUser user in result)
      Console.WriteLine(user.Email); // work with all users who have the specified role.
  },
  fault =>
  {
    Console.WriteLine($"server reported an error: {fault.Message}");
  }
));

Non-Blocking Method 2:

var result = await Backendless.UserService.FindByRoleAsync(roleName, loadRoles, queryBuilder);

foreach (BackendlessUser user in result)
        Console.WriteLine(user.Email); // work with all users who have the specified role.

Blocking API

var result = Backendless.UserService.FindByRole(roleName, loadRoles, queryBuilder);

foreach (BackendlessUser user in result)
        Console.WriteLine(user.Email); // works with all users who have a specific role.

Retrieving User Roles By User ID¶

This method can be used both for custom and system roles and returns an array of all available user roles.

Assigning a Role to a User¶

This operation is available only from Custom Business Logic. Applications must use the "Code Runner API key" in order for the API call to be accepted on the server. The reason for this restriction is that a malicious use of this API can easily compromise application's security. As a result, this API must be used from a controlled environment.

Non-blocking Method 1: With the Callback

public void AssignRole( string identity, string roleName, AsyncCallback<object> callback )

where:

Argument	Description
`identity`	a value for a user property marked as identity.
`roleName`	the name of the role to assign to the user.
`callback`	an object which receives either a return value or an error from the server.

Non-blocking Method 2:

public async Task AssignRoleAsync( string identity, string roleName )

Blocking API

public void AssignRole( string identity, string roleName )

Examples:

Non-Blocking Method 1: With the Callback

Backendless.UserService.AssignRole(identity, roleName, new AsyncCallback<object>(
            resp =>
            {
                Debug.Log("SUCCESSFULL");
            },
            fault =>
            {
                Debug.Log($"Error: {fault.Message}");
            }
        ));

Non-Blocking Method 2:

await Backendless.UserService.AssignRoleAsync(identity, roleName);
Console.WriteLine("Successful");

Blocking API

Backendless.UserService.AssignRole(identity, roleName);
Console.WriteLine("Successful");

Unassigning a Role from a User¶

This operation is available only from Custom Business Logic. Applications must use the "Code Runner API key" in order for the API call to be accepted on the server. The reason for this restriction is that a malicious use of this API can easily compromise application's security. As a result, this API must be used from a controlled environment.

Non-blocking Method 1: With the Callback

public void UnassignRole( string identity, string roleName, AsyncCallback<object> callback )

where:

Argument	Description
`identity`	a value for a user property marked as identity.
`roleName`	the name of the role to assign to the user.
`callback`	an object which receives either a return value or an error from the server.

Non-blocking Method 2

public async Task UnassignRoleAsync( string identity, string roleName )

Blocking API

public void UnassignRole( string identity, string roleName )

Examples¶

Non-Blocking Method 1: With the Callback

Backendless.UserService.UnassignRole(identity, roleName, new AsyncCallback<object>(
            resp =>
            {
                Debug.Log("SUCCESSFULL");
            },
            fault =>
            {
                Debug.Log($"Error: {fault.Message}");
            }
        ));

Non-Blocking Method 2:

await Backendless.UserService.UnassignRoleAsync(identity, roleName);
Console.WriteLine("Successful");

Blocking API

Backendless.UserService.UnassignRole(identity, roleName);
Console.WriteLine("Successful");

Errors¶

The following errors may occur during the API calls described above. See the Error Handling section for details on how to retrieve the error code when the server returns an error.

Error Code	Description
2002	Version is disabled or provided wrong application info (application id or secret key)
2005	Could not find role.
3038	One of the required parameters (user identity or roleName) is null.
3057	Could not find user by id or identity.
3058	Could not assign role to user.
3059	Could not unassign role to user.