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?

  • 1
    I doubt that many tutorials advocate for role-based authentication; more likely role-based authorization, or better yet role-based access control. See the Q&A here for some thoughts on the differences: role-based vs. identity-based authentication.
    – Erik Eidt
    Feb 11, 2017 at 17:17

2 Answers 2


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.

  • Is it going to be one-to-one relationship? or inheritance? I mean, if Instructor and Student inherited from Account, then the discriminator can tell the user's type.
    – Comp23555
    Feb 11, 2017 at 14:29
  • @Comp23555 That's what you commonly see, usually they call it 'user' then. I sometimes separate the account from the user, making it composite. So the user can remain to exist after account got removed (job change, finished study etc). Depends on your needs of course.
    – Joppe
    Feb 11, 2017 at 14:32

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.

  • My website will be for compiler course project purposes. In my university, only IT and engineering students take compiler course, and on each department, the course is taught by different instructor. It's required that only the admin adds instructors, and each instructor adds his student (only those added to the database are allowed to login). A person can be one of those three, and he will be redirected based in his position.Do you think that there's a better approach than the one mentioned above?
    – Comp23555
    Feb 11, 2017 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.