I think this can become easier if you implement a services layer in your application... you simply build an "authorizationService", whose sole purpose is to determine whether a user has rights to perform a specific action. Then other application services can ask the authorizationService "can user bob make a change to artifact a?"
The nice thing is that you don't pollute the rest of your application with references to roles and permissions... it's all controlled in one spot, so if in the future you want to modify the way authorization is defined (maybe now you want to use LDAP groups instead of roles in your database), you are ONLY modifying the authorizationService and the rest of your application has no idea. This isn't necessarily the most "OO" way to implement security, but I think that in the real world it leads to a more maintainable app. You can check out Tartan, which is a comprehensive framework for managing CFC-based services, and also my little pet project, coldspring, which has similar goals (but probably a bit more narrow in scope). -Dave >>> [EMAIL PROTECTED] 3/7/2005 10:23:55 PM >>> To better clarify this question, I have read the article by Hal Helms (http://www.halhelms.com/index.cfm?fuseaction=newsletters.show <http://www.halhelms.com/index.cfm?fuseaction=newsletters.show&issue=052203_ rolesBasedSecurity> &issue=052203_rolesBasedSecurity) regarding the roles-based security. This is the type of security implementation that I am trying to implement .... a role (editor) has one or more rights (createDocument, editDocument, etc.), and a user is then assigned to one or more roles in the system. The part I am needing to add to this model is that the specific user may not have the permission to edit a document everywhere in the system. This user might be part of the marketing group which has permissions to edit documents in the marketing area, but not in the engineering area. So, I am adding one more layer of complexity to the security model. In addition, I am trying to implement it upon an OO model and all of discussions of this implementation that I have found are either totally abstract or are applied to a procedural app. How would one define this in an object oriented fashion? In other words, from my earlier post, which objects know about security and how to manage/check it? Hopefully this puts my question into a better context. Thanks for any help or pointers. -- Jeff _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Chastain Sent: Monday, March 07, 2005 7:13 PM To: [email protected] Subject: [CFCDev] OO Security? Can anybody point me to an object oriented approach to security? I am looking to implement a role based security approach on a new application in which I am using an object oriented model developed with CFCs and a controller/view developed using FuseBox 4. I have two general questions with this approach. First, CFCs and specifically <cffunction tags have the roles security attribute. Utilizing this appears to require setting up security using the <cflogin etc. tags. This is not a problem with the exception that all of the examples I can find are showing these tags utilized in a typical procedural fashion. This leans me into the second question ... which objects know about security and how to manage it? Does a document know how to determine which users have what level of access to it or does a user object know all of the permissions that user has? At what level to methods like authentication and authorization come into play? Does anybody have a real obvious explanation on setting this up or know of any examples/articles I can go look at? Thanks -- Jeff ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
