12

In my application I am using ASP.NET Identity and I have different types of user( Teacher, Student, ...) that have their own properties, For for Teacher I have Experience, Languages Spoken, Certifications, Awards, Affiliations, ... and for Student I have different properties. So in this way I can't use roles because of different information per user. So all of them actually are users I mean they can login on my site. Also They have common information for signing up: First Name, Last Name, Email, Password Now what do you think and what's the best option for doing this? Should I create class for each user that inherits from IdentityUser<int, CustomUserLogin, CustomUserRole, CustomUserClaim> ? Any idea?

PS: I've found some solutions for doing that, For example here recommendation is to use Claims But it's not clear enough for me, Actually Claims are hard part of the puzzle and I didn't get what they are? :), It would be better to have examples. Thanks

Community
  • 1
  • 1
Sirwan Afifi
  • 10,654
  • 14
  • 63
  • 110
  • "So in this way I can't use roles because of different information per user." Class properties and roles are two totally different things; you can create whatever roles suit your application's security requirements, irrespective of class properties. – IrishChieftain Apr 10 '15 at 16:17
  • Yes I know. I mean those properties I need is belong to users not roles. – Sirwan Afifi Apr 10 '15 at 16:21
  • maybe this article will help get you rolling in the right direction: http://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/ – rogerdeuce Apr 10 '15 at 17:00

2 Answers2

11

Apporach #1:

The Claims approach may be the way to go. So you derive from IdentityUser in the normal way and add the common properties to the derived class. Then for each type of user you would add extra claims using UserManager.AddClaimAsync.

So, for example, let us say you create a new class user class called AppUser. You can then do:

AppUser teacher = new AppUser { /* fill properties here */ };
/* Save User */
await userManager.AddClaimAsync(teacher.Id, new Claim("app_usertype", "teacher"));
await userManager.AddClaimAsync(teacher.Id, new Claim("app_grade", 4));
await userManager.AddClaimAsync(teacher.Id, new Claim("app_exp", 10));
await userManager.AddClaimAsync(teacher.Id, new Claim("app_awards", "Award1,Award2"));
await userManager.AddClaimAsync(teacher.Id, new Claim("app_langspoken", "English,French,German"));

AppUser student = new AppUser { /* fill properties here */ };
/* Save User */
await userManager.AddClaimAsync(student.Id, new Claim("app_usertype", "student"));
await userManager.AddClaimAsync(student.Id, new Claim("app_grade", 2));

These will add different claims to different types of users. So the teacher claims to have "app_experience" of "10", "app_awards" of "Award1" and "Award2", etc. On the other hand the student claims to only have "app_grade" of "2".

Basically, the first parameter identifies the type of the claim and the second parameter is the data that backs up that claim. The type can be anything, so choose something that makes sense to your application and maybe prefix each name to distinguish it from others. In the case I've just prefixed "app".

You can then use UserManager.GetClaimsAsync to get all the claims for a user and search the returned list for the claim you are interested in.

Approach #2

The other approach would be to create a AppUser class and then Teacher and Student class that is derived from AppUser. In these classes you would add properties that would otherwise be added as claims in the example above.

The slight downside to this is you would have to create separate tables for each of these different users with relationships back to the ASP.NET Identity user table.

Plus, using FindByUserNameAsync, FindByEmailAsync, etc, will only ever return a single type of TUser, in this case, AppUser. Also, these methods will only query one table, AspNetUsers, so it would be up to you to fetch the extra information from the relevant Teacher or Student table.

MotoSV
  • 2,348
  • 17
  • 27
1

Since all users will have some of the same properties it would make sense to create a "User" class to hold all of the properties that will be the same for Teachers, students, etc.

I would then create a class for each User type with just the properties that are specific to that type of user. In this class I would include UserId as one of the properties so you have a relationship from your main group to their individual type(s). See below:

User Class: UserId (Primary Key), FirstName, LastName, Login, Password, Etc.

Teacher Class: UserId (Foreign Key), Grade Taught, Experience, Awards, Etc.

Student Class: UserId (Foreign Key), Grade, Honors, Etc.

There are many ways to do what you are after so this is just one suggestion. Good luck!

Lexi847942
  • 71
  • 1
  • 5