We're using Custom Claims in Firebase Auth to manage access in Firebase and allow custom UI experience.
We're now working on the User Admin part and we can't find a way to retrieve users by the custom claims.
For example, a user belongs to an organisation and have different access level - admin or user.
We need to allow the organisation's admin to see all their organisation's users.
We'd like to avoid using a separate database to manage organisation users to not double up the data.
Is it possible?
Can we retrieve all Auth users while filtering them by specific Custom Claim?
Thanks!
There is no built-in API to get a list of all users that have a specific claim.
There is an API to get a list of all users in the Admin SDK. So you could use that and then filter the users that have the claim you're looking for.
But performance of this will not be spectacular. So if listing all users with a specific claim is a common use-case for your app, you'll want to reconsider your concern about using an additional place to store the data. Duplicating data to achieve (well performing) use-cases is quite common in NoSQL.
Related
I've been trying to understand the differences of one-to-many and many-to-one relationships in nosql databases. I purchased a few courses on this and Firestone security rules language and have a basic grasp of it all, but I can't think of an efficient way to make a document accessible with a group of people.
I'm trying to implement an application where a user can have a profile and add users to be able to visit the profile/page as well. The only way I know how to do this is to add a field of allowed users to a document and when a user pulls the document down if their ID isn't in that field of permitted users then the profile won't display. I understand this is horribly flawed in that the user was still able to read the document and could rewrite it if permissions aren't set correctly. The only security in this method is hoping that no malicious users no the file path to where documents are stored.
Does anyone know how to properly add a group of users to be able to access a document in firebase?
So far I've implemented UID authentication in Firestone rules to ensure that a user is authenticated, but still any authenticated user can read or write any document in the app I'm demoing around with right now.
I also know you can create custom user types in firebase. This doesn't seem a valid solution for my application since I want to create a custom 'group' for each user that has a profile. Any advice would be greatly appreciated.
We're using our auth backend for multiple customers. The idea would be to create a tenant for every customer account. For user management purposes, I need to display a list of all available users in the front end.
As I can't just display all available users, I'm looking for a way on how to retrieve a specific group of users.
getUsers() (https://firebase.google.com/docs/auth/admin/manage-users#bulk_retrieve_user_data) doesn't help, as there is no UserIdentifier for custom claims (which would be a way to differentiate between accounts).
Another idea (as mentioned) would be to create a tenant for every account, and map the users that belong to this account. But it seems like there's no method to get all users for a tenant as well.
Of course I could just store user data in firestore as well, but I'm curious if there's a different way.
Thanks in advance for your help!
The documentation for Google Cloud Identity Platform seems to indicate that it is possible to get a list of the users for a specific tenant by calling listUsers on an auth instance that is initialized for that specific tenant with:
const tenantAuth = admin admin.auth().tenantManager().authForTenant('TENANT-ID');
tenantAuth.listUsers(1000, nextPageToken)
.then((listUsersResult) => {
...
})
I am trying to see if Firestore is the right tool for my need.
I am designing a multi-tenanted system using Firestore for scalability and security. Can this be done correctly using just Firestore, Firebase authentication, and Firebase rules to handle all CRUD operations? The idea behind the entities is:
System > Account > Business > Customer
Roles at each entity level would be:
Administrator, Manager, Support, Report, Unauthenticated (the customer)
Accounts have businesses and businesses have customers. Customers would not need to authenticate but read a specific document (designated by the business) and then create their own specific new document. They could create multiple documents but there would be time-based volume thresholds (no DOS!).
I believe Firestore Rules would work great if it didn’t have the Account as a superset that has multiple of the Businesses.
Is it possible to create a system like this with just Firestore, authentication, and rules alone? I want to keep things simple but also not pound a nail using a pair of pliers.
Thanks in advance for the insight!
With a set of well defined Custom Claims you can indeed use Firestore for such a multi-tenant system.
In your security rules, you would combined the different claims, depending on the access role.
In particular you should:
Check the user has the correct claims e.g. auth.token.businessId == "xyz", auth.token.role == "Support"
Check that the user is writing/reading a doc that corresponds to his entity, e.g. allow create: if request.auth.uid == userId && request.resource.data.businessId == auth.token.businessId
Don't forget that Security Rules are not filters, so in each query executed by a user, you need to add the different ids from his/her custom claims (businessId, accountId, etc...). Either by mimicking your entities tree with (sub)collections, or by using some where() clauses in the queries.
Note that since Customers would not need to authenticate, they could potentially read and create documents from/for others businesses, if they have the ID of these businesses (i.e. the DocumentReferences).
You will probably have to manage a set of claims for each user (role, account, business, ... ), which can become complex, so you might be interested by the following article which explains how to create an Admin module for managing Firebase users access and roles.
I am currently building a multi-platform web application and I'm currently busy with the authentication of users. I'm using vue on the client-side and django and the backend with postgres as the db.
I thought I would try out using firebase's authentication as it would speed up the process as well as take care of various issues like security etc. I have now come across a bit of a problem:
I need to add extra fields the user (gender, address etc.)
I need to set user roles (admin, manager etc.)
I am aware about some kind of way to set user roles but not really sure. In terms of extending the user in my mind I have two ideas:
Either I use the UID from firebase as a identifier to an extended user class
in my backend db. But that kinda defeats the purpose of speed.
Use Firestore - not sure how I would go about doing this though.
plz help
I have written a blog and made a video on how you can use custom claims to assign roles to your users. Essentially, you apply custom claims on a secure backend like inside of Cloud Functions, and these can be used to control access to Firebase backend features like Cloud Firestore and the Realtime Database. You can also check out the Firebase guide for more information.
As for additional data about a user like gender and addresses, that should be stored in Cloud Firestore, the Realtime Database, or whatever database you choose to use. It is not information that you constantly need when accessing a User object.
This is my first attempt, trying to integrate Membership on an existing shop already in production.
I'm not quite sure, based on my scenario, if I should use the build-in aspnet-providers or custom implementations of them in order to integrate membership.
Here's a few details:
I have a multi-tenant, single database, single schema web app based on subdomain.
The app is already in production and I will later want to link newly registered users with existing anonymous orders by email.
The development will continue after the membership integration, new features will be added, meaning new columns and linked tables for the users table.
This answer got my thinking of using the membership deafult Profile in order to extend the users table created by the aspnet providers, since I don't have users yet. Though its not clear to me how I would link Users with Orders and other tables/entities that might later be added when the app is going to be extended.
Maybe I could define my entities related to users as user-defined profile properties but they would not have associations on my database.
Another overhead I'm thinking of is how would I associate the users with the different tenants of the app. I would want users to be able to regiter in different tenants/subdomains with the same email.
How would you implement membership in this scenario?
This question is an aggregate of a few questions. I will try to answer them to he best of my knowledge
In case of managing users, i would like to suggest that you consider the following approach
Pre-define a list of basic user profile metadata that you will need in the application
Create an extensible approach like having custom fields for the user profile so that it can accommodate any data that may be required to capture in future
You should also be planning for a self-registration system in the application that will allow your user's to register themselves like the anonymuous ones that use the system with an email
Regarding associating the business entities, you will require to associate the entities with the tenant and not with the user. the level of application will be from the tenant and then it will flow down to the users.
Additionally, you should not have the user accessible business entities, when they are maintained in a form of package or so, it will be very easy to manage and use.
Share your thoughts on these approaches.
- Create a tenant identifier column [property] for each profile that identifies the base tenant to which the user belongs to
- create a table that manages the list of other tenant's that the user may be gaining access to at a later part