I have a saas platform I'm building and I'm currently struggling with how to model my auth flow. The system is going to be multiple multi-tenant applications but I would like to unify user authorization & authentication. Basically, each US State will have its own web app/resource server/database and every county in that state will be a separate tenant. I cannot combine all states into one application, so that is not an option.
I would like to throw all users and their information/password into one database connected to my auth service. But each county (tenant) admin within each state (web app) needs to be able to add & manager their users and their roles. So the auth service needs to be aware of all the different tenants across each application. I also need to be able to link items created in each database to the user that created it. If I create object "X" and another user in my county views that item, they can see "Kovaci" created this.
I also do NOT want SSO between states but if possible I would like users to be a part of multiple tenants within one app (not a requirement though). Native iOS/Mobile apps are another client I need to support with this flow.
I used this bitoftech article to base off of: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/comment-page-1/#comments
And here is my paint quick mockup: multi saas design
My question is just generally how do I design this auth part? Can I store all users in one auth db like my goal? If so, how do tenant admins manage them and how do I link tables in my separate app db's to the users' current info in the auth db?
Related
I am currently working on SAAS Application, where the world wide users can authenticate to our system.We are in research between AWSCognito and Firebase authentication.I was able to see AWSCognito user pools can be made available across multi-regions by replicating the user pools in needed regions so that the world wide users can authenticate with very low latency.In case of Firebase ,there is an option from multi-region but not suits for my use case.our targeting areas are IND,AUS,US and UK.So, can anyone suggest me to do a proper architecture for this use case ?
Firebase Authentication stores user data in a single global pool.
The data is replicated across the worldwide automatically across Google infrastructure, but there is no way for you to control regional shards for your users in Firebase Authentication. So if that is a requirement for your application, you'll need to use another system.
I'm using Microsoft Graph SDK for .NET Core. I'm trying to get a list of all Office 365 plans in all Azure Active Directory groups within my organization.
I have been reading through a lot of questions, but haven't found a clear answer to my problem: As it's stated in the official documentation, you cannot list plans in a group using client credentials (application permissions), which is the exact authentication method I'm using. Given this, how can I achieve my objective?
As per documentation, the only way to list plans in groups is to use Delegated Permissions, but in that case, and according to the Microsoft Graph permissions:
either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph.
If the signed-in user is a regular user then the application will only access the groups that user is a member of. Bear in mind that there may not be a single user that is a member of all groups.
Is there a way to get my application to list all plans in all groups within my organization?
You can now use application permissions.
Outdated Reply:
Planner currently does not support application permissions. Depending
on what your scenario is, you have couple of options. One option is to
create a user account to be used by your app, and add that user to all
the groups. Then you'll be able to query the plans with the
credentials of that user.
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
Use case: the app I built on app.foo.com, and an instance of telescope on community.foo.com, on separate application servers. The only collection they'd share is users. I would give the same mongo url and oplog url to both apps, and make sure that other than users, collection names did not overlap between the two apps.
Should this work fine? Any performance concerns?
The problem with this is you have to share the collection names.
If you use your databases you're also insured against Telescope suddenly using a collection name that your other app uses on a future version too.
What you can do is only share the users collection if you want.
Server side code (not needed on client)
Accounts.connection = DDP.connect("https://<telescope app url>");
Meteor.users = new Mongo.Collection("users", {
_preventAutopublish: true,
connection: Accounts.connection
});
Or more directly (not preferable if you're allowing OAuth logins)
var database = new MongoInternals.RemoteCollectionDriver("<mongo url of telescope app>");
Meteor.users = new Mongo.Collection("users", { _driver: database });
So this app now uses the Telescope app's user's collection.
There would be no problem with this at all. For example it's a common use case to have a user-facing app and an admin app, both using the same db.
This shouldn't be done at the database level:
When any of the two apps evolve, they could break themselves or the other one.
That's the kind of feature that belong in an API layer, or a separate service.
This way you have one user identity service that handles authentication (even cross-domain) and basic user data, and leave each app-specific user information in it's own part of your ecosystem. No risk of meltdown.
I can recommend a few :
Firebase
Parse
Hull.io (disclaimer : I'm a founder)
Auth0
LoginRadius
Most of these have client-side libs that you use to handle authentication and just pass back the currently logged-in user's ID to your app.
Some also offer to have one app being the Master, and authenticating users, then telling the service who's logged in, so you can retrieve data from your other app (at hull we call this Bring your own Users)