Topic: Modeling authentication and users

My application requires 4 different kinds of actors:

- Proband
- Manager
- CCOperator
- Administrator

The only thing that they have in common is that they are human beings who want to use my applications. Their properties, associated objects and related business logic is totally different.

The application consists of four major 'subapplications':

- The b2c application (for probands)
- The b2b application (for managers)
- The ccconsole (for ccoperators)
- The admin console (for administrators)

As these subapplications share the same model and some business logic as long as other resources, it seems natural to implement all three 'subapplications' as part of a single Rails application.

The question is now, how should I efficiently separate authentication. Collapsing all my actors into one model hierarchy seems awkward, as they don't have too much in common. Separating them as first class objects complicates authentication and violates the DRY principle.

What are your ideas ?

Re: Modeling authentication and users

Hi,

I use the following approach, I authenticate my users(read actors) to the web site and then use an Access Control List for authorisation to allow them to perform different actions (read subapplications).

When my users are created I assign them a role (read actor) - which is then referenced in the ACL I mentioned above.

FYI: I achieve this by using 2 plugins, for example: see Acts As Authenticated http://technoweenie.stikipad.com/plugin … henticated
   

Hope this helps,

Steve.

Re: Modeling authentication and users

@Devonps: Can you explain you setup a little more (ACL) as I would be interested how you implemented this!

Re: Modeling authentication and users

devonps wrote:

When my users are created I assign them a role (read actor) - which is then referenced in the ACL I mentioned above.

Hello Devonps,

thx for your answer. Your approach is the obvious, but that although means that my users would have to be part of the same class tree, which is pointless as there are no other things in common.

Woyzeck

Last edited by Woyzeck (2007-03-23 10:15:34)

Re: Modeling authentication and users

How about creating 5 models. One for each kind of Actor and one generic User model. This means every actor will have two records: one User model and one for their role which holds all of their unique logic, attributes, and associations. Each kind of actor will belong_to :user and the User has_one for each of the roles. Does this make sense?

If you really don't want this shared User model then there is an alternative. Just make four models - completely separate. Each one can have "name" and "password" attributes for authorization. Yes, there is a little bit of duplication here, but I don't think it's that big of a deal if there's not that many shared columns.

If you're going with this second approach, the authorization may be a bit tricky. Since the user only supplies his name and password you need to search all 4 tables for a match. You can move all of this logic into a generic User module because it doesn't really belong in any other class/model.

Railscasts - Free Ruby on Rails Screencasts

Re: Modeling authentication and users

Hello Rynanb,

currently I have modeled this as 4 separate model classes, but I like the approach with the separated account data/user data objects. This makes sense. I'll give it a try.

Thx for your answer.

Last edited by Woyzeck (2007-03-23 12:22:47)

Re: Modeling authentication and users

leevigraham wrote:

@Devonps: Can you explain you setup a little more (ACL) as I would be interested how you implemented this!

Sure, here goes:

The plugin I use for ACL is here http://agilewebdevelopment.com/plugins/acl_system

In each controller I identify those methods that I want to restrict access to by identifying which role can access that method, example:

before_filter :login_required
access_control     [:index, :add, :edit, :associate, :remove] => 'admin',
             :list=> '(admin | user | moderator)'

As you can infer from the above code - this approach allows me a fair degree of flexability - whilst retaining a fair level of protection.

BTW: the before_filter method is implemented within the acts_as_authenticated plugin and when the two plugins are combined you can start to introduce different layers of security to your application.

Hope that helps,

Steve.