Evaluating… security features

General
1

We are considering transitioning from another backend service for our web app. As the app grows, it’s becoming more difficult to manage security and building new modules due to a lack of robust security features.

I have a few questions that I have not been able to figure out from the videos or missions. I hope this is the right place to ask… if not, just let me know.

How do we handle setting up the security for object level roles? For example:

Users = {id, name, role}
Project = { Id, name, commission, dueDate }
UsersToProjects = { id, person, project, role, lastAccessed }

Two possible choices for UsersToProjects.role are Project-Manager and Contractor.

Project-Manager can CRUD all fields in their Projects.
Contractor can view Project.name and Project.dueDate
Anonymous users can view any Project.name and create projects assigned to a user

I understand the global roles, But how do we handle these types of row/column level roles for individual objects?

I’m asking specifically about how to handle the security setup. I understand how to get the data and sql, but want to make sure for instance that a contractor never knows the commission of a project they are assigned to. But that same contractor could be a project manager on another project.

2

Hello @Kevin_Wasie!

Welcome to our community and thank you for trying out Backendless!

An individual database table may have its own set of permissions for the same roles.
Each individual object in a data table may also have its own permissions for each role.

In this scheme you can see how the security hierarchy is represented:

image
image1265×720 121 KB

I also recommend that you check the information available at these links, I think it will be useful to you:

If you have any more questions, we will be happy to answer them.

Regards,
Alexander

3

Thank you for the resources, @Alexander_Pavelko.

I’ll jump into those.

4

You’re welcome.

Here are some more helpful videos on the subject:
About User Roles for Data Security
How to create a custom security role in Backendless
How to assign a custom security role to a user account in Backendless
How security permissions impact the behavior of APIs

Regards,
Alexander

5

@Alexander_Pavelko Took a look at those, and still unable to get an answer … I’m not trying to define system level roles. I want to set up roles for individual records on a many-to-many basis. Can we use backendless to create some type of security policy for this?

Example:
Users = { id, name }
Projects = { id, name, commission, due_date }
Users_To_Projects = { id, project_id, user_id, role }

There are several system roles such as: Account_Admin, Employee, Subscription_Manager.

Each user can have different roles on different projects, such as Project Manager, Contractor, Designer

Project Managers have full CRUD on all of their projects
Contractors can only view Project.due_date and Project.Name for projects that they have access to through Users.To_Projects

We need to be able to write policies such that,

By visiting /data/projects, the user only a) receives their projects that they are assigned to in Users_To_Projects, and b) only has the permissions based on their Project_To_user.role

We cannot use ownerId because there are many people that have access to the individual records.

I suppose we could set object/record level permissions on Create, Update, and Delete for each user, but that would be burdensome. We want to just create a policy once, and have it in place.

We also could create a new role for each object, but we would end up with 1000000+ roles which does not make sense.

Also, does backendless offer office hours or some other version of live support/evaluation call?

6

Hi Kevin,

You described access rules for Project Managers and Contractors:

What are the rules for other role types?

I believe the best approach here would be an intermediary data access layer in the form of an API service. With the built-in security model in Backendless, it would be hard to enforce security policy given that you have a table (Users_To_Projects) that overrides (or defines) the user’s role as it pertains to different projects.

Regards,
Mark

7

@mark-piller Thanks for the response …

I was using the project management example to make it easier to communicate… Our app actually manages real estate offers, transactions and escrows, with several (10+) parties dealing with financial data that is private to each party, but part of each individual record. Sometimes a user can be one role, other times they may be another (buyer, seller, sellers_real_estate_agent, buyers_real_estate_agent, loan_officer, etc.)

I believe the best approach here would be an intermediary data access layer in the form of an API service.

This makes sense. To understand more … so basically, we would use the backendless DB and API’s as normal, and build a API service that sits in front of the API to scrub the data for what is allowed for each role, and checks the role for authority to complete a certain function?

8

Yes, that’s correct. There are several benefits to this approach. One of them is you can completely hide direct access to the database API for the client side. As a result, any additional data processing can be shifted to the server-side and by doing so the client logic is simplified. Additionally, if the majority of the business logic is concentrated in your API services, you get the additional benefit of rolling out changes in the app without requiring users to update the client.

Out of curiosity, a user who may be in different roles, do they need to re-login to get a different role or would the credentials remain the same and it is the workflow in the app that determines their role?

Regards,
Mark

9

Thank you @mark-piller

Users remain logged in, but have access to different functions/data based on their role for the object they are in.

For instance

  • We need to display a list of all of the properties to anonymous users. This is done with /anonymous/properties … this just gives an address, a photo and an id

  • Logged in users receive their properties at /dashboard/properties …showing any properties that they are a part of at Users_To_Properties, regardless of role.

  • The details page of the property is where it gets ugly… we are scrubbing the data in the API endpoint. For instance, if a user has role buyers_real_estate_agent, we remove the data that is private to other roles such as seller.

  • managing functions on the UI is simple because we just do conditional displays based on their role. For instance, if they are a Buyer, they cannot edit so the edit button is not displayed. The update endpoint test for authorization based on the supplied id and their role with that property.

Your approach with a DAL is what we are looking for because what we are doing now in the endpoints is messy and hard to manage with any changes. Bound to be data leak as the app grows.

Further question … would a scenario like the following also require a DAL? …

A task/to do app with many users that allows users to comment on a task. The comments can be marked as comment.published=true/false. If comment.published is marked as true, all users can see it on /task/{id}/comments

if comment.published is marked as false, it is only visible to the owner.

10

Yes, it would require a DAL. Here’s why:
The built-in security system bases its grant/deny decision on 3 components:

  1. Principal (who the user is, their roles)
  2. Action (what API function they are performing - i.e. Read, Write, Update, Delete)
  3. Subject (the asset on which the Action is performed by the Principal. These are tables, or individual data records, files, etc).

In the scenario you described, there is a 4th component, which is the state of the data itself (the state of a comment is either published or not). As a result, there would have to be separate logic that makes the determination if the user can or cannot access the data.

Regards,
Mark