I mostly use objects as data holders. They don't contain any methods related to security (or any other business logic). Instead there are "manager" objects that do that. There is a SecurityManager object that handles all aspects related to security: user authentication, data access rights, etc. Our security model is quite complex because a user can be granted rights on data by other users on the fly and rights can also be removed. By totally separating data from business logic we managed to create a relatively simple to understand and maintain SecurityManager object.

However I am not sure this is the best approach and I'm really curious about hearing other ideas.

On Fri, 2005-01-21 at 08:28 -0600, Jeff Chastain wrote:
How does one go about build a security framework using an object oriented approach?  The question I am getting at is that 'security' is not an object in the same sense that a user or a document is an object.
 
So, does a user object have an authenticate method that accepts a username and password?  Something about this does not seem right.
 
Along the same lines, does a document object have an authorize method that accepts a user or group to determine if they have access?
 
So, how does one handle security using an object oriented approach?
 
Thanks
-- Jeff

Reply via email to