One additional question on this approach ... who makes the calls to the security service? Does the controller make the calls and therefore it needs to know what rights are necessary for each method and without the controller the app is generally un-secure? The other option I see is putting the calls to the security service back into the objects, but then things are right back where they started.
Sounds to me that in order to keep the objects as pure as possible, the controller is going to have to be pretty smart one way or the other. -- Jeff -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Thursday, March 10, 2005 1: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]
