Reputation: 12318
I have a web api. I want it to have two types of users. They are completely unrelated.
How can I manage authentication of they both?
I don't want to have them in the same table and manage the type of them as Roles, because they are different entities. One kind of user is used by humans and the other one is used by services. They have different classes and attributes. I would like to have something like two IdentityDbContext but I want to maintain all in the same database. Do you think is possible?
Upvotes: 5
Views: 1309
Reputation: 387
I'm not sure if that is a good practice, but you could use different schemas, like:
[dbo].UserProfile and [webapi].UserProfile
As far as I understood you are using ASP.NET MVC and using the default IdentityDbContext that comes with the Empty Project.
It uses a CodeFirst approach that creates the tables on your database. You just need to create the other one you need and configure it to use the different schema.
EDIT - Example
Notice [Table("UserProfile", Schema = "dbo")] and [Table("UserProfile", Schema = "webapi")]
This way EF will notice that you're trying to fetch data from different tables.
[Table("UserProfile", Schema = "dbo")]
public class UserProfile
{
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int UserId { get; set; }
public string UserName { get; set; }
}
[Table("UserProfile", Schema = "webapi")]
public class UserProfileWebApi
{
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int UserId { get; set; }
public string UserName { get; set; }
}
If you want to go further, you can create an interface for both classes. But again, I don't believe this is a good practice, you should just create a table with a different name to avoid confusion.
Upvotes: 6
Reputation: 174
There are two options I can see:
Have each user type extend a base user, so that any additional properties can be stored in a separate table for that user type. This will involve having the base user data stored in the same (existing) table for both types of user. If the authentication process for both user types is the same (username + password) then you should do this. This way you can just use the existing attributes on your controller methods for authentication.
If the users have no common properties / behavior regarding authentication then you will need to implement a custom solution for the second type of user. This may involve using a different schema for user data or to create your own logic around the authentication. I would guess in this case that the two types of users would never call the same API method? You could create a custom authentication attribute for the second user type. I find it hard to believe you will need to go down this path.
Upvotes: 0
Reputation: 4101
You should not manage different user contexts separately as entity can distinguish the types separated by table or discriminator column. Race conditions can be introduced when using two contexts for the same item and caching is no longer possible.
Upvotes: 2
Reputation: 6461
Since you wants to maintain Single (same) Database
. I think, you don't need to use Two different Contexts
for Same Database.
If you maintain Two database
then you can go with Two Context's
. Until otherwise its not necessary to have two contexts for Same DB. To be frank its waste of Time and work.
Also Using multiple context for same database is not a good code practice. It might create a performance problems when its come to the real time.
In your case, you can create two tables and use single Context
. Because as you written its having different attributes and types. I guess also you are using Code First Approach. I suggest to use single Context for single DB
.
Upvotes: 1