An assumption: a typical SaaS’s extra need for more role and permission-jockeying of tenants <-> users <-> restricted data than a typical app may mean that using 8base native auth might be the most flexible way to go? Valid?
We have built a couple of multi tenants applications on top of 8base, so we have a couple of lessons learned that we can share.
Regarding your question about authentication and authorization we use a combination of 8base permission engine with triggers on the mutations of the tables to make it happen:
Basically we use a Table of affiliation of users with the tenants, like @sebastian.scholl was explaining. Then the permission filters use those relationships to define a higher level of data that a user can “see”: READ, maybe UPDATE, maybe DELETE, maybe CREATE.
Higher measures of security and authorization policies are enforced via the before triggers. We make this functions loose enough to be used on wen applications and the triggers as well to avoid code duplicity.
I hope this may help, and feel free to ask any other question, happy to share what we have done, and possible alternatives to future scenarios.
Hey thanks much Alacret. OK so if I understand it:
Use custom 8base auth rules for tenants and their users for your various data tables a la that Sebastian post.
And before a user can perform any graphql mutation like create, update or delete, you use an 8base “trigger.before” to fire an additional auth function: “Is this person allowed to do what they are about to do? If yes, proceed. If not, give error.”
Keep in mind that I think most of the rules can be built in the 8base permission engine, just we choose to write them in Javascript because we also need it them in the frontend.
I’m also building a multi-tenant architecture with 8base and I’m still trying to figure things out. Did you say something was on the way to help with it @sebastian.scholl or is it still in a far future?