Jim Davis wrote: > retrieve userlevel > > if userlevel=admin > Entitlements = delete, edit, post, read
> It's still the template that's protecting itself, not the security system > enforcing rules over the template. Ok, your version is a much cleaner example of the standard security system that most people employ. We're still on the same page here... > if URL.action=delete & isEntitled(UserID, "delete") > delete message > end if > > This is saying "I've got a user here that wants to delete - can he?" > > The complexity of the system is abstracted - the page needs to know nothing > about possible entitlements, just the one specific it needs. That's assuming that you have a defined set of entitlements. So, let's say the user logs in and the system loads up that user's entitlements. That list could be edit, delete, post, read (because they're a message admin). Here's the problem - what if there is a template called users.cfm for modifying user accounts. Now that user will also have edit, delete, post, and read access unless you differentiate the entitlement sets like: messageedit, message_delete, message_post, message_read, user_delete, user_edit. What I'm saying is that not every template on the site uses the same set of entitlements. While one template can perform one set of actions, another template might be doing something completely unrelated. > You can then use the same system for group-level checks. For example: > > if URL.action=delete & isEntitled(UserID, "admin,member") > delete message > end if > > This is saying that "if the person is a member of the admin or moderator > groups, let'em delete". Again, I am trying to pull any group reference out of the templates. I want the security system to do all the group lookups and cross-reference it to the entitlements that were registered in the DB for that given template and then let the template know whether or not it can go ahead and perform the requested entitlement. > The concept is exactly the same: a task-based entitlement like the first > just tends to result in more entitlements overall. Just like there's an > "admin" group with some members there's a "delete" group with some members. In my setup, I am not creating groups that mimic the entitlements. I am creating groups and then assigning those groups to different entitlements that the different templates require. > You can combine the two into groups and subgroups - this is closest to what > you have presented. So, the admin group has a sub group of "delete, edit, > post, read" and some of those items are also assigned to other groups (it's > a many-to-many relationship). Like above, you would have to create a subgroup for every possible different entitlement that all the various templates would require. Edit in the message.cfm template is definately not the same as edit in the user manager. > With this you gain the concept of inheritance. In your example, for > example, there's really no need to have the same permissions defined > multiple times. Instead have permissions inherited: Inheritance is definately something that I'd like to investigate further. I know that my example was very poorly written, but I'd definately like to optimize the code so it's using inheritance instead of brute force to figure out who's got access to what. After we get through this initial conversation, I'd like to further investigate your logic for how groups are inherited (the nitty gritty). But let's leave that for another thread ;) > The key is that all of that complexity (groups of groups, etc) is abstracted > away in a service-level component. You need to know the group or task you > want to perform ("delete" or "member") but that's it - you ask the system > "can he?" and it says "yes" or "no". the requirement of knowing group or task is specifically what I was trying to pull out of the template-level code. > But your template still needs to "know" about groups here. How is that > different than, say (let's say, to stick with your checking model, that > "entitlements returns a struct of Boolean keys): the template doesn't need to know about groups. That's handled by the security system which then tells the template if it's allowed to perform the requested entitlement. In other words, the message template asks the security system "I have a user logged in and they requested the delete entitlement, should I allow this?" and the security system checks to see if that user has permission to use that entitlement for the message template (this information would be stored in the DB), and then the security system returns a true or false back to calling template based on the permission settings. Let's say the user also hits the user management template, that template asks the system "I've got a user that wants to edit a user, should I let them?" and the security system will go and check to see if that user has permission to use that entitlement for the *user management template* because the user management template may have a different set of entitlements than the message editing template i.e.: message entitlements: edit, post, read, delete user mgr entitlements: edit, delete, copy, move > I still really don't see how that's any less complex that what I've > presented as the "standard model". You're adding a lot of complexity under > the covers to track file names when you really don't need to in my opinion: > the templates still need to know which entitlements they need (since they > have to check for them) and since they need to know there's no reason to > store them in the database (as least that I can see). Hehehe, that's the rub, it isn't any less complex, it's just more flexible by not having to edit the template-level code to tell it what it's allowed to do. It's all controlled centrally. My goal is to allow all entitlement/group association to happen in a GUI instead of having to edit the templates to say what a template is allowed to do. The only requirement for a template is to tell the system what entitlements are available for that given template so they can be registered in the DB and the security system will then allow you to assign permissions to each of those entitlements through a GUI. > The system as described is only database intensive if you let it be. > There's no reason that every call has to hit the database. Yes, obviuosly I could create a much simpler system that doesn't hit the database at all. But that would also require me to do more template editing when managing entitlements. Obviously there's going to be a big trade-off here, and I will definately have to see how big it is. If it completely stalls the entire application because it's too DB intensive, then I'll have to drop back to the standard system that most everyone else employs. I'm just trying to take the standard security model to the next level of flexibility. > In my system (and most others that I've seen) the standard practice is to > cache the user entitlements into a memory scope (either application or > session). That way the checks, even complex ones, can be made very quickly. > > Even if you don't drop the "page-level" permissions (which you really, > really don't need) you could still cache them as well - even for a largish > site the memory usage for this would be pretty small (say a meg or two) and > that resource usage would be nothing compared to constant database calls. That's a really interesting alternative. I create template-specific entitlements and then load all of those up into a session variable when the user logs in. And yeah, like you said, it's a quick check of that list to see if that user has the right to that entitlement. I will keep this idea in mind. You know, thought of an idea. I could still use the system that I described above. It would still register every template with the security system and that template's specific entitlements. Then, when a user first logs in, it will load up all the entitlements that the specific user has into a session list like you mentioned. So now, instead of it hitting the DB, it will just hit the memory. Not quite as dynamic, but it would definately be faster and memory's cheaper than a faster DB. I could probably make a flag for the security system to reload a logged-in user's entitlement list if the permissions were changed. I just wonder how big of a memory hit that would be if I have 7000 users with a pretty long entitlement list loaded for every user. It'd probably be smart to use some kind of abbreviation notation. Your definately giving me some great ideas here! thanks, Mike ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:217328 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