sorry spell checker messed up ... <clock> was suppose to be <cflock> ...
_____ From: Dusty Hale [mailto:[EMAIL PROTECTED] Sent: Thursday, May 10, 2007 2:46 PM To: 'discussion@acfug.org' Subject: RE: [ACFUG Discuss] preferred method for coding logins I was always under the impression that it was better to use client variable with the storage mechanism set to a database server with the thought being too much overhead session variables due to having to <clock> the session variables. Dean the 3X3 approach seems good. I'm a little confused how to check on "the object" level but I think I understand were to go on the "user" and "requested action". Thanks for your thoughts. _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean H. Saxe Sent: Wednesday, May 09, 2007 5:07 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] preferred method for coding logins Whoa, I could talk for days on this alone. A few thoughts: Authentication must take place on the server. All authorization information must also remain on the server, therefore it is always held in the SESSION scope. While I have immense respect for Hal, I find that method to be a PITA. Besides, it only addresses authorization to a specific function and not data. For good, strong authorization you must check 3 things, 3 times (3X3): Check: The User The object The requested action The user should have permission to take the action upon the object. You do this in three places: 1) Before allowing the user to see the option to perform <action> on <object> in the UI 2) When the user requests to perform <action> (e.g. view) the object (e.g. view acctID 1000) 3) When the user attempts to modify the object (e.g. delete acctID 1000). So, you have 2 levels of AuthZ: The first is large grained, does the user have permission to a URL or a set of functionality. This prevents privilege escalation vertically, e.g. a user becomes an admin. The second is fine grained, does the user have permission to a specific piece of information. This prevents horizontal privilege escalation, e.g. can user Dean see user Dusty's personal data. This is where most developers screw up and forget to check for permissions. AuthZ systems are easy to implement... incorrectly. Make sure yours is designed well up front to prevent problems down the road. And make sure it is USED in the code each and every time permission to perform some action on some object is requested. FWIW, this is an authorization (authZ) issue and not one specific to authentication (authN). If you want thoughts on authN, just ask. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] "If liberty means anything at all, it means the right to tell people what they do not want to hear." -- George Orwell, 1945 On May 9, 2007, at 5:00 PM, Dusty Hale wrote: As a part of the app I'm working on I have to code a permission based login system. I've written a lot of this kind of code in the past to pull from but I thought it would be interesting to ask if anyone has thought on current preferred ways to code logins. My thoughts are: What is the current preferred method of holding login information (variable scopes)? Client, Session, or Cookie scope.? In the past I've always used numeric values to assign specific permissions and the BitAnd() function to determine if a user has access to a specific permission. This was an approach that I learned from Hal Helms years ago. I wonder if there are newer more preferred ways of coding logins before I dive into this one or if I should stick to what I already know. I welcome any thoughts or opinions on the subject. Dusty ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink <http://www.fusionlink.com> ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
