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
