Authentication Systems - Separate for Management?

Question

Edit: I admit to being unclear when I first wrote the question. I suppose I wasn't sure of the issue myself, the comments and answers provided up to now helped me focus on the issue, thank you to all involved. This edit is a total rewrite of the question. End editorial comment

On a dynamic website we have two systems - content management, and user interface (trivial).

We are trying to decide if the two should have separate authentication systems (being two systems, this might increase security [or not - @GlenH7?]), each having its own hierarchy of permissions etc.

Or is it better to have a single system (it's the same database, after all... plus easier maintenance) and only play around with permissions (regular, jumbo, power, super nova, admin, Q)?

Answer 1

An Administrator is Role which is a super-set of all permissions and usually means something special semantically outside these permissions as well, as in having special permissions that no other role can have.

A Regular User with extended permissions is still a Regular User, but with additional permissions and by definition can't have the special permissions of an Administrator.

The two are not logically equivalent or semantically equivalent as they should also be orthogonal.

Maybe what you really want to define is a Power User if you don't have anything specific that an Administrator can only do.

Either way I would add auditing the system and I would try and re-use some underlying or existing role based authentication and authorization system rather than creating your own. This focus on the location of the authentication in this question alone tells me you will get it more wrong than right. Why would you think you need two authentication systems, twice as much work, twice as much change to make mistakes, twice as much chance for failure, etc.

Answer 2

Edit: I'm still staying with my original answer based upon the additional information you provided. Original answer is below.

Even if the UI and Mgmt sites have completely different content and URLs, I don't see that you have anything to gain from having two authentication / authorization systems. At a meta level, both sites are dealing with the same information and are using the same sets of authorization rules to determine if someone is allowed to do something or not.

You can still establish two hierarchies of permissions within the same authentication / authorization schema. User accounts can have varying degrees of privilege and access based upon whatever tree structure you deem appropriate. Ditto with the Maintenance accounts and the content they would be accessing. Using the same, underlying layer for that security implementation just makes it easier on you to build and maintain.

If for some reason you were really, really, really worried about regular users even knowing there was a maintenance interface, then I would suggest creating two separate sites / URLs for access but still use the same underlying security layer. It's trivial to create a second authentication view with its own URL. That would meet the "perceived isolation" requirement without significantly increasing your workload.

Original Answer

I agree with Jarrod Roberson's answer, and this is intended to provide more detail behind that approach.

It sounds like you need at least three categories of users within your authentication / authorization scheme.

• Regular user
  As the name implies, this is for the regular users of your site without any special privileges.
• Power user
  These are essentially regular users but with enhanced privileges for handling maintenance type tasks. P.SE moderators would be an example of power users.
• Administrator
  Are users with full rights to the system and can change anything that is exposed through the programming of the site. Your developers may or may not be Administrators for your production site.

Developers raise an interesting question about what rights to assign. In some cases, they need Administrator rights so they can fix the wrongs within the system (sorry for the pun). But most of the time, you don't want them logged in as Administrators but rather as power users or regular users.

One way to solve this is through the use of multiple logins. "JoeUser" can be their regular login when they aren't exercising their developer role while "JoeAdmin" would be their admin login. The Admin login can trigger auditing / tracking / etc... while the regular login wouldn't.

Having two separate authentication systems buys you nothing but headache. In addition to the reasons Jarrod laid out, here are a few more.

• It doesn't prevent regular users from logging in as admins. Regular users would have to know the admin's credentials before they could login as an admin.
• It doesn't increase your security. If anything, a dedicated, privileged authentication system makes it easier for attackers as they can focus on the one system and not worry about getting through as a lesser level user. IE. they cracked your admin auth system so they know they'll get in as admins.
• It makes authentication more annoying for your Administrators. Because they have to go to a different site to authenticate as an Admin, they are more likely to skip using their regular user logins and just stay logged in as admins. Not necessarily what you want.

So the answer is essentially this: Code up a single authentication / authorization layer. Create multiple logins for whoever needs Admin rights.