I have several different types of users (InternalUser, Clinician, and Patient) that can log into my website, so, for each type of user, I've created a user class that inherits from ApplicationUser.
If a logged-in user comes to the website's main page (https://example.com/) then the MVC controller code needs to figure out which type of user it is so that it can return a redirect to the correct "main" page (https://example.com/clinician, https://example.com/patient, etc.).
It seems reasonable to me to use a claim as an easy, low-cost way to discriminate the user type in the controller, without having to load the current user from the database. When I register a user, I add a claim that represents the user "type":
await _userManager.AddClaimAsync("ihi:user_type", "clinician");
Then, in the controller, I check the claim:
[Authorize]
public IActionResult Index()
{
if (User.HasClaim("ihi:user_type", "clinician")) return Redirect("...");
if (User.HasClaim("ihi:user_type", "patient")) return Redirect("...");
if (User.HasClaim("ihi:user_type", "internal")) return Redirect("...");
throw new InternalErrorException("Logged in user is not in a recognized user role");
}
I have a couple of questions regarding this scheme:
- Is this a reasonable approach?
- This scheme (both the
[Authorize]attribute and my claims checks) relies on looking at the value of a cookie. Is the data stored in that cookie reasonably safe from tampering? (I would hope so, otherwise an attacker could modify the cookie and game the Identity system.)