Security (16 posts)

In my previous post I described how to adjust object’s access control list (ACL) using Backendless console. As I mentioned, in addition to console, object’s permissions can be controlled using API. In fact, for any persisted object, Backendless supports the following capabilities:

granting/rejecting permission to execute find/save/update/delete operation on an object to:

• a user
• a role
• all users
• all roles

The general API usage pattern is:

Where <OPERATION> can be FIND , UPDATE , REMOVE. There are many more methods available on the <OPERATION> class supporting all the combinations listed above.

Every data objects saved in Backendless has its own access control list (ACL). Object’s ACL includes permissions for users and roles for all Data service operations. Using ACL an application may be configured to allow users (and/or roles they belong to) to be able to execute Data Service API calls. For example, in a shopping app you may have the Customer and SupportRep roles. Users in the Customer role may have the permission to create and update objects in the Incident table, but may not delete them. A user in the SupportRep role may have the permission to delete those objects.

Object ACL configuration can be done via API or Backendless console. This post review the latter. To get to the ACL screen for a specific object:

1. Login to Backendless console, select your app and click the Data icon.
2. Select the table to get to the data object you need to modify the ACL of.
3. Click the “key” icon in the ACL column:
   
4. Select Users Permissions or Roles Permissions In the ACL screen.
5. Adjust the permissions for the roles and/or users as you see fit. A permission can be adjusted by clicking an icon at the intersection of a row representing user or role and a column which represents an operation. For example the following screenshot restricts access to an object for any not-authenticated user and does not allow users in the Customer role to delete the object:
   

This may apply only to some apps, especially if your license agreement explicitly prohibits users from specific countries, or if perhaps you want to allow users only from a specific country. The feature lets you select the countries where users would not be allowed to consume the backend of your app. The feature relies on geo-decoding user’s IP address and we do our best to maintain the mapping between the IP addresses and the countries they are assigned to. If a country is selected as one where the APIs for your app should not be allowed, then any request a user from that country makes would be rejected. To configure geography-based restrictions:

In the previous post I described how to obtain file’s public URL using the Backendless developer console. Even though one may obtain a public URL for a file or directory, it is very easy to change the permissions to restrict file download for anonymous (not authenticated) users. To restrict access:

1. Login to the Backendless developer console, select an app and click the Files icon.
2. Navigate to the file or directory for which public access should be denied.
3. Click the lock icon to switch to the Security screen.
4. Click the Roles Permissions menu.
5. Click the checkmark icon in the cell at the intersection of the row for NotAuthenticatedUser and the Read column until you get a red X icon as shown in the screenshot below:
   Continue reading

A user on StackOverflow asked how to load only the data which belongs to the currently logged in user. Although if you read the question it may sound like something else, this is how I understood it. This is indeed an interesting and very common use-case. Backendless (IMHO) handles it beautifully and this feature certainly deserves a place in this feature-a-day series.

What you need to know before we get to the coding sample part is:

• How to register a user in Backendless
• How to login a user into Backendless
• How to save objects in Backendless with API and management console

Loading data objects which belong to a user does not require any specialized APIs. In fact exactly the same Backendless API you’d use to load objects from the server should be used. The trick is in setting up the security policy to restrict users from accessing data objects and letting Backendless to fall back to what we call the Owner Policy.

The use-case for updating a user account is rather frequent. Either the user herself or the admin may need to update user properties. Backendless provides the API for updating user accounts, although app admins/developers can do it using Backendless console as well. The code below demonstrates the API for updating a user:

It has happened to a lot of people, especially with the online banking applications – you try logging in a couple of times and get your password wrong. Then the screen changes saying the account is locked out and you need to try again in XX minutes. If this is the behavior you would like your app to have, it could not be easier to set up with Backendless:

1. Login to console, select your app and click the Users icon.
2. Click the Login menu.
3. You will see two sections on the screen: Lock User Account and Unlock User Account:
   
4. The Lock User Account controls how many unsuccessful logins would be tolerated by the backend before the account is locked out. Use the slider to adjust the value. There is also an option to allow unlimited unsuccessful logins.
5. The Unlock User Account controls the amount of time a user has to wait before the account is unlocked and the user can try logging in again.

Can you think of an easier way to configure it? ) Enjoy!

In my previous posts I wrote how to create developer-defined security roles and how to secure data table access for a security role. Ultimately when a client application makes API requests, the security evolves around users, since it is a user who authenticates himself against the system. A user may have roles assigned to him or her and in that case any permissions granted (or denied) to a role would be applicable to the user as well. In this article I will review how to assign roles to users using Backendless console. Keep in mind that these assignments can also be done using API and I will be writing another article in this series on that feature as well.

The instructions below assume you already have some users registered for your app or created using console. Also, you need to have at least one custom security role. To assign roles to users:

1. Login to Backendless console, select an app and click the Data icon.
2. The Users table should be selected by default. Click the checkboxes for each user object for which you would like to assign roles.
3. Click the User Roles button in the button toolbar.
4. Console displays the User Role Management popup. Using the popup you can assign available custom roles to the selected users. Click the checkboxes for the roles to assign and click the Save button.

The same User Role Management popup can be used to edit role to user assignments. The dialog is smart enough to handle multiple user selection and will properly display conflicting assignments using the three-state checkbox.

In one of my previous posts I described how to restrict access to all data for “guest” users. The Backendless security model lets you control access to data tables, or more generally “asset containers”, at the role and operation levels. That means an application developer can set up security restrictions for API operations on a specific data table for a security role. For example, a job/resume search application may have two application roles: Employer and JobSeeker. Suppose there is a table called JobListing which contains job listing objects submitted by the users in the Employer role. Actions permitted on the table for the JobSeeker role may look like these:

Applications use the Backendless API to access data, run searches, store, update and delete objects in the database. When a user authenticates himself with the backend, all subsequent API calls are executed on the behalf of the logged in user. However, if an API call is made without an authenticated user in the session, it is associated with an anonymous user. As a result, in an application that does not restrict data access, the data is exposed to everyone.

Restricting access for anonymous (non-authenticated) users is a very straight-forward process. Application developer has multiple options ranging from denying access globally for all API calls to restriction at the data table-level or even at the specific object level. In this article I review the process for restricting access globally.