multi tenant using firebase auth??

[Colin Cannon]

I love the ease of using firebase auth and how quickly I can get a project up and running using firestore and firebase functions.  In the not so distant past I used to create a linux instance and build mysql and use php.  Firebase makes everything so much easier and less stressful.  With that said, I have recently run into an architecture problem that is giving me problems. 

I am creating an abstract application that each company can customize to an extent and they will have their own users. 

Problem 1:  I want to use firebase auth, but each company will have their own users and it is possible that a user can create an account with multiple companies.  I am not worried about security rules or data structure, what worries me is what happens when a user already has an account with one company, and then they go to another company and try to create an account.  To the user the companies are unrelated, but unknown to them the already have a firebase user that was created from a previous company.

Potential Solution:  I am still waiting to hear from firebase help, but I was planning to use the firebase project API to spin up new firebase projects when a new company is formed, so they will have their own project and users.  I plan on using google app engine or perhaps firebase hosting to host my application, but I also want to user firebase functions to control logic and interact with the firestore.  If I am able to programmatically spin up a new firebase project when a new company signs up, will I have to somehow upload the firebase functions to that project or can I somehow reference the same firebase functions across multiple projects?

[Kato Richardson]

Hi Colin,

A new project per company is one way to go here. Keep in mind that there is a limit on the number of projects you can create programmatically for a given account. It's not a fixed limit and is based on some abuse logic so it's hard to predict when you'll run out of projects.

Another approach would be to allow the auth accounts (i.e. unique user ids) to be shared between companies for people who can log into multiples (Side note: curious how an employee could work for two orgs in your app). You could control access to the orgs by writing security rules that restrict reads to members of the org:

