I am asking about the best practice when I have a single application but can be deployed to different domains with different features and different databases and a single user may have an account on both domains so the user information will be repeated, so is it a best practice to create one database with asp.net identity tables and the identity server connect to this database and authenticate all users from this database? The question again is it good to put the asp.net identity tables at the identity server or at the client apps?
Asked
Active
Viewed 82 times
1
-
1This has nothing to do with best practice but with a proper design. Client apps can't be trusted with the user's credentials. That's why the user needs to login on the IdentityServer website. So a client may not have access in any way to the user's credentials. – Dec 30 '19 at 20:10
-
The client is one of the platforms of the company, it is not third party – malballah Dec 31 '19 at 07:45
-
The best practice is to create a single database unless you have a strong reason for wanting to utilize different databases for tenants – Randy Jan 09 '20 at 04:42
-
@Randy Thank you Randy, but are you sure of that, one database accessed by the client and the identity server is the best practice if the client is first-party? I have been adviced with a separate database for identity server? – malballah Jan 09 '20 at 08:12
-
What's the case being made for more than one database, especially when information is repeated? Also, it's because it's first party that I think information should be centralized. The one case where it should be ok to have different databases is if the clients have an OpenId Connect identity provider in front of their database that IdentityServer can interface with – Randy Jan 09 '20 at 13:06
-
@Randy Exactly I use identityserver4 host to authenticate users and secure some APIs so I delegated user management and authentication to the identityserver4, it is the open id provider, I have not repeated anything, the database at identityserver holds identity data but the client application database holds the information about the identity, so Users at identityserver and all other information about the user at the client database. – malballah Jan 09 '20 at 18:01
-
@malballah Please note the difference between the Identity User and the Business User. Both live in a different context. Read (the second part of) my [answer here](https://stackoverflow.com/questions/52079466/is-claims-based-authorization-appropriate-for-individual-resources/52100609#52100609) for some more information. – Jan 09 '20 at 21:44
-
@RuardvanElburg This is exactly what I did, I separate the identity user in a database and connected the identityserver to it, but also delegated roles to it, so I understood from your answer it is better to separate the identity user from the business user – malballah Jan 10 '20 at 17:52
-
@malballah Absolutely. For user authorization I can recommend the [PolicyServer](https://policyserver.io/) (from the creators of IdentityServer). Check the [OSS version sample](https://github.com/policyserver/policyserver.local). – Jan 10 '20 at 20:35
-
@RuardvanElburg I am confused, what I should do now is to make the identityserver just authenticate users and has a separate database for users only, and the roles permissions management must be managed from the client application? is that what you mean? – malballah Jan 11 '20 at 04:22
-
@RuardvanElburg what I did is I have a client MVC application with a database having a table Accounts with column IdentityUserId, and table Roles with column IdentityRoleId, and IdentityServer host with a database having tables Users, Roles and UserRoles, I allow users to get authenticated and I get their roles with the identityserver, also when the admin add users or roles to the client application I call some APIs at the identity server to add the users and roles also to the identityserver database I would appreciate if you tell me which part is not good in this architecture. – malballah Jan 11 '20 at 04:42