Should distinct parts of a system share the same login?

Question

So let's say we have a web application for an autoshop.

The employees use this application to keep track of cars and other related work as it moves from checkin to diagnosis to repair, and then back to the customer for billing.

The customers use this application to check on the status of their cars, request extra servicing, and get an invoice for the work performed.

Also, the autoshop doesn't do everything right in house, and has a few specialty contractors in the areas. Sometimes a part or an entire vehicle will be shipped off to a contractor for a few days before finally being returned for final repairs. The contractors also use this application to be alerted of new jobs available for them (they have to go by and pick up cars every morning), make notes on how the repairs are coming, and then mark down that the cars are done and should be returned.

Three very distinct groups of people use the application for different but related things. The employees can see most data in the system, but the customers should only see things relating to their account, and the contractors should only see things about the cars currently and previously assigned to them. All of them need to be able to access the application from anywhere.

I'm wondering, would it be a good or bad idea to treat this as one application with one url, which, depending on the user permissions, takes them each to a very different section of the site? Or are there issues I haven't thought of?

Update: For people thinking about permissions/authorization, I should mention that this application becomes more complicated in that regard. This autoshop also handles fleet maintenance for a few companies, and thus a single customer may have multiple logins associated with it: the accounting office has one login that lets them only see invoices, where as a different office can only see the repair/maintenance reports, and should not be able to see invoices.

Contractors have a similar set of special authorization rules.

Answer 1

Don't confuse Authorization with Authentication.

• Authentication: validating who the user is.
• Authorization: deciding what a known (authenticated) user can see and do.

Logging in is your authentication, and assigning users to roles (as Benny already pointed out) is the most efficient way to handle authorization.

Answer 2

Having one identitet provider in one application instead of three greatly reduces maintenance cost. So if you don't need data isolation, for whatever reason, this is your preferred architecture.

To solve the employee, customer and contractors different use of the system you should implement roles. Employees are part of the employee group which has permission to the parts of the system they need to perform their work. The same goes for customers and contractors which have separate groups. In governance you add or remove employees when new are hired or when one quit. But employees that don't work there anymore aren't deleted to keep track of older transaction logs. New customers are added to the customer group and new contractors are added to the contractors group.

Most important to remember: Set permissions on group, never individually.

Answer 3

It seems to me 3 distinct but interrelated roles (employee, customer, contractor/partner) are obvious and I think it's easier to manage that with 3 distinct applications, and 3 distinct URLs. I say 3 distinct applications but under the covers they wouldn't necessarily be very segregated, they could share much of the underlying plumbing, but on the (user facing) surface (UI styles and URL semantics) my impression it would be best to make 3 facades.

For the purpose of example let's assume you have the domain name "autoshop.com".

Consider this: employees logins see everything with a blue background and domain names starting with "internal.autoshop.com", and customers see everything with a green background with the basic domain name "autoshop.com", and contractors see a yellow background and URLs starting with "partners.autoshop.com". Even if all these access routes go to the same content it's important to keep them distinguished by role. One important reason is that employees might legitimately access a customer view or partner view and the fact that it's a customer or partner view should be readily apparent.

There are many reasons to maintain this separation of roles (and the surfacing of this separation through styles/facades and URLs), and I can't identify them very well without knowing more details, but the bottom line is, planning for the future, it's easier to integrate separate roles (or facades that show roles) than it is to segregate them, or break them up.

Answer 4

In my experience, it's much easier to use one system and then just create different groups and then give them different permissions. I was working on an admin data entry system and we wanted to create a new system for outsourced workers to work on (with fewer fields, more instructions and less authorizations). So we kept our system and interface for us and made a new one from them.

If I had to do it over, I would have just used the one interface and created different user groups.

Here are just a few of the problems we had because we separated them:

• More work do updates on both systems when something changes
• Difficult to make sure fields have the same requirements & checks
• Hard to get people to change from one system to the other if needed
• A pain to troubleshoot since sometimes something functioned on one and not the other

If you make one system with different default tabs displayed for different groups, it would work just fine and make your life much easier in the future.