> -----Original Message----- > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Monday, September 05, 2005 5:35 PM > To: CF-Talk > Subject: RE: Question about my security system > > Here's the functional difference: > > I've provided an application to someone else (not myself), and I've > built in several roles. Now the other person, let's call him Bob, > decides that the 3 roles I've built into the system aren't sufficient. > If I've chosen to reference those role names in page, here are my > instructions for adding a role:
This isn't a functional difference... it's a convention. Your system only knows what's put into it. It's doesn't matter if you do it "at the factory" or Bob does it six months later. You've decided not to check roles in templates - you've already said that your system COULD check roles in templates. Your system doesn't stop people from checking roles in templates. It's by convention you don't. Don't get me wrong - it's a GOOD convention. I'm not arguing (as you seem to think I am) for (or against, actually) checking roles in templates. I'm arguing that the difference between a role and permission is by convention and not a systemic requirement. > > 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. > > It's not a matter of treating them differently... It's a matter of > their _being_ different. You can _treat_ them exactly the same, and > the end result will still be different behavior/consequences (see > above). EXACTLY! Now we're getting someplace! You can treat them exactly the same - the system can. The system doesn't require knowledge of your conventions! Well - to be clear, the enititlement checking system doesn't, the administrator system needs all sorts of knowledge of your conventions. > It's true they are labels, but they're labels for different things... > > What you're saying is that I should be able to come to you and say > > a) Here is the accounting department (bunch of people). > > b) Here is a member of the accounting department, currently > distributing a payroll check. > > a=b) The act of distributing (verb) a payroll check is not only > synonymous with, but exactly the same thing as the accounting > department (noun). You're reading too much into what I'm saying. You're arguing conventions and I'm not. ALL I'm saying is that the acts of CHECKING whether somebody is in the accounting department OR whether somebody can distribute checks are equivalent to the security system. That's it - read nothing else into it. The system checks, it says "yes" or "no". That's it. It doesn't need to know that one is a task and one is group (in my opinion). Is this person connected to that thing? That's all it cares about. > Labels for different things... that's why they have different labels. In the interface, sure. In the underlying system as well if you prefer - but it's not _necessary_ there by any means. > > 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. > > Umm... okay... but I don't write software that will do something I > consider to be a patently bad idea. But you do write software so that Bob can set up the system that makes the most sense to him (even when it doesn't make sense to you)... you're life is a paradox! ;^) > > 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. > > It doesn't bother you that this is a complete non-sequitur and makes > absolutely no sense whatsoever? I don't see it as such. > What you've said is > > "Anonymous is a child of admin, therefore an admin can read." > > More or less it's equivalent of: > > "Coliflour and brocoli are both vegetables, therefore carrots are > orange." Not at all. Anonymous is a child of admin. Therefore admin can do everything that anonymous can. Since anonymous can read so can admin. I may not have said it well (and thanks for being such a bitch about it) but the logic is perfectly sound. > > (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.) > > Nah... the per-page permissions for onTap applications actually makes > a lot of sense... Maybe... I can't say one way or the other, but I trust you. In my case however I wanted a loosely coupled security system. It could be dropped into a custom app, a fusebox app or whatever with very little impact. > Though it's not really technically "per page" it's "per process"... > and a process can have children... so... for example, if you have this That makes more sense (see my reply to Mike). "Pages" aren't what needs to be secured (in my opinion) - functions are (however they're included in the pages). > >> 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". > > Umm... okay, you just made an argument, I rebutted and you changed the > subject. Not at all - you changed the context. So there. Previously you said that to check permissions you need to just use a simple onTap function... so to add permissions you don't need to "write code" just to use this simple function? Or if it's contained in a process doesn't the process have to, at the very least, identify itself to the system to allow itself to be permissioned? How is an abstraction of code, however elegant, any less code? To add a new permission you have to either apply it to an existing thing (which has to have code in it to identify itself) or add the permission and then add code to the thing to recognize the new permission. This has to happen - the system doesn't read minds... does it? Because... damn, if it does then I concede right now. > Argument A) But you do have to create extra programming to add > permissions > > Rebuttal A) No, I can create permissions all day long without doing > any programming I apologize. I was talking about about creating permissions and actually having them apply to new functionality. I'll concede that you can create permissions all day long without doing any programming. > Subject Change + Non Sequitur) It doesn't matter if you have to create > extra programming to add permissions because my friend Jim won't let > people who aren't members of the accounting department distribute > payroll checks. What an asshole. I don't trust you no more. Ok. Let's say you've a process: editUser. Allows anybody in the admin group or moderator group to edit user information. Now time goes one and for one reason or another I want to add some granularity to this process. I want only admins to be able to change the user's email address, but moderators can still change everything else. How would I do this, using your system, without adding code? Now, before you get all bitchy on me again I don't mind that I have to add code. I've done something unexpected. I've forked a process that was originally dealt with only under one security context. I EXPECT to have to change code here because there's no way that the system could have predicted this need. This is the kind of change I'm talking about... not just slicing and dicing existing groups or shuffling existing processes. <snipped more assholeishness> > > I don't think a generalized security system needs to know > > more than that. > > Okay... I don't think a security system that's as generic as you > describe is really a worthwhile endeavor... It leads to more > programming work later for something that I could have just provided > the user with a tool to perform. I don't agree - but I think we already know that. In my opinion there are several distinct parts to this kind of thing: 1) Security Service. This service should be able to authenticate/store credentials, provide information about the user and store entitlement. It's the "engine" it handles the day-to-day operation of the security system. It should be as generic as possible. It should assume as little as possible about the system in which it runs and the access models that will be used by it. It's the referee monitoring and watching the action but getting in the way only when needed. 2) Management Model. This is the interface for working with the system as you've defined it. It's where you actually add data to the system. It needs to understand, intimately, your access model and rules. It prevents your users from breaking that model. There's no reason that a single security service can't support multiple management models in my opinion. 3) Developer API. This doesn't have to be a distinct "system" but sometimes is. This is the way your developers interact with the Security Service. It's the way they determine if somebody is authenticated or is entitled to do something. The Developer API can be closely linked to the management model or loosely linked. In some cases the same Developer API can be used with multiple management models. This is essentially the attitude taken by OSes like Windows. The NTFS security model is quite open at its core - just a simple set of services and a generic way to store data about inheritance and the like. The management model applies a lot of restrictions on its use however. Finally the developer API consists of some simplified methods (getUserID, isEntitled, etc). SiteMinder is set up the same way: a VERY open LDAP core which could support pretty much any kind of model. These system come with a pre-defined management model - but you could choose to adopt your own - the services support that. All of my comments have concerned the modeling of the underlying service, not the management model. Start with an open service and your management model will be supported, make assumptions in your service based on a single management model and you're limited from then on. Of course that may not be a bad thing for some... but I think it is. Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217406 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
