Hello:
I am a member of a team creating a .NET application, and we seem to have run
into an issue when trying to implement role based security.
Our application makes use of a fairly common (table based) security model in
which privileges are assigned to roles, which are then assigned users. So,
for example, the user "JSmith" may be assigned to a "SalesRep" role and as a
result have "Add Customer", "View Customer", and "Edit Customer" privileges.
Our privileges directly correspond with the CRUD methods of our classes. So,
if a user is attempting to view a customer, the following method would be
called:
public static Customer GetCustomer(Guid CustomerID)
{
// Retrieve role information for current user
RoleInfo roleInfo =
RoleInfo.GetRoleInfo(Thread.CurrentPrincipal.Ident ity.Name);
// Determine if role contains view customer privilege
if(!roleInfo.RolePrivilegeInfoCollection.Includes( "Customer",
"View"))
{
throw new SecurityException("User not authorized to
view a customer");
}
// Retrieve customer record
return (Customer)DataPortal.Fetch(new Criteria(CustomerID));
}
We have managed the security of many classes in this manner, and it has
worked quite well. Recently, however, we encountered a situation in which a
user may need to be granted an object privilege in one context but not in
another. So, continuing with the above example, it may be necessary to allow
a user to view all (or a subset of) customer fields if they appear on Form1
but not if they appear on Form2.
Because privileges correspond directly with object methods, this requirement
is (obviously) problematic - the current design only allows for one
privilege per object method regardless of the number of contexts in which
that object is used. Our dilemma is how to get around this limitation, and
we are considering the following solutions:
1. Create a different version of the customer object for each object
context. A unique set of privileges can then be assigned to each object.
2. Allow a client to pass the current context to a single customer object
when making a request. Security decisions can then be made based upon the
identity of the current user *and* the context in which the object is being
used.
3. Associate privileges with forms or more general tasks rather than entity
methods. Because security would be enforced at a higher level,
Customer.GetCustomer() could be accessed by the system regardless of the
context in which the object is being used.
4. Other options?
Has anyone else run into a similar problem? Rather than trying to "reinvent
the wheel", we would prefer to incorporate a proven pattern that won't get
us into hot water in the long run. I have had trouble finding any
discussion of these issues either on the web or in print and would
appreciate any input or suggestions. Also, any information on sites or books
that discuss these types of issues would be appreciated.
Thanks!
Chris
