Help with authentication/authorisation design

Could someone help me with an authentication/authorisation design

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.

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

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

  3. Authentication for customers is based on their email address and

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

  5. 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.


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,
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
only users of a particular role (Garage Owners), can list (access the
action on your controllers) all Customers/Mechanics/Cars associated to
same Garage as the Owner’s, for example. Also, since your application
several ‘faces’, one for each user role, it might be a good
Or, it may
but it’s definitely something worth looking at, IMO.

Paulo Muggler

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.

I think trying to model all those relationships solely in your user
will turn out way more complicated than adding a few extra models to
app to help capture those relationships. Your concerns about data
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
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
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
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
your User models, for example, Customer < User, Admin < User, etc. This
certain properties (garage_id, etc.) would be available only in some of
User subclasses. This has the downside of making things a bit more
complicated at the db level, and your business logic would likely get
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
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
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
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
start experimenting, and seeing how things turn out. Especially when
with a business domain (or technology) not fully understood, trying out
of the options might go a long way helping you understand and decide
are best for your case.


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