Help with authentication/authorisation design

rubyonrails-talk
1

Could someone help me with an authentication/authorisation design please?

It's for a car garage application that allows a customer to monitor the status of their car. Here are my requirements: 1. I need a heirarchy of 4 users:       A. Superuser (me)       B. Garage owner.       C. Mechanic.       D. Customer.

The superuser can create/edit/delete users A,B,C and D. The Garage owner can create/edit/delete users C and D.

2. There can be multiple Garage owners that own the same group of mechanics, and customers.

3. Authentication for garage owners and mechanics is an account number (that the application issues) and password.

4. Authentication for customers is based on their email address and password.

5. A single login form for all types of user.

6. A customer has visibility of the status of their car only. A mechanic or garage owner has access to all cars associated with the garage. And the super user has access to all cars in the db.

My plugins of choice for this would be authlogic and cancan, but I can't figure out a design that will represent the ownership of some users by other users, for example, that for a particular garage owner, get all the mechanics or customers.

I have tried several designs, but none seem to work. I would appreciate any help, advice or pointers.

Thanks

2

Not sure I understand whether the problem is capturing the business relationships in your Rails models, or applying your authorization frameworks to your app. Hope this helps a bit:

It seems to me you would want to associate your Customers, Mechanics, and Garage Owners to some sort of Garage model, and then navigating the association to get, for example, all the Mechanics or Customers for a particular Garage Owner becomes rather trivial. Of course, I may be oversimplifying here (for example, can a Customer be associated with multiple Garages? What then?). You would then use your authorization frameworks to limit access to the actions in your controllers, ensuring that only users of a particular role (Garage Owners), can list (access the index action on your controllers) all Customers/Mechanics/Cars associated to the same Garage as the Owner’s, for example. Also, since your application has several ‘faces’, one for each user role, it might be a good idea to use namespaces. Or, it may not, but it’s definitely something worth looking at, IMO.

regards,

Paulo Muggler

3

Thanks for the reply Paulo, my question was about the business relationships involved, and I think you went a long a way towards answering it.

With regards to a Customer being associated with multiple Garages, good news, this is not possible, they would have to have separate accounts.

Your solution is great, but it doesn't address all the problems. How would I handle a customer having ownership of their car only? Would I add a car_id to User that would be NULL for all users other than customers? This makes me uneasy, as the logic about the "roles" each user can full fill would be spread around. The roles I could apply in cancan would be restricted by the database data. Does that make sense? it just seems like cancan, and database would be highly coupled, is it a valid concern?

And how do I handle the superuser having ownership of all garages? I guess they would have a garage_id of NULL?

Considering that a "Garage" is essentially just a name, I was thinking that a preferable design would be to somehow model the relationships between the different types of user directly, but as I couldn't make that work, I am probably on the wrong track.

4

I think trying to model all those relationships solely in your user models will turn out way more complicated than adding a few extra models to your app to help capture those relationships. Your concerns about data coupling are valid, but at some point, you’ll have to store the information about which roles a given user may fullfill, and there’s no better place than at the user model itself, on the database, IMO.

In the case of Cars, a Car would belong_to a User, such that the association’s foreign key (User id) would be located in the Cars table in your db, and the User tables would not contain that information at all.

As for the superuser having a garage_id == null, I don’t think that is much of a problem, considering it would be a minority of the Users that would have that role.

One other technique you may consider is the use of class inheritance along your User models, for example, Customer < User, Admin < User, etc. This way, certain properties (garage_id, etc.) would be available only in some of the User subclasses. This has the downside of making things a bit more complicated at the db level, and your business logic would likely get more complicated too. Not sure if it would apply to your case, anyway, just wanted to point out that it is also a valid approach. For a first iteration on this problem, personally I would have those roles stored right in the User model (as a String), with methods to test for roles (user.admin?, user.garage_owner?(garage_id), etc., etc.

As a side note: design is always about compromise, every design choice has its ups and downs, and it’s up to the product designer (you) to weight in on the goods and bads and make the choices, based on what are your requirements, constraints, etc. Your concerns are valid, indeed, it shows you are considering the outcomes of your choices beforehand, which is generally a good thing. At some point, though, you have to make the cut and start experimenting, and seeing how things turn out. Especially when dealing with a business domain (or technology) not fully understood, trying out some of the options might go a long way helping you understand and decide which are best for your case.

regards,

Paulo

5

Thanks so much for your help Paulo, it's really appreciated.