Should I use role-based authentication?

Question

I have 3 types of users who might login to my website: Admin, Instructor, Student.

I already have tables for Students and Instructors , and each one has its unique properties .

Now I want to create the login page. Many tutorials use role-based authentication in similar cases, but In my case , I have already created different classes for each of them. Also , there won't be a register page, since instructors are added by Admin and students by instructors. Can't I check the type of the user once he loges in? and then I redirect him based on this?

Answer 1

Do the simplest thing that could possibly work. If the user in itself also dictates the role it has, then spend no further effort separating them. Can always do that later.

You could add an 'account' table and create foreign keys towards it, you'd have one table to check login name and password and thereafter you can query for the specific user. It would help to store the user type in the account table so you know what foreign relation to query.

Answer 2

People are just people.

An instructor can take a class, and thus, be a student. An admin may also instruct. A student may take several classes, and thus have several instructors. So, it is best not to conflate the notions of a person's identity with the role(s) they play and to accommodate that roles they play are contextual.

Many systems need to support the notion that one user has several roles. If you don't support that, then when an Instructor is an Admin or a Student, either they'll have too much permission for a given context or it just won't work properly, and they'll have to use a different login (i.e. create multiple identities, possibly involving managing multiple email addresses) when they want to use the system from a different role they play.

---

Regarding your internal implementation (from your comment to @Joppe), use of inheritance (e.g. Student inherits from Account) precludes having one person play multiple roles. This should use composition instead. Speaking philosophically, we would not say that "A Student is-a(n) Account".

---

You might consider an identity page, which gives the user access to the various roles & contexts they have. Then allow them to choose a role (or context) and proceed with the authorizations and access control associated with that role for the rest of their session. They should be able to change roles by going back to their identity page.