A Twist on User Security

albruan posted on Friday, June 30, 2006

I'm in the preliminary stages of developing a replacement for a dBase III application for a client and have a question regarding user security since they're wanting something a little beyond CSLA's username/role security model. Basically, they are using a username/role security model with the addition of a third item/field named Department. With the client's existing application, each user is assigned a role such as administrator, estimator, manager, etc.; additionally, each user is assigned department(s) such as architectural, structural, electrical, etc. in which they're allowed to perform their job function. On top of this, a user may be a manager in the architectural department, but only an estimator in the structural department. So, the role table I need to create for this application would be something along the line of:

      User      Role      Department
   UserA      M         Architectural
   UserA      E         Structural
   UserB      M         Structural
   UserC      A         Architectural
   UserD      E         Architectural

Has anyone encountered anything similar to this and, if so, how was it solved?

albruan replied on Friday, June 30, 2006

I went back to the old forum and found that I could accomplish what I need by inheriting the BusinessIdentity and BusinessPrincipal classes and adding new properties for them in my new classes. At least I could if I were using CSLA 1.0 or 1.5; however, since I'm using CSLA 2.0 I'm not sure how to handle this since BusinessIdentity is no longer part of the CSLA framework.

Any suggestions?

Brian Criswell replied on Friday, June 30, 2006

For your principal, inherit from BusinessPrincipalBase. For your identity, your class definition would start with:
public class AppIdentity : ReadOnlyBase<AppIdentity>, IIdentity

The PTracker application has examples of these.

paul@citrusdev.co.uk replied on Sunday, July 02, 2006

Surely the department is just another twist on the role.

Can you not handle this solely using the orle based security model i.e. ElectricalManager. This preserves both the csla and microsoft way of handling security, it makes security for cross departmental functional far easier (role - "Managers").

Role based security, or even AD style group security all works on the same principle. It feels wrong to go against the grain with so much history behind the simpler model.

reagan123 replied on Tuesday, April 22, 2008

I'm bringing this one way back from the dead....

Has anyone else run into a situation like this were the user has different roles based on some third element? If so, what was your solution?

Thanks for any insight.

raz0rf1sh replied on Tuesday, April 22, 2008

Not sure if this will help or not, but in the environments that we write most of our applications for, it is VERY hard to put everyone in a specific role. We didn't want to define a bunch of roles that were specific to one or two actions.

What we decided to do was implement what we call checkpoints. These are specific permissions like Add User, Edit User, View User, Change User Password and so on. We added some additional properties to our BusinessPrincipal object to validate checkpoints and load all the Checkpoints for the user, similiar to the Roles.

This gave us MAXIMUM flexibility and allowed the customer to create Roles on the fly, and assigned Checkpoints to the Roles.

Hope this helps some,

Matt

reagan123 replied on Tuesday, April 22, 2008

Interesting approach Matt.. makes sense... thanks for the reply.

Here's a little explanation in general for my scenario. Basically we have your typical setup where a person is assigned to a group and a group has a list of roles.

This worked fine except that now a user can belong to many organizations... they may in a different group in each organization.

Currently, we display all of the Organizations in a treeview. We need to load the group for that specified organization when they click on the node. For example, if Joe is logged in and clicks on Organization1... We need to know he has "Admin" rights for that organization. If he clicks on Organization2, he needs to only have "Clerk" rights.

Joe Organization1 Admin
Joe Organization2 Clerk

Does that make sense?

Any other pointers or suggestions appreciated.

raz0rf1sh replied on Tuesday, April 22, 2008

Okay ... so there is one other thing that we do that I failed to mention! =)

Similiar to your organizations, we have multiple environments, in our case separate organizational units have to have their own database. So we create an Environment 1 for Company 1 and Environment 2 for Company 2. Each Environment has their own set of permissions, so the administrator can make sure users get the appropriate access based on environment. It's kind of a pain in the a$$ to manage, with many environment ... but it is very flexible ... and more importantly, it works.

In your case you might do something similiar. It sounds like your BusinessPrincipal would need to include the organizations and the permissions for each organization. The maybe have a method to authorize the role or checkpoint access but include the organization.

This is a bit of a variation on how we use our environments, but hopefully it gives you another idea.

Hope this helps,

Matt

MGervais replied on Tuesday, April 22, 2008

Matt,

I'd be interested in knowing how you solved this scenario. Our application will need to follow almost an identical path as you have described.

Do you keep a central User repository that tracks the databases a certain User has access to? If so, how do tell the application which database to access? If not, then is there any additional information you can share?

Thanks.