asp.net Multi tenant localization - asp.net-core

We are developing an asp.net core multi-tenant application in which we have a single installation of the software and, based on the host, it gets the data from different database. THis way each tenant has it own database.
Single application - multiple tenat databases
Since tenants can personalize the fixed texts of the application, we need to store those localizations resources in the tenant database. At the beggining we load those resources with the default values but after that each tenant could change those values.
We need a way to have those resources so when someone types www.tenant-01.com it gets the resources for this tenant. But accessing the database each time we need a resource is not a good technique since the performance would be horrible...
Any ideas on how to address this?

Related

Localization in moqui framework

In moqui framework, how to implement localization for different labels for differrnt tenants. for eg tenant related xml cong files
All translations are in the tables for the LocalizedMessage and LocalizedEntityField entities, and those tables are in a separate database for each tenant. To use different translations for different tenants just add and modify records in the database for each tenant as needed. This can be done using the Localization screens in the System app when authenticated in the desired tenant.

Using Flat Files for authorization instead of using database tables

I have an mvc4 application which use sql database as back end. I am using asp.net identity for authentication and authorization. I have a need to move some of the user settings/configuration from database to flat files. The current system stores user configuration in tables which we do not want to share with customers. This information must be maintained in flat files and be written in the directory where the code is executed. I need to come up with a .NET MVC prototype which can store/retrieve user configuration from a flat file.
Basically, I need that instead of using the database for authorization for storing and checking what users have access to what features etc. I can store in a flat file and load that into memory and use that to check for authorization for granting users access to different features.
Also when the admin changes users authorization stuff it should update the file.
Can anyone please suggest me some scenario.
You can look into using files as Resources in your code. Resources can be accessed, read and updated at run time. And these will not be exposed to the users.
Some links which might help.
https://stackoverflow.com/a/1533984/689625
https://stackoverflow.com/a/20908560/689625
https://msdn.microsoft.com/en-us/library/7k989cfy%28v=vs.90%29.aspx

Should i use REST as a 'communication medium' between modules of a larger system?

What i mean by the title is: we have a system with different submodules, each with their own (MVC web) application. I thought about creating a REST service that accesses the database and gives data to the applications so no application themselves can access a database directly. The API calls on all the methods that access the database and an application chooses, which to use etc. Basically the web application's models aren't themselves mapped to any database entities which is commonly done in MVC applications (like in ASP.net with entityframework).
Why i thought about this idea in the first place is because i couldn't figure out how to map models to database tables without having to map to all of the tables and their attributes (switching some off for some applications, we're using Phalcon) and have hundreds of unused models in each application. How bad of an idea is creating a REST API for this?
If each application will access the same database you will have to maintain a lot of boilerplate model code (sql/orm). In case of some changes in database you'll have to propagate changes to every application.
In terms of maintenance it is better to expose business operations through web service which will be the only point of contact with database.
In case of web service changes inside database are not visible in applications
On the other hand without web service in front each change to database requires change in each application.

impersonation of different users using entity framework

i'm planning to use a combination of entity framework + plain sql access for a large sized project that i'm about to start. its an ASP.NET web application.
for auditing data, i was thinking of creating a user in sql db for every user in membership that i create so that the auditing can automatically track the asp.net logged in user activities. so basically, if i could impersonate as that username for the connection that is used, then sql server will automatically log.
do you know how to implement this in entity framework, i'm fairly new to ef.
if this is not possible, do you know another solution WITHOUT manually including userid in every sql insert/update/delete.
thanks..
That is pretty bad idea. If you want this kind of auditing don't use membership and instead use Windows accounts directly with Kerberos delegation as common in large ERP or CRM systems = each user will have access to the database with his own domain account but it requires very correctly specifying security for the database and it will most probably lead to design without entity framework because you will not want users to be albe to execute queries directly but only to execute stored procedures under their user context.
If your application should be publicly available then this level of auditing is not for you and you must roll your own solution on the application level (not the database level).

Performing centralized authorization for multiple applications

Here's a question that I have been wrestling with for a while. We have a situation wherein we have a number of applications that we have created. These have grown organically over a period of time.
All of these applications have permissions code built into them that controls access to various parts of the application depending on whether the currently logged in user has the necessary permissions or not.
Alongside these applications is a utility application which allows an administrator to map users to permissions for all applications - the way it works is that every application has code which reads this external database of the said utility application to check if the currently logged in user has the necessary permission or not.
Now, the question is this. Should the user-permissions mapping information reside in and be owned by the applications themselves, or is it okay to have this information reside within an external entity/DB (as in this case the utility application's database).
Part of me thinks that application permissions are very specific to the application context itself, so shouldn't be separated from the application itself. But I am not sure.
Any comments?
You should read up on federated identity, which is the new trend.
We have for over 10 years maintained a library we used across all applications which centralized user authentication and authorization. It is loosely coupled to AD and has centralized roles and rights that are managed by the user community based on business needs and not the network personnel.
Our design has afforded us the ability to embrace the new trends on federated identity practices along with claims based identity and simply update our library allowing all applications, some of which are written VB6 to use current security requirements.