> -----Original Message-----
> From: Mike Soultanian [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 04, 2005 3:24 PM
> To: CF-Talk
> Subject: Re: Question about my security system
>
> 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).
But you MUST have this. Your pages need to have them predefined to work -
however your label them, segment them, group them or whatever they must be
redefined and agreed upon.
> 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.
I think this is where I'm losing you. I see no difference between "groups"
and "tasks" in this.
I define a role of "admin" and give some people that role or I define a task
of "MessageEdit" and give some people the ability to do that - it's the same
thing. The underlying implementation is exactly the same for both, aren't
they?
If the template has to say:
If delete AND User entitled to delete
Delete
End if
Then it's using "groups" = the group is called "delete" rather than "admin"
or "editor" or what ever, but it's still a "group". Or, to reverse it:
things like "Admin" and "editor" are really just entitlements no different
than "delete".
> 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.
Yup. And that's all you're doing as well even if you don't know it...
whether you say "messageDelete" or "Delete on the message page" you're
really doing the same thing: setting up a specific entitlement.
One of abstracting this is via some kind of "context" parameter. For
example instead of "isEntitled(User, 'delete')" you might add a context
modifier such as " isEntitled(User, 'delete', 'message') where "message" is
a context for the entitlement.
In your case you might keep your current idea and still do this - the
context of the check would be the page:
isEntitled(User, 'delete', CurrentPage)
However I still think it's adding a lot of complexity to this for every
single page when a conversational abstraction works.
In the end this is really no different than just doing "isEntitled(User,
'messageDelete')" however.
> the requirement of knowing group or task is specifically what I was
> trying to pull out of the template-level code.
But from everything I've seen it's still there - isn't it? If you're
checking for a Boolean tag before doing something isn't that putting the
task into the template?
> > 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.
But again - I'm not seeing the difference between groups and entitlements
here. To me, so far, they're just two labels for the same concept.
> 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.
Sounds great - exactly what I've been talking about. ;^)
For this to happen the security service doesn't need to know that they're in
that template however, it doesn't need to know anything about the page.
Just that this user wants to delete a message, can he?
> 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.:
But again - this doesn't need to know about the template - just the task
"EditUser".
By linking the system to the template you seem to be adding a lot of
complexity that doesn't seem to add much (to me - all my probably uninformed
opinion).
Dropping the template from consideration you can just add a new entitlement
(for example "deleteUser"), assign some users to it and add the check to
your code.
Adding it to the templates means that you have to also register the
templates and there possible tasks - which doesn't seem to add anything to
me.
The entitlements don't HAVE to be per template so why bother going to effort
of making them per template?
> 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.
But from everything you've said you DO have to edit the template code!
That's the crux of what I'm missing here.
If you have to say "if canDelete" then you have to check - you have to edit
the template to check the entitlement in the spot where it's needed. You
have to know that entitlement at design time to check it.
I'm not seeing how I could add a new entitlement to a template without
touching the template... if you have a template that you want to add
"delete" to you have to edit it to add the check.
> 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.
But the template has to know everything you're talking about not putting in
the template to do any of this... I'm just not seeing it.
I know I'm missing the point here... I just know it.
> 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.
The system doesn't have to be simpler or changed. Basically anything that
you need to call the DB for you can cache in memory and eliminate the DB
traffic in trade for higher memory usage.
In your case, for example, just using cached queries might speed things up
tremendously compared to raw database calls.
> > 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.
Yup - from an architecture perspective RAM is always cheaper than bandwith.
;^)
> 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.
It could be dynamic via a mediator. All you really have to do is make sure
that the system that updates the database also checks the cache and updates
that as well.
This works really well on single system situations. The problems with it
come in when you have multiple systems accessing the same entitlements
database. Then to keep both fast caching and instant updates you have to
set up some kind of broadcast system (which isn't all that hard to do
either... it just adds complexity).
> 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.
Well... I think that would only be if you had 7,000 users logged in at the
same time (and if you did then the machine probably already capacity). ;^)
In my case I cache the information when they log in and then update a
timestamp every time the information is touched. A scheduled task runs
every 15 minutes and runs through the timestamps - any cache item that's
more than 30 minutes (or whatever you like) old is deleted.
Pretty standard cache management stuff.
But even if you did have all 7,000 cached and each user had, let's say 10kb
of entitlement data (which is, I think, a lot more than you'd need) you're
talking what... in the range of about 70 meg of data or so?
To save all of those database calls dedicating up to 100 meg of RAM to the
entitlements system seems like a pretty good trade off.
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:217335
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
