Good day. Maybe a very stupid solution to my question. Lets say I have a multi-tenant app I create for the construction industry. So the app support different tenants. Business 1 buys the app using a monthly fee. Business 2 buys the app using a monthly fee. I give Business 1 one ADMIN person and the person will have the role of ADMIN. I limit the Users table in such a way that only ADMINs can register new users for their Business. I use a field that will register new users under Business 1. Let’s call the field “company” and set the value to Business 1. Every new User then gets registered with a field to identify which company.
Every business creates new projects in a Table called “projects”. I can create projects for different businesses in the same table. Same for Business 2.
So let’s say that for some reason the ADMIN person accidentally shares his details with a person that wants to cause damage. That person gets the credentials of the ADMIN person, creates his own version of the ADMIN app (he has the API Keys from decoding my app and can see my API calls) and starts creating users for different Businesses as he will have rights to register new Users in the table. OR another user with another role assigned are able to create projects in the projects table. His details get compromised by a malicious attacker and are now able to create projects for any business.
That ADMIN person has access now to the whole Users table and can then change the “company field” should he choose?
How can I secure this? Sorry if this is a stupid question. I am new to multi tenant apps.
Backendless Version (3.x / 6.x, Online / Managed / Pro )
Online
Client SDK (REST / Android / Objective-C / Swift / JS )
Console
Application ID
075F9883-1E98-6218-FFAC-FCEFBC95B000
Hello @Jack_Jenkins, welcome to our community!
One of the options is to prevent users with the “Admin” role from creating another users with the “Admin” role. For this purpose, I can suggest to use beforeCreate event handler.
For the “Projects” table, add beforeCreate/beforeUpdate handler too. It will check the updated row for a company and will check the request for the user’s company. If companies are not equal (user tries to change companyField column) - prevent the event by returning { short: true } object from the event handler. (Read more about Stop Event Processing)
This will protect the data of other companies, their projects and users from attempts to replace their data. However, if someone gained access to the admin’s account, he will still be able to change the data that are determined by his permissions - for example, create new users or delete the current ones, but these actions will be strictly limited by the company that is assigned to this admin. He will not be able to change his company or someone else’s company, create a new admin or delete the current one.
Regards,
Viktor
Thank you. I will look into this and ask again should I have problems. Thanks for the reply!
Are there any costs related to this service that can come and bite me later? The Event Handlers server side. I need to look also into column visibility, which I see is not included in the $25 plan (which I hoped I could start with).
Another thing…I see you support 2 factor authentication using Twilio. Is there a way for an Admin person to create a Twilio account on Backendless? I don’t want users registering themselves for this app. Their Admin must do so. Is there a way for me to get this functionality and have 2 factor authentication? Maybe I can use an event handler on the User table to do this. Will it fall under the SocialUser role when a user authenticates using Twilio? So maybe I can allow users to be created using Twilio themselves and then add a field in the User table to have them enabled for the system. Then only the Admin can change that field. Using an event handler so that when a user login I can check that field before allowing them into the app?
Hi Jack,
There are no hidden charges, everything related to pricing is documented on the pricing page. The limits related to Event Handlers are:
These limits can be eliminated with the following extension from the Marketplace:
Regarding your questions:
Creating a Twilio account should be done directly with Twilio.
Please clarify how 2-factor authentication is related to the ability of the admin to create user accounts? I see these as two separate functions.
The SocialUser role is assigned to an authenticated account that logged in via an OAuth2 login
Yes, this sounds like a reasonable approach.
Regards,
Mark
