aspnetboilerplate global user table (common for all tenants) - aspnetboilerplate

Let's assume below scenario.
There can be multiple tenants. Each tenant offers different services based on their business to clients. Depending on the size of the client, they may have their own database as well (ex:- Large clients prefer their data to be isolated).
Arranging tenants to fulfill above scenario is possible with the AspNetBoilerplate out of the box.
Then comes the customers who consumes various services provided by multiple businesses (tenants). There is a single mobile app for these customers. Once they login, they should be able to get services from any tenant unless a tenant has blocked a user.
Note that the point here is these customers are NOT registering for each tenant separately.
What are my options to get this setup done properly using AspNetBoilerplate? My initial thoughts are;
1) Have a separate table - MyCustomers - All mobile users will get authenticated against this table. For this should i create a separate auth pipeline ?
2) Current AspNetBoilerplate demo; you choose the tenant and login. But in my case; they log in and they will choose a service provider (tenant). At this point;
Should I create a new user automatically IF the selected tenant is in a different database (For large businesses having their own database)?
If the selected service provider is a small customer, who are in the same database differentiated with a TenantId I will have to additionally have a --> (many) relationship maintained so when a new service is selected a new record goes to this table?
At the end of the day, MyCustomers will only be using a single mobile app to get any service from any business after they login. Once they login, they should have access to all tenants (unless they are blocked).
Is there a better way to do this using AspNetBoilerplate existing architecture?

Related

Admin dashboard for microservice application

I am working on an admin dashboard for 5 services using Laravel. It is really complicated to do so in admin. We, for example, want to show a list of transactions with user name for each row. Both of the users and transactions tables are in different databases. We had to make another request to fetch the user name form the other service.
I am wondering about when it comes to statistics and writing complex queries to get data from all of theses services in a report. How can I handle such a case?
Can I make multiple connections to the databases with the admin dashboard project?
Is there any available pattern that facilitate the work for me?
Thanks

Is there a way to restrict some users to access SQL tables based on their group

Please help me as I'm new to REST API, ASP.NET MVC and developing an application from scratch. I have a requirement from client to build a ASP.NET WEB API application with SQL Server database. I'm new to development so I need help on the queries raised by my client.
The application will have 3 groups of users: admin users, group 1 users and group 2 users. Since each of these groups will have different functionalities, the database tables are also going to be different for each group.
The query raised by my client is that group 1 users should not be able to access the tables of group 2 users and vice-versa even from outside the application.
I know at the application level, we can use an [Authorize] attribute in REST API calls so that access to each request is authenticated.
Apart from this, can we do anything at the database level so that users who know the database name, login will not be able to access 100's of SQL Server tables which they don't have to deal with by any other means. The connection string used in application will be having a login which will be using SQL Server authentication mode. Can multiple connection strings in my application be a solution to deal with this scenario?

A single user credential to connect to multiple tenants

I am using ASP.NET Boilerplate for its multi-tenancy support. When a user log in, I would like to present to the user the list of tenants it has access to. For instance, if a user with email admin#example.com is part of Tenant-A and Tenant-B, would like to offer the choice to switch between tenants.
This does not seem to be easily doable. Each user can be mapped to a single Tenant (AbpUsers table).
What would be the best way to allow a user to access multiple tenants? The only way I think this can be done is by adding a N:M table between User and Tenant, but then will ABP allow me to do context switching between tenants?
By design, tenant data (including users, roles...) are completely isolated from each other and can not be shared easily.
We solved this issue with "Account linking" feature in AspNet Zero. With this feature, you can connect your accounts in different tenants and then switch between accounts with a single click. It basically maps those accounts (users) in database and logs out & logs in automatically when you want to switch. See more info: https://aspnetzero.com/Documents/Development-Guide-Core#user-menu

Multi-tenant application using MEAN stack

I am working on a multi-tenant app in MEAN stack, in which user will signup and using their business names I will create an account(sub-domain) for them : abc.example.com.
So what approach should I use for this multi-tenant app?
A single database in which each client have their specific collection.
Or, should I maintain separate db for each user signup ?
In my application, I will be having 3-4 fixed collections for each user.
So out of these two which will be more beneficial and If you can also provide any example to support your answer ?
There are a lot of criteria that you need to look into before switching to the separate database per tenant model
Tenant volume, the number of tenants in the system
Volume of data per tenant
Compliance requirements like HIPAA that you have to adhere to the tenant
Geographical diversity, one tenant in USA and other tenant in Asia etc...
Both the options are fine, but once you are not able to predict beforehand the values for the points 1 through 3, you can just use the same database with a tenantid column and later scale out to per tenant database with ease.
If you have some values for the above mentioned points, the community here will be able to guide you better.

Authentication and authorization with the seperate database multi-tenat approach

starting a proof of concept for this model it appears not to be possible to configure the membership provider per request to the respective clients database. It appears that the web application instantiates the membership providers on application start and doesn't allow modification to this during subsequent requests.
I have tried using reflection and modifying the connection string in the Application_BeginRequest (in the global.aspx) but it appears that the membership provider is designed and implemented to only initialise once per application rather than per request.
This implies for the separate database approach, the default asp.net membership provider wont work with the single application/multiple database (multitenant seperate database) model.
what authentication/authorization model do people use in this architecture? do they use a custom implementation of the Microsoft membership providers or do they use a different package or library?
Cheers
Tim
In the case of a multi-tenant application development scenario, the best preferred is a SSO or to go with a custom profile management system.
In order for you to enable tenant based authentication using the databases, you can have a connection string manager that identifies your tenant based on some of the criteria like the company code or the URL and then use the user login data from that database for that tenant's users.
The usage will be like you identify / infer the tenant code from the login credentials and then choose the database that is available for that tenant and then authenticate the user against this database. Hence the tenants can have their own databases for their user's authentication.
This is feasible and can also comply with the regulatory requirements that may be for different tenants based on their geography.

Resources