Authorization & Object Retrieval

Slayer posted on Monday, June 29, 2009

Hi

I have a editable USER object. Restricted users may not create or view existing USERS on the system, they may only modify their own profile.

I have CanGetObject and CanAddObject and CanEditObject methods on my USER object. For restricted users the CanGetObject must return false in all the cases, except where the user wants to modifies his or her USER profile. I dont want to return true on my CanGetObject method for these users. Any ideas ?

RockfordLhotka replied on Monday, June 29, 2009

This is a pretty common question.

The thing to remember is that the CanGetObject(), etc. methods are per-type, not per-instance. They are static (or in 3.5 and higher they are on Csla.Security.AuthorizationRules).

What you are asking for is per-instance authorization. To even know the rules, you have to have an instance of the object, otherwise you don't know if it is for the user or not.

There is no per-instance authorization concept in CSLA .NET at this time. I'm not sure there ever will be, for two reasons

1. It isn't clear how such rules could be standardized - they are clearly not just role-based or the per-type system would be sufficient
2. .NET has no formal concept of authorization - so anything I made up would be just as valid as anything you are going to make up - so I don't see where CSLA would provide value beyond what you'll do by implementing an instance method on your class

 

Henrik replied on Thursday, July 02, 2009

What you really have is two different use cases:

One use case is administrators (not-restricted users) creating/editing/deleting users in the system,
and the other is a user maintaining his/her user profile.

In my own systems I usually have two different editable root classes:

1. User (only accesible by admins).
2. UserProfile (can be accessed by any user, but can only load, edit and save data for the current user. This is ensured inside the class in DataPortal_Fetch where the current user's id, which I have in the current Principal.Identity.UserId, is added as a parameter to the stored procedure that fetches the current user's data).

Cheers
/Henrik

whelzer replied on Saturday, July 04, 2009

We override the Can methods so we'll have something like:

shared function CanAddObject() as boolean
  return isinrole("adders")
and

shared CanAddObject(obj as myBO) as boolean

select case obj.MyProperty
   case whatever
       CanAddObject()
   case somthingelse
       return false
end

Fairly sure (hope) I got this idea from the Forum...either way it works for us..