RE: [CFCDev] OO Security

[jamie lawrence]

Hi Jim,   I have just read this thread and I am currently working on a system on which I think I could implement this. Would it be possible to have a copy of the code?   Cheers   Jamo   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Davis Sent: 21 January 2005 21:25 To: cfcdev@cfczone.org Subject: RE: [CFCDev] OO Security   I’ve done this in CF – but I’m not sure if it’s the “right way”.   In my case there’s a “Security” object that is instantiated by the application to be secured.  This the “gateway” object – calls for information go through it.   To “login” you would call the object passing your credentuals (user name and password, for example) and a unique key to identify the user’s security information (for example the CFTOKEN).  Either an error is returned or you’re successful.  If the latter an “authentication” object is created which represents the users current security session.   The user information is represented by three objects: a Credential (security system-level information), a Profile (personal user information such as name, address, phone, etc) and an Entitlement (a set of groups/action/whatever the user is permitted to do).  I split the object up simply to allow for the easy modification of the types.  For example a Forums system might need different profile information – my system allows you to specify a custom “profile” object to use without having to modify the “Credential” or “Entitlement” objects.   To get at that information you access the Authentication throught the main Security object via the user’s key.  For example you might say:   CurrentProfile = Security.getAuthentication(UserKey).getProfile()   FirstName = CurrentProfile.getFirstName()   To check entitlements you might do something like:   CurrentEntitlement = Security.getAuthentication(UserKey).getEntitlement()   if ( CurrentEntitlement.isEntitled(ThisGroup) ) { allow } else { deny }   The key for me is that the security system itself is completely self contained – you query the system with the user key to get any security-related information rather than embedding security-related processing in your application.  Because of this there are no restrictions on the security system – it works, for example, just as well in the server or the application scopes (or even non-persistent, but then, of course, it won’t remember anything).   The system also allows for relatively simple database modification (to use a different database you would create a new set of persistence “brokers” which only handle DB processes) and it supports things like three-strikes-and-you’re-out password validation and ban lists.   I’ve been very pleased with it so far.  If you’ve like the code, let me know.   Again, I’m not sure if it’s “right” (if there is such a thing) but once I got the concepts down it’s really helped me a lot.   Jim Davis     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Chastain Sent: Friday, January 21, 2005 9:29 AM To: cfcdev@cfczone.org Subject: [CFCDev] OO Security   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