RE: [CFCDev] OO Security?

[Roland Collins]

Not a problem – I can breeze with you if you like (and anyone else who is interested).  Let me know and I’ll set up a meeting room.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GroupOne Dev. Sent: Tuesday, March 08, 2005 3:50 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] OO Security?   Roland - You actually just decribed what I am trying to build exactly.  To simplify ....      A user/userGroup has one or more roles.      A role has one or more rights.      A user/userGroup then has permission to one or more objects (via the ACL). If effect, the role and the userGroup are really the same thing ... a userGroup that has a role is just a nested group.  It is just an easier concept for some to grasp that this user is an 'editor' rather than the fact that the user has 'createDocument', 'editDocument', etc. rights. I follow the db tables, but would be interested in seeing more of your model if you are willing to share.  We can take this offline if need be. Thanks -- Jeff From: "Roland Collins" <[EMAIL PROTECTED]> Sent: Tuesday, March 08, 2005 2:30 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] OO Security? In-line comments J   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GroupOne Dev. Sent: Tuesday, March 08, 2005 2:34 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] OO Security?   There you go making a mess of things again ;-) If you are trying to simplify the API (which does not sound bad at all), does the calling app still not need to know about users in order to pass the user object or the user's id value into the API method call?  This sounds like at least this level of security (whether the user is logged in) is pulled out of the API and into the controller either way. The calling app does not need to know about user, actually – all it needs to know is the user token, which it retrieves from a “login” call.  It doesn’t need to know anything about what the token relates to or what the token is since all of the logic that actually deals with the token is contained in the AuthenticationManager, and the only method the calling app _ever_ needs to call on the AuthenticationManager is “loginUser”. Having the object or the method know what rights are required does make sense and that is probably why Macromedia added the 'roles' attribute to the <cffunction tag.  The problem is that while this could allow for automatic checking of roles/rights, it does not allow for checking of permissions ... just because you have the right to create a document, do you have permission to do it here?  So, there would still have to be some logic either in the controller or the method to do this check. Well the model that I explained is greatly simplified from what we actually use internally ;)  Internally, our “rights” apply to operations that you can perform in the system.  Each actual “object” (and by object, I mean accounts, documents, forums, etc., not the actual CFC Objects) also maintains a separate ACL which describes which users and groups are allowed to access it.  So in our model, you first need to have the right to perform a certain type of operation, such as retrieve an account balance, and then you also have to have been granted access to that particular account.  In order to simplify this, we use groups (or roles, if you want to call them that), to which users and rights can be assigned, and then these roles can also be assigned to individual objects.  It’s fairly complex in terms of implementation, but the UI for it is actually very easy to use and the concept of “groups” and “rights” has been extremely easy for our end users to grasp.  Our basic groups and rights data model is attached if it helps any.  Keep in mind that there are also a similar set of tables for object-level permissions, such as account_groups and account_users, that I have omitted from the diagram so as to make it easier to visualize. All I wanted was one definitive answer .... of couse I cannot remember when I last got one when talking oo programming. If there was a single definitive answer, we’d all be out of jobs ;)   ---------------------------------------------------------- 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