We are in the process of developing an application that requires an extensible security model. We have multiple user "types": Employees, Customers and Vendors. Within the Employees type, we have a variety of roles such as Sales and Administration.
The model we have been working with in the past is an extension of Csla with the concept of Groups added. So, a User is a member of various Groups each of which contains a list of Roles. So, a User's roles are determined by the composition of all the roles contained in all of the assigned Groups. Not to complicated.
From this, we are able to determine the type of user by simply checking their membership in a particular Group. However, each of these types encapsulates different information. For instance, one feature of the application is to allow HR to maintain an employee's file, which will include their benefits information - something not applicable to Customers and Vendors. Likewise, part of the process includes account information for those two groups, which is not applicable to Employees. Furthermore, a Customer's account is going to contain different information than a Vendor’s.
When the user signs into the application, we call the User.Login(username, password) method for authentication. If successful, the current principal is set as laid out in the Csla framework. How then do we connect this to the appropriate “profile” class (Employee, Customer or Vendor) so that we can gain access to that user’s profile information?
I failed to mention that a component of the application is that these users are able to sign-in and maintain their profile information, such as mailing addresses, phone numbers, etc. Employees are able to view benefits information, see how many vacation days they’ve accrued, etc. Customers may view their account information, make payments and so on. Vendors may submit bids, view their bid history and check on the status of their account (and pending payments). In order to accomplish this, we need some way to instantiate the proper object based on the user’s login information.
We have debated various ways to accomplish this such as implementing a common Actor object that “connects” the entities, using an if-else block based on the user’s group membership to instantiate the correct object and so on.
Our goal is to create a model that is extensible, allowing for additional types to be added, and can be applied to a variety of applications as this scenario exists in a number of our applications.
We realize that we are not reinventing the wheel. In fact, this situation is analogous to the way Active Directory and Exchange behave with respect to Contacts and Users. Without Exchange, you can create a Contact or a User in Active Directory each having its own set of properties. Integrating Exchange extends the User object with mail-enabled features so you essentially have a third type of entity (a User with a mailbox versus one without). When I sign into my network, AD knows that I have a mailbox assigned to my account and is able to obtain the mail-enabled properties for that user. We are looking to accomplish the same type of thing.
Thanks in advance for the suggestions and healthy debate. Your input is appreciated.
As quick as that another one pops up!
Since posting this earlier, another project has been presented where the client needs to handle the same type of scenario except this time it is using Employees and Contractors. As before, the Employee records contain additional HR information while the Contractor contains fields/properties specific to them. The wrinkle in this case is that the Employees information is maintained by their HR department in an Oracle database while Contractor information is managed by corporate admins in a SQL Server database. Two different data sources!
Copyright (c) Marimer LLC