> -----Original Message-----
> From: Mike Soultanian [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 05, 2005 5:15 PM
> To: CF-Talk
> Subject: Re: Question about my security system
>
> Users are then assigned into each of those groups utilizing a
> many-to-many relationship. I can then assign groups to resources
> instead of assigning individual users to resources. This is standard
> windows administration practice because it makes for easier user admin.
> Now whether this is the best strategy for web app security, that's
> another thing, but I'm giving it a try anyways.
Gotcha. We're on the same page.
> Now, my basic system currently works like this. I have a table that
> stores all the files on my site (they are uniquely named) and what
> groups are allowed to access each of those files. When a user requests
> a file, my cf_security tag (which is inserted at the beginning of every
> template) does a lookup to see what groups are allowed to access that
> file and then if the user is a member of one of those groups, it allows
> the user to access the file. If not, it will halt execution and go to
> an "access denied" template.
I see the point.... but I'm not sure if I agree with the implementation.
What you talking about here is metadata: information about the file. By
putting all of this in the data base you're adding a level of complexity
that I just wouldn't be comfortable with.
The cf_Security tag has to be used (it doesn't have to be used in every
file, by the way, just a common include that's run for every request). So
you already have a requirement to put something in every file (or in some
common place) but let's say it's included on every page.
But you're also inheriting a need to make every file uniquely named (or else
moving files would be a nightmare) and this doesn't mesh with most web sites
(which use the same root for every directory).
You're also using a database which has no real connection to the file to
store important information about the file.
New files must be added the filesystem and then registered in the security
system. All changes will require a trip to this UI (and when you're talking
about doing this on the file level I'm not sure if that's any easier than
just changing something in the file).
The parallel of the Windows permission system (well... at least NTFS) is a
good one: the file permissions are maintained in the file or directory.
Move a file and it still has the same permissions.
There is no centralized database of file-level permissions.
In a, let's say "average" system, you might put your security groups in the
file:
isEntitled(User, "admin,member")
Which returns true if the user is an admin or a member.
This isn't a bad thing in and of itself, I think. The security information
is where I think it should be: in the file.
(Someday all files and directories will have the ability to store arbitrary
metadata similar to the ID3 tagging system for MP3.... then these kind of
things become easier.)
The think I think you're really troubled about it maintenance, right? The
issue of adding a group and needing to change the files and such?
Off the top of my head I could see two possibilities that would make me more
comfortable with the idea (and we all want that, right?) ;^)
One idea is to keep the information in the files, but centralize the
management of it. This is most like the Windows File System model.
Instead of you hitting a database and seeing what a file has you hit the
file, extract its security information from a standardized block and view
it. Changing permissions would just rewrite the file with the new
permissions (or any other meta data information you wanted).
Most source control systems already have this concept (they have the same
problem: the file systems won't allow you to add ambiguous metadata). They
add (or have the option of adding) meta data in a standard block to the top
of files. So your CF_Security might become this:
<cf_Security roles="" />
Or even this:
<!--- Inserted by the Security Manager --->
<cfset SecurityRoles = "">
<!--- Inserted by the Security Manager --->
<cf_Security />
(I'd prefer the former since it doesn't contaminate the page as much.)
But "roles" (or whatever you want to call it) could be managed centrally
(using the exact same interface you envisioned for the DB solution - only it
would be writing to the file system instead) OR at the file level if you so
desired.
This eliminates the need for unique file names. It allows files to be moved
around and such without losing information. It means that files could be
added without touching the interface or could be added and then security
managed via interface - whichever you like.
In this sense the security system (the actual running system) doesn't need
to know beans about files - only roles/permissions (which is the way I like
it). The files are still managing their own roles in this regard... but a
centralized system is managing the files.
The second thought is what to do about directories. I could feel a lot more
comfortable with your described model if I didn't have to manage things
strictly on a per-file basis. Instead I would much rather manage things at
mask level.
For example, instead of setting permissions (and having database rows) for
10 files in the admin section why not set permissions for
"/AppRoot/Admin/*"?
You might still set a permission for "/AppRoot/Admin/AddUser.cfm" (which,
like in Windows, would override the directory entries) but you wouldn't have
to.
Unfortunately there's no way to insert metadata information into a directory
like there is with a file... so either database or a file in the directory
would really have to hold the metadata.
This leaves you with the problems of moving content and orphaning the
loosely coupled permissions. But it would allow you a lot more flexibility
in the long run. Simple "Admin or everybody" systems may only need two
definitions while more complex systems can be as complex as they want.
> Now, the only real permission (using windows lingo) that any user has
> with my basic system is execute. They either have permission to execute
> the file or not.
True... although you might not want to limit it to that implicitly. You
might (and then again might not) want to add (or leave open the ability to
add) such permissions as "edit" or "delete" which could be leveraged later
at the template level.
Up until now we're golden (with a few niggling points on storage location):
this is how most systems work.
> Taking this a step further, I wanted to allow myself to assign other
> permissions (read, write, display, concatenate, jump, fly, whatever) to
> templates based on the actions that those templates might perform.
Gotcha.
> So, in the user template, I need to edit/modify/delete users, and in the
> message template, I need to edit/post/delete messages. I wanted to take
> those permissions and bring control of each of them into the security
> system and allow myself to assign groups to *each* of those permissions
> on a per-template basis to really granularize the system.
My issue with this is the idea of attaching the permissions to the files
instead of defining them as broadly applicable.
I really think you're going to have lots of cases of repeated permissions
and issues with portable code. For example: you let's say you have a
"deleteUser" permission.
This permission (duh) is needed to delete a user. Now, in good programming
practice you create an encapsulated, portable CFC/Custom
Tag/Function/Whatever to delete the user. That function, of course, checks
for that permission.
And that's the key to me: the function checks for the permission. The
function may be included in several pages, none of which really need to know
what permissions are required for it to do it's job - they just want to take
advantage of the "service" the component provides.
If you set up a generic "deleteUser" permission and check it in the function
the function can run anyplace and still work. If you require that the page
(which in most apps is a collection of portable components) know about it
then you msy both add the function (and know what's inside it) AND update
the security system.
There are also plenty of cases where the file name of the page doesn't
describe what's going on (Fusebox applications for example) - you're system
would have to include more than just filename to possibly work with such a
system. Again, you have templates which are included in other and THOSE
templates need the permissions, not the calling page.
This is really the crux of my issue - I don't see the need to link
permissions to the files when the files you're linking are probably not the
best place to check those permissions.
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:217395
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
