Help with CSLA Security

dantruj posted on Tuesday, February 12, 2008

I have a question of design or best practice on using the CSLA security (CanAddObject, CanEditObject ...). The methods are static and check against static roles listed in the database. IsUserInRole("Admin"). But what if all your users are the same but should only see their data? User1 and User2 can both be Admins in applicationA, but I dont want User1 to see User2's data. I know that the stored procedures should only return UserA's data when userA is logged in, but what if UserB calls a page page.aspx?Id = 20 and Id = 20 belongs to UserA? I have encrypted the query string and this should not happen but what if? How would the static security methods handle this situation? or should they? Maybe I should call a method called IsUsersData() which checks if the current user in context is the same as the user who created the record loaded in the BO. But this depends upon the UI making this call and the BO would not enforce this. Does anyone have a similiar problem or any suggestions on how to handle this sistuation.

webjedi replied on Tuesday, February 12, 2008

I'm just spit-balling here and while I am thinking it through there's an element of stink to it so keep that in mind. What if you define the role they are in as their login User1 or User2 in your membership provider and then check the context when you are in the CanEditObject do like:

IsUserInRole(Context.UserName.ToString());

Can recall the syntax of retrieving the context user name at the moment (in Microsoft Server 2008 Marketing Haze at the moment).

Though as I said eariler something seems wrong about accessing the context in the BO like this.

dantruj replied on Tuesday, February 12, 2008

That's funny I did do something kinda like that. Except I made the security methods instance methods and not static. Then I did get the current user from context, then compared against the instance property (field) for the user who created the record. It works, but I wonder if this is the correct way to handle this. If the security methods are static and their roles that they access are static, then how do you handle the case of instance security?

webjedi replied on Tuesday, February 12, 2008

Just realized my pseudo example would always yield a true in the scenario described...lol...so don't do it my way.

Like this would be *better*:

IsUserInRole(_createdbyuserid);

dantruj replied on Friday, February 22, 2008

But if the CanAddObject(), CanGetObject(), CanDeleteObject() and CanEditObject() methods are static methods then you can't have the _createdByuserId instance field in those methods, right?

JoeFallon1 replied on Saturday, February 23, 2008

1. Yes the SP should have and ID parameter to return only the current user's data.

2. You should not pass the ID on the Query String. If you encrypt it then it should work fine. No one is going to hack it.

3. But there is no need to pass the ID. You already have it on every page. It is in the Custom Principal object which you used to authenticate the user. Simply pull the principal off the thread or out of Context and read the ID directly.

Joe