Actually, Barney - you just nailed me on something! In my haste to paste that together, I was cutting and pasting code all over the place. In our actual application, we have exactly what you describe - a security service that performs both the authentication and access checks. Other than the possibility that I was severely over (or maybe under) caffeinated, I don't know how the UserManager component wound up with that set of responsibilities!
Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Thursday, March 10, 2005 2:20 PM To: [email protected] Subject: Re: [CFCDev] OO Security for the OO Purists You're absolutely right that moving the security to the controller is a bad idea. Which isn't to say that the controller doesn't need to help enforce security stuff, just that it should be the one implementing it. I also think that putting the security stuff in the user object is a bad idea as well, though the backing data does have to reside there. I usually have a security service in my apps that deals with authentication and what Roland calls "rights". So you can call secSvc.authenticate(username, password), or secSvc.isUserAuthorized(roleList, "create proposal"). The per-object permissions don't really fit that paradigm, however. For those, I use something like object.getRoleAccess(roleList). The roleList in both cases is (surprise!) the list of roles that the current user is in. Depending on your scenario, you may need additional parameters, such as a siteID if you're app runs multiple instance of itself with a single shared database. Both of those security questions are pretty abstracted, so they're usable from within your business model for checking things, and are also suitable for use by external [to the model] code, such as your controller, so that it can tell the view to render the appropriate links/buttons. Within your model, the "right" checking usually happens at the 'top' of the request: in the service object's service method. The "permission" checking, however, happens in a much less structured fashion, because it necessarily is bound to specific object interactions, and must be performed wherever those interactions happen. cheers, barneyb On Thu, 10 Mar 2005 12:46:09 -0600, Jeff Chastain <[EMAIL PROTECTED]> wrote: > > There has been some discussion recently about implementing security for an > OO application and Roland posted his method this morning which I am > personally very appreciative of. It is always nice to see an example. The > security scheme I am needing to implement is very similar to the one Roland > posted, so this is background info. > > ---------- > > To perform an action upon a given object, I have to have the right to > perform that action as well as access or permission to the object I want to > perform the action upon. For example, just because a sales rep. has the > right to create proposals and permission to do so for his company does not > mean he has permission to create proposals for another company. In the same > sense just because a support engineer has permission to access the server > room does not give then the right to change the configuration of a server. > > > So, for every action in the application, the following checks need to be > done: > - Does the user have the right to perform the given action? (create > proposal) > - Does the user have permission to perform the given action on this > object? (company 123) > > > ---------- > The question is, where are these checks performed as the answers to the > follow questions point in different directions ... > > - A user knows what his/her rights are, so it should be the one to state > if it has a given right? > user.checkUserRight( 'create proposal' ):boolean > > - Who better knows what rights are required for a given action than the > object those actions are being performed on, so that means that an > individual object should be the one asking the user if it has a given right? > > document object is passed a user object and calls the > checkUserRight( 'create proposal' ) on that user > > - An object has an access control list, so it should be the one to state > if a user has access to it? > > object.checkAccess( user ):boolean > > But, from an OO design standpoint, does all of this not put to much > responsibility in the user and object to know about security? > > On the flip side, all of this logic could be moved to the controller, but > .... what if I want to put an HTML interface and a Flex interface on an > application? The HTML interface could use a Fusebox controller, but the > Flex interface would access the objects via web services. So now, I am > managing security in an Fusebox controller and in a Flex controller and if > something needed changing (i.e. a right for a given method), I would have to > find and change it in multiple places, so this is no good either. > > Also, as components are basically an API, should the application that > utilizes the API have to know about security or should the API handle that? > > So, are there significant design or reusability issues in going one path > (internal object security) vs. another (security in the controller), or is > there another path all together? I am just about to the point of saying > there is no right answer and flipping a coin. Anybody else want to chime > in? > > Thanks > -- Jeff -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. ---------------------------------------------------------- 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]
