Business object based on security

Business object based on security

Old forum URL: forums.lhotka.net/forums/t/6380.aspx


dbrillon posted on Monday, February 09, 2009

Hi,

I would like to know how to extract my business objects based on the current user. Let me explain what I need to do.  Let say that I have business objects representing a fleet of vehicles.  Each fleet can have many garages and each garage has many vehicles.  The users are not allowed to see all the vehicles but only the ones in the garages they are assigned.  How could I implement this with CSLA.net.  Is there a way to filter the data retreived by the Fetch method of the DataPortal based on the security principal of the current user?

Thanks,

 

RockfordLhotka replied on Tuesday, February 10, 2009

I would think you'd do that sort of filtering directly in your SQL statements. So your data access code would do the filter based on information you have about the user.

User information is typically contained in the .NET identity object. You can create a custom identity object that contains information about the user, such as the garage to which they are assigned. To do this, create a serializable object that implements IIdentity, or that inherits from Csla.Security.CslaIdentity (that's easier) and just add your extra properties.

There are some sample apps in the Samples folder that show how to do this, and there are unit tests for CslaIdentity that also show some techniques.

dbrillon replied on Tuesday, February 10, 2009

Thanks a lot.  I will take a look at the sample.

 

 

SonOfPirate replied on Tuesday, February 10, 2009

In our case, we prefer to separate security concerns from what we consider to be profile information, such as the garage to which the user is assigned.  We use the Name property of the IIdentity object to retrieve the UserInfo for the current user.  The UserInfo object would have a Garage property (or a PropertyBag) containing the value for the setting.

While you can have the property on your custom IIdentity or IPrincipal object(s), we opt not to so that these objects are kept small.  If we did use these objects for profile information, then we would have to retrieve all of the profile values each time we authenticated, serialize/deserialize 'em and hold them in memory, etc. even if we had no use for the information.  In other words, by separating the identity and profile information, we only have to load the profile settings (which in our case can be large) when we need them.

Something to think about, anyway.  Hope that helps.

 

Copyright (c) Marimer LLC