> -----Original Message-----
> From: Mike Soultanian [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 04, 2005 1:27 AM
> To: CF-Talk
> Subject: Re: Question about my security system
>
> Jim Davis wrote:
> > It seems like it might be overkill to tag every single page (since then
> you
> > would have to provide permissions to every single page). Are your needs
> > really so complex that they can't be managed with groups?
>
> Well, I need the application to know what file is what because it is
> going to return structures with "rights" (think windows NT rights) flags
> back to the calling template based on permissions. So, let's say a page
> can post, edit, or delete a topic, when the page is accessed, it will
> check the current user's permissions and will set any "flag" variables
> (or rights) to the template and let the template know, for lack of
> better words, what it's allowed to do. Does that make sense?
Sure - in the lingo you're returned a set of entitlements. The user can "do
these things".
But I'm still not clear why each page has to be defined separately.
For example if you have three pages in a site which are part of the "add
user" function (let's say the three pages are "enter data", "verify data"
and "submit data") in your scheme you need to add three pages the system and
allow "add user" to all of them.
Instead it would seem simpler to create a role or group called "add user"
and have those three pages check to see if the current user has that role or
is a member of that group.
In most cases security is pretty flat... many sites only have
"administrator" and "visitor" for example.
In a roles based scheme you just add people to the "administrator" group and
pages which provide administrator functions make sure they're part of it.
Unless I'm misunderstanding in your scheme every page with administrator
functions will have to be defined separately and each user granted specific
access to every one of those pages.
> Like I mentioned above, the application will "tell" the page what it's
> allowed to do based on the permissions of the user logged in. How the
> system knows what permissions are associated with each different page is
> another portion I have not explained, but it's not really that important
> right now.
I'm missing something (it wouldn't be the first time!) If the application
"tells" the page... how is it enforced? Doesn't the page still have to 1)
know that the function in question is covered under that label and b) agree
to honor that restriction?
And, since that's the case, why would you store a profile for every page in
the site instead of just the roles? All the page needs to know is what the
user can do - the system doesn't need to know what the page can do.
> > I would probably not trust the CGI variables (which are web server
> > dependent) for this. Instead use the built in CF functions:
> > getCurrentTemplatePath() for example.
>
> Ok, now, my question here is if I use that function, what template is it
> going to return? Remember, this function is going to be called from a
> custom tag that is located within the Application.cfm file. So will it
> return the tag pathname, the application.cfm pathname, or the actual
> file that was requested by the user?
Actually in that case you'd probably want "GetBaseTemplatePath()" which
returns the path of the root template (the template called by the web
server).
> Also, why wouldn't you trust the web server from providing the correct
> file name to the CF server?
It's not that I don't trust it... it's just that I don't trust it. ;^)
If you're security system is based on this information then you really want
as little dependency as possible. Do it all inside CF and you don't have to
worry (as much) about people spoofing a web server path or something to
circumvent your code.
> > As for which is "more secure" - neither. Where you put your code has
> > nothing to do with the security of the system. The application.cfm
> solution
> > will DEFINITELY make the code more maintainable... and maintainable code
> is
> > less buggy than un-maintainable code.
>
> I think what I meant to say by secure was is there a way to get around
> my tags. You kinda answered my question when you suggested not to trust
> the CGI variables.
Well - in either case there's a chance. Whether you link the tags from the
template itself or from application it doesn't really matter.
Remember that Application.cfm is really just an "auto include" - it runs as
part of the template when you hit a page of the site. Anything that could
compromise it could compromise any custom tag and vice versa.
> In regards to everything you wrote explaining your security system (I
> won't quote it all), there is one thing which I don't think it addresses
> which is specifically what I am looking for:
>
> In all the security systems that I've seen so far (even the built in
> one), they only assign permissions to files. Whether it's done by
> groups, roles, whatever, it still only says who can access a file. It
> doesn't really address the fact that pages and perform multiple duties.
> One thing I refuse to do is hard-code stuff like:
>
> if admin
> let me delete this message
> if moderator or admin
> let me edit this message
> if user
> i can't do crap
> endif
But this is the way things is done - amd I don't see how your system will
get around it. In fact is seems much more complex than that.
For example consider your example: what if your PAGE is defined as being
able to delete and edit a message but your USER is defined as only being
able to edit one?
Then your logic something like:
If I can delete
If user is admin
Let user delete
If I can edit
If user is admin or moderator
Let user edit
The page would have to use logic like the above to handle this, wouldn't it?
And if it doesn't then why bother with the per-page permissions?
> I want my system to be completely dynamic such that it will keep track
> of what functions (or entitlements like you called it) each page can
> perform (like my example with the message posting page above), and who
> is allowed to perform each of those functions for that page.
But how does the system prevent a page from doing something it's not allowed
to do? It can't. If the page says "what can I do?" and the system responds
"you can edit a message"... well, there's nothing stopping the page from
deleting the message, is there?
The system can't mistrust both the user and the template - it has to trust
the template not to do something it's not supposed to.
It's much simpler to assume that any page in the site can do ANYTHING. But
that the pages will ensure that the users have the entitlements to do
certain things.
> Ok, nevermind, you can ignore my questions about putting the tag in the
> application.cfm file. I still have to put it in the top of each file
> because it's in that tag that you specify what rights, or entitlements,
> that page has and then those rights are registered with the application
> and then assigned permissions.
>
> Then, when that page is requested by a user, the system checks to see if
> that user has permissions to access the file *and* what rights the user
> has permission to. Based on those permissions, the application then
> tells the calling page what it's allowed to do. Does that make any
> sense at all? I can rewrite it out if you're curious.
But why bother with the per-file shtick? Why doesn't the system just let
any page have access to the whole list of what the user can do? The page
can say "Can the user edit?" or "Can the user delete?" What you have sound
more like "Can the user delete because if he can I might want to delete, if
you let me?"
But this is easily answered just by "Can the user the delete?" If the page
checks the entitlements system and finds the user can delete it provides the
delete functionality, if the user can't it doesn't.
I still feel that the matter falls down to enforcement. The system can't
enforce the dictate of what the page can do, so why have it? The page must
cooperate and either allow or disallow the user access.
So I've a page. I write it and it allows somebody with "Admin" permissions
to "delete" a message. Later I add the ability to for somebody with "Edit"
permissions to "edit" a message.
Your system says that to do that the change would have to be registered.
However what's stopped the page from ignoring this and just doing it? What
does tracking this page level buy you?
If the page is "in charge" in the end because its adherence to the security
system can't be enforced and it adds a lot of complexity to your system why
bother doing it?
I'm sure I'm missing something here... I'm not trying to be a jerk (that
comes naturally) but I'm just not seeing any value to a per-template
entitlement scheme.
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217319
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
