I have a shared Database for a Multi-Tenant WebApplication, that uses Entity Framework Core. The Tenants have their own Tenant Table and every model has a Tenant ID.
By Design it is not possible to access the data of another Tenant because I have Query Filters and the code in the controllers always checks TenantId.
But I would like to encrypt the data of each Tenant or at least the most sensetive data with a different key or purpose string.
I implemented it for one model with the Protection API.
It would be a lot of work though to implement it for every model, because I have to call protect and unprotect after every Database call in the controller.
I am using MariaDB as my Database. Does somebody know if it is possible to let MariaDB do the encrypting? I know you can encrypt the data at rest, but is it also possible to encrypt different rows identified by TenantId with a different key?
Related
Summary of my problem
My project is more complex but here is my problem at very basic level. I have a Blazor WebAssembly project where I do just basic CRUD operations.
I also have a small database and lets say I have two tables Users and Roles. What I do is to create their classes in Database-First fashion, by using Scaffold-DbContext and I run this command on the Shared project because I also want to reach to these classes from both Server and Client projects.
When I try to used Individual User Accounts on Authentication tab when creating a Blazor WebAssembly project, it creates the data models in the server. Which means I cannot access to my tables from Client Project. They need to be in Shared. Also it is Code-First based. I don't want to use migrations.
What I tried
What I tried to do is to create an identical -almost- project with Individual User Accounts projects but my Users class inherits IdentityUser and my DbContext inherits ApiAuthorizationDbContext but problem starts here.
I cannot add ApiAuthorization package from NuGet because it says Shared project does not compatible with .NetStandard 2.1.
Also changing Shared project's standard didn't work.
Some Questions
Can't I just add my users table on the Shared and use Identity from that table? (Since it's just a single table of rather larger database)
Do I need two databases for this? One for Identity, one for rest of the application?
Do I need to use Identity for Authentication & Authorization? What else can I use? Or Can I use a custom one where I can use it as I described earlier (Having models in Shared project)
My Goal
I want to authorize users with [Authorize] property. Since I cannot accomplish the registration, I cannot proceed.
Use 2 DbContexts. The Identity tables (yours or ASP.NET) should not be part of the Shared or Client projects.
I want to authorize users with [Authorize] property
The real authorization happens on the server, nothing in the client is safe. Have you looked at the complete (JWT based) implementation in the template?
Can't I just add my users table on the Shared and use Identity from that table? (Since it's just a single table of rather larger database)
No, Identity needs the base class. And your client app doesn't need (and shouldn't see) most of its properties.
Do I need two databases for this? One for Identity, one for rest of the application?
That is the best way. Note that you can have 2 DbContexts for 1 physical Db.
Link to the User wit a simple UserId (no Nav property) when needed.
While writing a solution from scratch based on microservice approach (more specifically it is Azure Service Fabric) I came to an idea of splitting the user Identity (which is login credentials, claims, etc.) and user profile (which may contain some social info like avatar, links to social networks, birthday, etc.).
For the identity, I'm going to use IdentityServer4 (stateless ASP.Net Core) and for storing all these data I'm thinking of an Entity Framework + SQL. The profile will be managed and stored on different microservice (stateless as well) with a connection to Cosmos DB (via Mongo DB API), thus making it a NoSQL storage.
Are there any disadvantages of such an approach I'm not aware of?
You're conflating a bunch of things here. First, you have your actual "user" entity persisted to the database. There is no good reason to split a "profile" from this, as it's all just data about the user. If you're using Identity to manage users, roles and such, it was designed to be extensible from the ground up, meaning put user data on the user entity. A separate profile entity only serves to necessitate an join for no purpose.
At a higher level, once the user has been authenticated (via Identity Server), you have a principal. That principal is basically just a set of claims tied to a particular "identity" (i.e. the authenticated user). The claims come from multiple places, it could be data on the user record, roles, or even third-party claims such as when an external login account is utilized. Where the claims come from is mostly inconsequential.
Long and short, there's no reason for a separate profile entity and especially no reason for an entirely different service to work with profiles. That profile service would inevitably have to utilize a user service, so there's a hard dependency between the two: a clear sign that it's no a true separate service. In fact, this only makes the rest of your app that much more complicated as then you're having to work with both a user service and profile service depending on what piece of the user you're after.
I've read a lot of topics about making ef core + ddd working together but they are only show an example where we have only one microservice. I stuck with solution about putting EF Core + DDD right where it's more than one. For example we have 1 database and 2 microservices (identity, schedule). In every service we have to keep own bounded context. Identity service only working with User, Role, ... tables... In opposite, schedule service working with User, Appointment, etc. Also, when we design a domain model we only using properties we need. So, in Appointment service for User entity I only need to use for example Id, NameDetails, Address, ContactInfo when in identity service I use Email, Password, etc. The question is: Should I use the different db context for each microservice? If yes, how I should handle migrations in that case?
Using one database for two or more microservices is a contradiction in itself. A microservice is supposed to be autonomous, meaning it should not share the same database with a different microservice.
If you need to reference a user-id for instance in two services, you would only store this id, whether it's an integer, a string or any other kind of key.
Your second database will not be able to validate the existence of that foreign key, since it doesn't know about the table where the Users are stored in.
You would want to create a single db-context for each service, that has it's own migrations and it's own database, when you really want to use microservices.
If you still want to use the same database to do that, you can create many DbContexts that actually point to the same database, but only define a set of entities.
In general there are different levels of domain-driven-design. You can do domain-driven-design without microservices and even without distributed systems. Keywords like Aggregates, Commands and Events, Distributed Systems are all part of domain-driven-design.
Some resources to read about domain-driven-design
https://stackoverflow.com/a/1222488/5397642
https://martinfowler.com/bliki/DDD_Aggregate.html
https://medium.com/withbetterco/using-aggregates-and-factories-in-domain-driven-design-34e0dff220c3
https://dev.to/designpuddle/apps--microservices--what-you-need-to-know-autonomy-and-the-challenges-you-will-face-39e1
I think that in this particular case User in Identity service isn't the same as User in Appointment service. I would make new Entity called, for example Person(with attributes such as NameDetails, Address, ContactInfo, DateOfBirth etc..) , in Appointment service and save it in separate database for that service (2 databases 2 services).
We have a large multi tenant business application and we want to know how Entity Framework and Authentication will fit in this design; i mean i need samples on how to use Entity Framework in this design and how authentication will be done; i see Dynamics Crm and sharepoint use Configuration(Master) Database and different databases for each tenant; how the users will be authenticated and saved;when i investigate dynamics crm configuration database, i see it contains users table; also, the tenant database contains Users table and i don't know the difference
Your question is broad and may require a lot of detail to go into. I would like to give you a simple overview.
The Entity Framework & OWIN Middleware's are one way of easing in the development effort. You choose EF when you ONLY have a object model that is similar to that of your database.
The advent of OWIN middlewares help you to easily integrate with a wide variety of authentication mechanism like Google, Facebook, Azure Active Directory etc...
Additionally, in addition to using OWIN, you will still require to build a logic around the user and tenant management systems. There will be a tenant table that contains the metadata about your tenant's [customer's].
There will be a user table that will contain your user's against tenant's. Here, each row can be identified against a tenant using tenant identifier or you can opt to use a separate table for each tenant.
The single database model is the one which is shared by all the tenant's and is belonging to the Level 4 of Multi-tenancy.
You should decide based your business specific use case whether you need to support a shared database or a dedicated database per tenant.
With OWIN, I have also written middlewares that can talk to any OAuth2 enabled IDP and get back the user into the system. It is upto the business usecases which drive the level of customization and depth of integration required and the technologies just help us achieve the same.
Please share some more specific questions or your views to discuss further
(ASP.NET MVC 4.5) Imagine you have a model for a bank or a company that has IDs that are sensitive information such as an account number or some other personally identifying information. What is the best way, or at the least what are some strategies, to route the edit/display actions without placing this information in the URL.
Obviously this would be bad:
https://goliath-natinal.com/Accounts/Edit/954321
if 954321 is your bank account number.
I imagine one way of doing this would be to add a GUID to each account that acts a a surrogate key. But I'm very curious to know if there are any possibilities for doing something if you cannot change the database at all.
Just throwing some ideas out here...
You could encrypt your identifier using Rijndael or some other type of encryption. You could salt and hash it based on other identifying fields related to the account. You could do that on the fly. You'd take a processing hit though.
If you're using a memcache or azure caching you could create a map of accounts to guids and let that just sit in the cache. If allowed, in the DB you could create a separate mapping table that maps the account to a new guid.
Can you give more info on the full restrictions? I.E. Is the table restricted from change, or the whole DB? Could you create a new DB?