Object Model Authorization - OO Design Question

Question

Background Each Project has one Account it is associated with. Each User can have permission to access zero to many Accounts. This in turn means that each User can only access a sub-set of Projects based on the User's Account permissions.

The User object is loaded up when the user signs in to the application, and Account permissions are loaded up at that point as well. That User object is stored in the application's cache. Projects are loaded on an as-needed basis.

Question What is the best way to enforce the Account limitations? We want it to be abstracted away from the actual presentation logic, but we don't think it's necessarily a good approach to put the authorization logic inside the Project object, because then it depends on the User object. What do you guys think?

Example: (aspx page code behind)

Project oProject = New Project(projectId); //Pass an Int32 here
if (oProject.Load()) //This operation needs to check user permissions somehow
{ /* Do stuff */ }

Answer 1

Then abstract away the user object also. Turn user objects into a collection of permissions you can query using a standard interface from the projects.

Answer 2

You could implement a class responsible for validating permissions against the project (i.e. do the permission check logic would live outside the project); e.g. In Java:

public interface EntitlementsManager {
   void checkProjectPermission(String userName, int projectId) throws SecurityException;
}

Then in your code you simply add calls to checkProjectPermission at the business layer before passing results back to your presentation layer. Granted this is a a fairly procedural (i.e. non-OO) approach but it's clear to follow as all your permission based logic is in one class. The exception based approach also means fewer if-then statements in your code.