Rails - May 2011 - Help with authentication/authorisation design

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

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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<http://stackoverflow.com/questions/119197/the-rails-way-namespaces>to
use
namespaces<http://guides.rubyonrails.org/routing.html#controller-namespaces-and-routing>.
Or, it may
not<http://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

On Tue, May 17, 2011 at 07:27, Pingu Penguin
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
> 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
>
> --
> Posted via http://www.ruby-forum.com/.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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.

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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

On Tue, May 17, 2011 at 12:19, Pingu Penguin
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
> 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.
>
> --
> Posted via http://www.ruby-forum.com/.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.