RE: [CFCDev] OO Security?

[Roland Collins]

The user token is just a unique identifier in our system.  Under the covers, it corresponds to a user’s unique id in our database structure, but the end-user never needs to know that.  The identifier is actually returned from a call to “AuthenticationManager.loginUser(username, userPassword)” and then just passed around the system.  We could completely change what the user token is and what it corresponds to without ever touching our components just by changing the AuthenticationManager component.   Every user on our system has a session, even anonymous users, so checking for a session does not work on our system.  We have an actual “Anonymous” account to which a user gets assigned to before he logs in.  This allows us to grant rights to anonymous users, which is very helpful in a truly dynamic environment.  Not to mention, it breaks encapsulation if the AuthenticationManager needs to know that there is even such a thing as a session.   Roland   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GroupOne Dev. Sent: Tuesday, March 08, 2005 1:27 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] OO Security?   This is along the lines of what I was saying.  However, it goes one step further by refactoring and pulling that common functionality out of each object and putting it in a central place which is always a good thing. One question - what is the user token?  Could the authentication manager not check for a user's session?  If the session variable does not exist, they are not logged in.  If the session variable does exist, but they don't have the right 'right', then an exception is thrown.  Or, does this token do something else? Thanks -- Jeff From: "Roland Collins" <[EMAIL PROTECTED]> Sent: Tuesday, March 08, 2005 11:49 AM To: CFCDev@cfczone.org Subject: RE: [CFCDev] OO Security? All of our objects require a user token to be passed in and they then perform their own access checks using our Authentication manager component.  The authentication manager throws an “AuthenticationException” if the user does not have the appropriate level of access, and this gets logged, kicked to our error handler, or whatever else we need to do. It winds up looking like this (in broken code, anyway).   <cfobject name=”SomeObject”>   <cffunction name=”getAccountBalance”>             <cfargument name=”userToken”>             <cfargument name=”accountNumber”>               <cfset var accountBalance = 0>               <cfinvoke component=”AuthenticationManager” method=”checkUserAccess”>                         <cfinvokeargument name=”userToken” value=”#arguments.userToken#”>                         <cfinvokeargument name=”requiredRight” value=”NameOfRequiredRight”>             </cfinvoke>                         <cfdotheprocessinghere>               <cfreturn accountBalance> </cffunction>     </cfobject>   HTH, Roland     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GroupOne Dev. Sent: Tuesday, March 08, 2005 12:30 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] OO Security?   Nando - This is helpful.  The concept of a key ring with doors and locks is a good real world example.  However, in this case I am not sure a real world model is the best example.  If I were to do it this way, I would have two different 'keys' for a janitor ... one if the janitor worked on the 5th floor and one if the janitor worked on the 6th floor.  This seems like it could get very complicated in a hurry if you are working on a 40 floor tower. Instead, I am looking at a 2 tier model.  The janitor may have a key to the janitor's closet, of which there is one on every floor.  But, janitor A should only have access to floors 1 through 5.  Therefore instead of giving the janitor 5 different keys, we give them an electronic passkey that opens janitor closets on floors 1 through 5, but not on any other floor ... i.e. the combination of a janitor role (with associated rights) plus permissions to work on floors 1 through 5. This model seems fairly easy to implement ... a role object has one or more rights.  A user or group then has one or more roles in the system.  Then, each object (i.e. the janitor's closet) has an access control list that says which users have access to that object.  The role/right combination is a property of the user (a user knows his role), and the access control list is a property of the object (an object knows who can access it).  This way, things can get as granular or as generic as needed ... individual users can be given permissions to an object or the janitorial staff (user group) can be given permissions to an object. Assuming there is nothing in this model that I am overlooking, my biggest problem at this point is where the authentication and authorization functions happen.  At what point does the user get prompted to log in?  For example, the building lobby might be open to anybody that walks in and we don't want to check ID before you can even come in the front door.  Then, at what point does the user's authorization get checked? I think I am making this part more complicated than it needs to be.  Should an actual object need to know how to check if a user is authorized or should this functionality be moved up to the controller?  Thus, in the controller, when a user attempts to create a new document, the controller will first check if the user is logged in, then check if they have the editor role with the right to create documents, then check if they have write permissions to the folder they are attempting to create the document in. This seems to make more sense than trying to fit these checks into the user, document, or folder objects. Any thoughts or suggestions? Thanks for the help. -- Jeff ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org