How to restrict data access based on group?

[Bob_Leung]

I have a setup where:

• Organisations is a table with info such as “name, address” etc.
• User belong to one or more organisations
• Any users belonging to that organisation can edit the information of that org.
• Users outside of org cannot edit, but can view “some” fields.
• Other tables may have access based on which org the user is accessing as.

What’s the best way to achieve this?

My current implementation are as follows:

• In Organisations table, add relations “Users” - which defines which user belongs to this org.
• In tables I want provide access based on org, add a “ownerOrgId” column, which is the objectId of the Org.
• When something is added to these tables, set the ownerOrgId
• Add event handlers for these tables to first check the user’s org matches ownerOrgId before allowing them access.
• User profile page allows user to switch between orgs.

It’s quite an involved flow, so I am wondering if there are smarter ways of achieving this within Backendless.

Two things I looked at that I believe won’t fit the requirements above:

Custom API Keys
I recently “Custom API keys”, but upon review of the documentation and youtube explainer, I believe that a) it won’t know which org a user belongs to, b) like normal API keys, are not meant to be secure, so we can’t rely on it to protect sensitive data.

Security Roles
While this restricts access, there’s no way to determine if user is part of an org and therefore which record it can access.

[Volodymyr_Ialovyi]

Hello @Bob_Leung

The solution depends on how many records you have in the Organizations and Users tables, and how often these records change.

In my opinion, the best option would be to use standard tools, which are described on the Data Security page, namely:

@Bob_Leung

Any users belonging to that organisation can edit the information of that org.

Solution: [LAYER 1] ObjectACL for the user who makes the call section from Data Security page

@Bob_Leung

• Users outside of org cannot edit, but can view “some” fields.
• Other tables may have access based on which org the user is accessing as.

[LAYER 3] Table permissions for the user-defined roles section from Data Security page

• Add roles (Users-Security Roles-Add Role): org1, org2, …
• Assigning a Role to a User via console* or API:
  — user1 - org1+org2
  — user2 - org2+org3+org4
  …

@Bob_Leung

Users outside of org cannot edit, but can view “some” fields.

Using COLUMNS VISIBILITY:

@Bob_Leung

Other tables may have access based on which org the user is accessing as.

Solution: Other tables may have access based on which custom role (org1, org2,…) the user is accessing as.

Add event handlers (Category: Data Tables, Event: addRelation, Timing: after, Context: Organization + Category: Data Tables, Event: deleteRelation, Timing: after, Context: Organization) to change ObjectACL + RoletoUser.

* Role to a User via console:

Regards,
Volodymyr

[Bob_Leung]

Thanks Volodymyr - the issue I have with this solution then is that I will need many roles, since orgs are user defined and not a predetermined number.

Agree with you in using the standard tools, but I am not sure how I can make your suggested implementation work in my case.