Help with authentication/authorisation design

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

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

  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.

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
ideahttp://stackoverflow.com/questions/119197/the-rails-way-namespacesto
use
namespaceshttp://guides.rubyonrails.org/routing.html#controller-namespaces-and-routing.
Or, it may
nothttp://blog.philburrows.com/articles/2008/05/02/rails-namespaces-rock-rails-namespaces-suck-/,
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.