Interesting question. Off the top of my head here's what I'd do (someone please correct me where I go off base):
Create a security class/object that has both authentication and authorization methods. Authentication would determine if the supplied credentials (username and password in the example) can identify a user. Authorization would determine the user's roles and permissions. The user object would have methods that interface the security object. Document objects (and any other entities) could have calls to the security object that would determine if the accessing entity (user) has the correct authorization for the action. This could get a little complicated depending on how granular your security model will be. If you are using some framework/methodology/pattern with a central controller you could move the check authorization for actions logic to the controller. The benefits are that maintenance would be easier as it would be limited to the controller, and the entities in the system wouldn't need to worry about the security as it is handled by the controller. On Fri, 21 Jan 2005 08:28:42 -0600, Jeff Chastain <[EMAIL PROTECTED]> 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 -- -- Howard Fore, [EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
