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?
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?
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.
P
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.
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.
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.
Copyright (c) Marimer LLC