service cloud.firestore {

  match /databases/{database}/documents {

function isOrgMember(orgId, userId) {

    return exists(/databases/$(database)/documents/organizations/$(orgId)/members/$(userId));

}

match /organizations/{orgId} {

    allow read: if isOrgMember(orgId, request.auth.uid);

}

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/c84c03d8-d0b1-4d2c-b917-5ad75653645c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Colin Cannon]

Thank you Kato for the reply,

The first approach wouldn't work for me because I am building a SaaS app and we may have thousands of clients, so I would always be worried that I would be cut off with each new client.  I wish there was some way to create multiple user accounts in the same firebase authentication project, don't know how that would work though.  Or if we knew how many projects we could spin up and just pay for them, I have no idea if the limit is 10 or a 1,000,000.

As far as the second approach, the users are not employees of my clients, they are clients of my clients.  Our software is basically a membership shell site for a specific industry.  Businesses would use our application, but they would get their own members.  It is definitely possible that a user would be a member or more than one of our clients.  Even our clients wouldn't know each other so sharing logins wouldn't work.

I love firebase and I have used it in apps and PWA in recent months, it just doesn't feel like it is meant for something like a SaaS application, unless I am missing something big.

[Chuan Ren]

Hi Colin,

We're working on a native multi-tenancy support for Firebase Auth which has not been released yet. We'd like to invite you to try it. You'll receive an email from our PM and feel free to discuss with him directly.

[Luca Faggianelli]

Hi Chuan, i'm facing a similar issue, but my concern is mostly for data isolation in firestore for each customer, would you be so kind to include me in the invitation list as well

Thanks

Luca

[Viggo Navarsete]

Hi Chuan,

I'm also working on a multi-tenancy app where I want to separate each organization within firestore, but would like to have this in ONE project, so it seems this native multi-tenancy support would be of high interest for me too. Is it possible for me to receive such an invitation?

Best regards,

Viggo

[Chuan Ren]

Hi Luca, Viggo,

Thanks for your interests. You should receive an invitation in the near future.

Best,

Chuan

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/a3e918d3-4b5e-4f9f-bf7d-39bbd0aab8ad%40googlegroups.com.

[conor...@gmail.com]

Hello Chuan, 

I would greatly appreciate having an invitation to this multi-tenant feature. I'm working on 2 multi-tenant Firestore SaaS apps for the past year.

Thanks in advance!

- Conor

[Arsenio Aguirre]

Hi Chuan,

I am also working in a multi-tenancy application, I would like to participate trying the feature.

Regards,

Arsenio

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CABwWdYm%2B-ArdDQXQdYDyvtx6pcZKHBGp_ZN8ixB5YGxupyL_iQ%40mail.gmail.com.

[Marc Jordan]

Thanks all for your interest in potential Multi-Tenancy solutions with Firebase Auth.

We'd love to learn more about your use-cases, so if there are multi tenant applications you're building today, could you provide feedback in this Form? https://forms.gle/vxh8htwkvfmS1tN77

Thanks!
Marc

Firebase Auth PM

[jo...@nowims.com]

Colin,

We are combating this right now with one of two methods:

1. Separate each project for each customer - leverage deployment manager to completely deploy your solution to a new project, etc.  An issue you may have is the provisioning of the Firebase Hosting URL if you provide custom URL for each customer.  I would suggest using AppEngine for this as you can use the API to modify URLs.
   
   
2. Denormalize your data as Keto suggested - we do this for customers that do not require their own environment.  Your end-user(s) would sign in using the methods you provide through Firebase Auth (e.g., Email/Password, GMail), you would persist auth.uid into a Firestore collection "users". Each organization would be contained in a collection "organizations", and then you have two additional tables for the denormalized structure as below
1. userOrganizations -> authUser.uid: { organizationId: {role: "member"}}
2. organizationUsers -> organization.id: {authUserId: { role: "member"}}

Note: we store activeOrganizationId on the user for front-end - think of this like slack or discord channel selections.

As Keto said, you can then configure your firestore rules to limit the access to organizations, etc... 

Hope this is helpful for you.

[jo...@nowims.com]

Kato,

A follow-up to my previous post, an idea we are considering is leveraging a central Firestore to hold the configs for each client application.  For example, our application would use our company's default Firestore config for the iOS, Android and Web applications, the first step of authenticating would be requesting the "User" organization_id which we would then look-up in our main Firestore configuration collection and create a secondary config within the application to reference the organization firebase project config.  We would then use the secondary config to perform queries, etc... 

To give a little example - (web config used below)

firebase.initializeApp({
  apiKey: default1
  authDomain: default1
  databaseURL: default1
  storageBucket: default1
});

Use the above config to lookup appropriate organization config stored in our Firestore

firebase.initializeApp({
  apiKey: customer1
  authDomain: customer1
  databaseURL: customer1
  storageBucket: customer1
  messagingSenderId: customer1
}, "customerConfig");

Use customerConfig to perform all customer operations.

This is a proposed idea, any feedback is appreciated. 

[jo...@nowims.com]

Kato,

I apologize for calling you Keto, the diet must have been on my mind.  

Question for you as we just ran across a potential problem with multiple projects - if we use multiple projects for multi-tenancy, what is the best approach for configuring our iOS and Android apps to leverage the appropriate Firebase project?  We do not want to release a new version of our iOS and Android application for each customer in the app store so open to suggestions.

On Wednesday, March 27, 2019 at 9:35:36 AM UTC-5, jo...@nowims.com wrote:

[James Miller]

Hi Chuan,

I am also working in a multi-tenancy application, I would like to participate trying the feature.

Regards,

James

[Bassam]

Hey James, multi-tenancy is now generally available: https://cloud.google.com/identity-platform/docs/multi-tenancy

Best regards,

Bassam

[AFT]

Is this also available for Kotlin/Android SDK ? 

I am trying to write an App from which users should be able to perform all the functions that could be done from a web based dashboard.

I have successfully enabled Multi-tenancy from GCIP , however I could not find any API in Kotlin SDK which will allow me to pass Tenant ID during authentication.

Can someone please help me figure this out?

Thanks

[Marlo Kessler]

Yeah, 

I think you are seriously doing some great stuff and multi tenancy is one of it. Nevertheless, it would be a great to know whether you are bringing multi tenancy support in the iOS and Android SDKs.

Thanks guys!

Best regards

Marlo