> -----Original Message----- > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Monday, September 05, 2005 11:30 AM > To: CF-Talk > Subject: RE: Question about my security system > > >> I'm sure that's how entitlements are differentiated in > >> Jim's apps (message_edit, user_edit, etc). > > > Nope. ;^) My apps are dumbasses. > > > The system just allows you make labels for things - you > > get granular and do tasks or generic and do groups or > > whatever - there's no difference in concept. > > > So far I've never needed more than generic "Admin", > > "Editor", "Member" and "Visitor". > > Ahh, so you just do the one thing I expressly avoid. :P
Ah - but that's the point: I do that, but the system I built does enforce that model. You could use the exact same system to set up task-based permissions as well - because functionality there's no difference. > > I know - I've led a sheltered life. > > > It's also a tiny bit frustrating that spent so long > > modeling and building this security system and all > > I've ever needed from it is a four-way switch. ;^) > > Yes you have... wow... I'd have thought there'd be enough red-tape at > a major insurance company to guarantee you abstracted the permissions > beyond that. Whoa there, buddy. This was never for work (we've not even upgraded from CF 4.5 there yet!) In any case had I built it for the office they wouldn't have let me open-source it. (For what it's worth the office uses SiteMinder for its enterprise security system. Along with a lot of one-off "tactical" systems which are all being (rightly) pressured to move to the enterprise system.) I've used this system on FirstNight.org and DepressedPress.com and several intranet projects. In all those cases there's been a lot of "public" material, a small slice of "members only" and a smaller slice of "admin only". Easy peasy. ;^) > > I'm having the same problem here: I don't see any > > conceptual difference between a role and permission. > > The difference is all in the labeling and physical > > concepts they represent, not the system level. > > Umm... no there's a pretty significant difference... > > Let me see if I can produce an example that illustrates it > sufficiently: <snip> > Does that make more sense now? Not at all. The question is not how to use them or how you might define rules to use them, its how a system would treat them differently. Or, more specifically why a system would need to treat them differently. You set up a "group": "admin"; you set a permission "DeleteUser". "DeleteUser" is assigned to "admin". Template developers are told to only check enititlements for the "deleteUser" permission. How is this different from: You set up a group "Admin". You set up another group: "DeleteUser". DeleteUser is a child group of Admin. Template developers are told to only check enititlements for the "deleteUser" group. In both cases all of these (groups, permissions, entitlements, roles, tasks, etc) are just labels - just labels which can be checked against a membership list. You may conceptually limit things (like in your example) to "super labels" (groups, roles, etc) which may contain "child labels" (permissions, tasks, entitlements, etc) or not limit it and allow anything to contain anything else... but in the end they're the same thing functionally: "Is this person assigned to that label (or a label which inherits that label)?" The concept of groups vrs permissions is a convenient convention, not a system-level requirement. You decide to call some things "roles" and some things "permissions" and you, by convention, only check for the latter - but they're both the same conceptually: just labels. This is my point. Your explanation makes PERFECT sense when considering the UI to maintain these things however - that's where such conventions are needed. They simplify the management of the system and reduce the complexity of using it. But you don't need to restrict your underlying system to that model at all. The system can happily keep all this on the same conceptual level via a many-to-many parent-child relationship and an current-implementation-defined "context" catagory. Such a system could be leveraged to do EVERYTHING that's been discussed here for the past few days. The system doesn't care. You want complex inheritance? Fine. You want simple "role-permission" inheritance? Fine. You want simpler group-only checking? Fine. Using the original "message board" and your example you might see: Label Context Parents ------------------------------------------------------ Admin Role Moderator Role Member Role Anonymous Role DeleteMessage Permission Admin EditMessage Permission Admin, Moderator PostMessage Permission Admin, Moderator, Member ReadMessage Permission Admin, Moderator, Member, Anonymous The "context" would inform your interface conventions (select by role or by permission). Or you might just leave "context" of and have a convention that all Labels without parents are "roles" and all those with parents are "permissions". You could leave it simple and say that all labels must be unique or you allow labels to have the same names (I assume each label would be linked with a description of the label). You could enforce matches (entitlement checks) by only name or by name and parent (enabling the contextual grouping I mentioned). The original system proposed (by Mike was it? Damn I'm bad with names) might use "context" to link permissions to pages. It might look like this: Label Context Parents ------------------------------------------------------ Admin Role Moderator Role Member Role Anonymous Role MessageURL Page Delete MessageURL Admin Edit MessageURL Admin, Moderator Post MessageURL Admin, Moderator, Member Read MessageURL Admin, Moderator, Member, Anonymous UserStuffURL Page Delete UserStuffURL Admin Add UserStuffURL Admin The first delete is in the context of "MessageURL" (probably its key actually) - so it will only be relevant in that context. Now, finally, to adopt the inheritance model for this same set of entitlements you might use this: Label Context Parents ------------------------------------------------------ Admin Role Moderator Role Admin Member Role Moderator Anonymous Role Member MessageURL Page Delete MessageURL Admin Edit MessageURL Moderator Post MessageURL Member Read MessageURL Anonymous UserStuffURL Page Delete UserStuffURL Admin Add UserStuffURL Admin Convesationally: Anoymous is a child of Member, Member is a child of Moderator and Moderator is a child of Admin. If an Admin wants to "Read" you would check the context (yes, we're on the right page) and then check the parent - it's "anonymous". But since anonymous is a descendent of "admin" admin can read. (I agree with you, by the way, that this can become way too confusing way to quickly - but the system can _support_ the concepts easily without having to implementing them. I also still think that adding per-page permissions needlessly complicates things.) My whole point here is that these labels are still all the same things, systemically: just labels. We've allowed them to be linked together in ambiguously complex parent-child relationships within the design of the sytem. We've given them, the concept of a context (which could be explicit or inferred from the relationships) However our interface, our rules for using the system, enforces limitations for the sake of maintaining our important, but ambiguous, conventions. > > But you do have to create extra programming to add > > permissions... so what's the difference? > > Umm... in most cases no I don't... The framework abstracts the > permission to an individual process and then checks permission > automatically... I do occasionally check the applicability of an > alternate permission (for something other than the current process), > but the system is designed such that someone who installs it elsewhere > can actually create new permissions to secure sections of my > application even if I didn't secure them, without writing any CFML. It's really no matter if you write CFML or not. To security something with a permission you need to know the name of it. That's the bottom line - whether that's abstracted or not you need to say "this thing here, only let people that can do that thing there in". > Moreover even if I am manually checking a specific permission within a > page, the page doesn't know anything about what roles are granted to > that permission, which allows the person who set up the app to I still say this is just semantics. You're checking a label and theres a lot of labels relationships that might come into play behind the scenes. But it's all just labels and conventions for grouping and checking them. I don't think a generalized security system needs to know more than that. Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217375 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
