I have a created a class called SecurityUser that allows those in an Administrators group retrieve, edit, update, etc the object. It follows the normal CSLA guidelines and examples for checking security. I'm OK with this object.
e.g. The following is the normal stuff you see...
public static SecurityUser GetSecurityUser(int id)
{
if (!AuthorizationRules.CanGetObject(typeof(SecurityUser)))
{
throw new SecurityException("some message here");
}
return DataPortal.Fetch<SecurityUser>(new SingleCriteria<SecurityUser, int>(id));
}
However, I have also created another class (SecurityUserSelf) for people to update their own account. This is specifically for those that aren't in the Administrators group but need to update their own profile. A very standard scenario. I wouldn't think that we would allow this object to be added to any Roles.
How do you suggest implementing security? I was thinking about something like this:
public static SecurityUserSelf GetSecurityUserSelf(int id)
{
// Get ID of current user. I have added an ID property to my custom identity class.
int currentUserId = ((MyCustomIdentity)Csla.ApplicationContext.User.Identity).ID;
if (id != currentUserId)
{
throw new SecurityException("Only allowed to update yourself!");
}
return DataPortal.Fetch etc....
}
And then the normal Save routine would be ok as-is, because we know that only an existing user (created by some other Admin) could retrieve their own account info using this object. I chose to check the user in the GetSecurityUserSelf() method instead of the Save() method to prevent unauthorized people from randomly viewing/getting other's accounts. Also, there wouldn't be a NewSecurityUserSelf() method, because all accounts have to be added by an Admin using the first class mentioned.
Thoughts?
This seems fine to me. In CSLA 4 you can formalize the behavior into an AuthorizationRule, but in 3.8 your approach is a good one.
Thanks Rocky!
Copyright (c) Marimer LLC