>> -----Original Message-----
>> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
>> Sent: Monday, September 05, 2005 11:30 AM
>> To: CF-Talk
>> Subject: RE: Question about my security system
>>
>> >> I'm sure that's how entitlements are differentiated in
>> >> Jim's apps (message_edit, user_edit, etc).
>>
>> > Nope. ;^) My apps are dumbasses.
>>
>> > The system just allows you make labels for things - you
>> > get granular and do tasks or generic and do groups or
>> > whatever - there's no difference in concept.
>>
>> > So far I've never needed more than generic "Admin",
>> > "Editor", "Member" and "Visitor".
>>
>> Ahh, so you just do the one thing I expressly avoid. :P
> Ah - but that's the point: I do that, but the system I
> built does enforce that model. You could use the exact
> same system to set up task-based permissions as well -
> because functionality there's no difference.
Umm... yes there is...
Here's the functional difference:
I've provided an application to someone else (not myself), and I've
built in several roles. Now the other person, let's call him Bob,
decides that the 3 roles I've built into the system aren't sufficient.
If I've chosen to reference those role names in page, here are my
instructions for adding a role:
1) Open Dreamweaver (or your preferred editor)
2) Find all the templates you want the role to have access to
3) modify the line where the user's roles are checked
4) save those templates
Viola! You can now no longer upgrade to the latest version of my
software easily.
Comparatively, if I only reference the individual permissions in-page,
here are the instructions to add a new role:
1) Open a browser and log in to the application
2) go to the admin section and add your role
a) select the checkbox next to all permissions you'd like the user to
have
3) press the save button
Viola! No modifications to code = no hassles when you upgrade.
You've not had to deal with these issues apparently because you've
only used your security system on clients for custom site/app work
which doesn't get resold, i.e. the code for FirstNight belongs to
FirstNight (nevermind who holds the copyright) -- nobody else gets it.
>> > I'm having the same problem here: I don't see any
>> > conceptual difference between a role and permission.
>> > The difference is all in the labeling and physical
>> > concepts they represent, not the system level.
>>
>> Umm... no there's a pretty significant difference...
>>
>> Let me see if I can produce an example that illustrates
>> it sufficiently:
> <snip>
>> Does that make more sense now?
> Not at all. The question is not how to use them or
> how you might define rules to use them, its how a system
> would treat them differently. Or, more specifically why
> a system would need to treat them differently.
It's not a matter of treating them differently... It's a matter of
their _being_ different. You can _treat_ them exactly the same, and
the end result will still be different behavior/consequences (see
above).
> You set up a "group": "admin"; you set a permission
> "DeleteUser". "DeleteUser" is assigned to "admin".
> Template developers are told to only check
> enititlements for the "deleteUser" permission.
> How is this different from:
> You set up a group "Admin". You set up another group:
> "DeleteUser". DeleteUser is a child group of Admin.
> Template developers are told to only check
> enititlements for the "deleteUser" group.
See above. I'm not writing software just for other developers -- I'm
also writing it for non-developer/non-programmer users, some of whom
will be administrators with the permission to change what
privileges/tasks/rights/entitlements belong to what groups of users
(roles). If I put references to the group names in page, then I've
suddenly limited my target audience to writing software that's
significantly less versatile because it requires a programmer to
change roles.
> In both cases all of these (groups, permissions,
> entitlements, roles, tasks, etc) are just labels
> - just labels which can be checked
> against a membership list.
It's true they are labels, but they're labels for different things...
What you're saying is that I should be able to come to you and say
a) Here is the accounting department (bunch of people).
b) Here is a member of the accounting department, currently
distributing a payroll check.
a=b) The act of distributing (verb) a payroll check is not only
synonymous with, but exactly the same thing as the accounting
department (noun).
conclusion c) Therefore I don't need to distribute payroll checks: all
I need is to have an accounting department. Whether the accounting
department distributes payroll checks is neither here nor there --
people can get paid or not, doesn't matter. Therefore stop paying
payroll, because we have an accounting department.
----------
In the physical world, the act of distributing the check (verb) and
the semantic grouping of employees (noun) in the accounting department
are separate. So why would I want to create a digital system which
blurs that distinction or worse completely eliminates the distinction
between two things which are distinct in our physical reality? And I'm
not talking about using physical metaphors for computing problems,
like making an interface have pages because you called something an
"address book". These are in fact distinct entities with distinct
Aristotelian final causes. The final cause of the accounting
department is to have a group of people to handle accounting tasks.
The final cause of distributing payroll checks is to pay your
employees. These are very specific, distinct and different things.
> You may conceptually limit things (like in your example)
> to "super labels" (groups, roles, etc) which may contain
> "child labels" (permissions, tasks, entitlements, etc)
> or not limit it and allow anything to contain anything
> else... but in the end they're the same thing
> functionally:
> "Is this person assigned to that label (or a label which
> inherits that label)?"
> The concept of groups vrs permissions is a convenient
> convention, not a system-level requirement.
No it's not a system requirement. But I personally don't consider any
system which doesn't use this convention worthy of my time.
> You decide to call some things "roles" and some
> things "permissions" and you, by convention, only
> check for the latter - but they're both the same
> conceptually: just labels.
Labels for different things... that's why they have different labels.
The things they represent are not conceptually the same. And they hav
an infinite amount of variance from one group of people to the next --
different companies, different divisions or departments within the
same company, etc. However while the relationship between a permission
and a task is 1-to-1 the relationship between a role and a task is
always many-to-many. Hence by eliminating an arbitrary hard-coding of
a many-to-many relationship within the code page, you can eliminate
the need for programmers to maintain the permission set for a given
application. Sure I can sell an app to someone and then configure it
for them, but if I provide them with the means to configure it then I
can free my time up to perform equity-building tasks.
> Your explanation makes PERFECT sense when considering the
> UI to maintain these things however - that's where such
> conventions are needed. They simplify the management of
> the system and reduce the complexity of using it. But
> you don't need to restrict your underlying system to
> that model at all.
Umm... okay... but I don't write software that will do something I
consider to be a patently bad idea.
> The system can happily keep all this on the same
> conceptual level via a many-to-many parent-child
> relationship and an current-implementation-defined
> "context" catagory. Such a system could be leveraged
> to do EVERYTHING that's been discussed here for the
> past few days.
> The system doesn't care. You want complex inheritance?
> Fine. You want simple "role-permission" inheritance?
> Fine. You want simpler group-only checking? Fine.
> Using the original "message board" and your example you
> might see:
> Label Context Parents
> ------------------------------------------------------
> Admin Role
> Moderator Role
> Member Role
> Anonymous Role
> DeleteMessage Permission Admin
> EditMessage Permission Admin, Moderator
> PostMessage Permission Admin, Moderator, Member
> ReadMessage Permission Admin, Moderator, Member,
> Anonymous
Well that's a semantic error right there... a permission is not a
child of a role (although in my system permissions can have child
permissions, i.e. you can only access "admin/members" if you can first
access "admin").
> The "context" would inform your interface conventions
> (select by role or by permission). Or you might just
> leave "context" of and have a convention that all
> Labels without parents are "roles" and all those
> with parents are "permissions".
Bad idea... they should be stored separately...
> You could leave it simple and say that all labels must
> be unique or you allow labels to have the same names
> (I assume each label would be linked with a description
> of the label). You could enforce matches (entitlement
> checks) by only name or by name and parent (enabling
> the contextual grouping I mentioned).
> The original system proposed
> (by Mike was it? Damn I'm bad with names)
Which seems to be part of your problem understanding this. :P
<snip>
> Convesationally: Anoymous is a child of Member, Member
> is a child of Moderator and Moderator is a child of Admin.
> If an Admin wants to "Read" you would check the context
> (yes, we're on the right page) and then check the parent
> - it's "anonymous". But since anonymous is a descendent
> of "admin" admin can read.
It doesn't bother you that this is a complete non-sequitur and makes
absolutely no sense whatsoever?
Or did you get confused by your model (in which case I'd have to say
it's a bad model) and describe it incorrectly?
What you've said is
"Anonymous is a child of admin, therefore an admin can read."
More or less it's equivalent of:
"Coliflour and brocoli are both vegetables, therefore carrots are
orange."
> (I agree with you, by the way, that this can become
> way too confusing way to quickly - but the system
> can _support_ the concepts easily without having to
> implementing them. I also still think that adding
> per-page permissions needlessly complicates things.)
Nah... the per-page permissions for onTap applications actually makes
a lot of sense...
Though it's not really technically "per page" it's "per process"...
and a process can have children... so... for example, if you have this
url:
/admin/members/edit.cfm?netaction=update
You might have these permissions
admin
admin/members
admin/members/edit
admin/members/edit/update
Any of these permissions which exist must apply to the current user in
order for the user to be permitted to execute that http request
uninterupted (otherwise they go off to the login page). Instead of
complicating the security model, this actually simplifies it quite a
bit... this abstraction of the path (admin/members/edit/update) is a
built in semantic of the framework, and prior to that a built-in
semantic of every operating system (file-system). You already write
your applications by using the file system -- different directories
and different files do different things. So you're already applying a
semantic in your development work that says "files in directory x
perform x-related tasks" (or something similar). All this does is take
what you're already doing and then applies security against that
existing semantic model.
> My whole point here is that these labels are still
> all the same things, systemically: just labels.
Nope.
>> > But you do have to create extra programming to add
>> > permissions... so what's the difference?
>>
>> Umm... in most cases no I don't... The framework
>> abstracts the permission to an individual process
>> and then checks permission automatically... I do
>> occasionally check the applicability of an alternate
>> permission (for something other than the current
>> process), but the system is designed such that
>> someone who installs it elsewhere can actually
>> create new permissions to secure sections of
>> my application even if I didn't secure them,
>> without writing any CFML.
> It's really no matter if you write CFML or not. To
> security something with a permission you need to know
> the name of it. That's the bottom line - whether
> that's abstracted or not you need to say "this
> thing here, only let people that can do that thing
> there in".
Umm... okay, you just made an argument, I rebutted and you changed the
subject.
Argument A) But you do have to create extra programming to add
permissions
Rebuttal A) No, I can create permissions all day long without doing
any programming
Subject Change + Non Sequitur) It doesn't matter if you have to create
extra programming to add permissions because my friend Jim won't let
people who aren't members of the accounting department distribute
payroll checks.
>> Moreover even if I am manually checking a specific
>> permission within a page, the page doesn't know
>> anything about what roles are granted to that
>> permission, which allows the person who set up
>> the app to
> I still say this is just semantics. You're checking
> a label and theres a lot of labels relationships that
> might come into play behind the scenes. But it's all
> just labels and conventions for grouping and
> checking them.
All programming is semantics... Wait... let me rephrase that
11000111 00101101 10100011 11000111 00101101
10100011 11000111 00101101 10100011 11000111
00101101 10100011 11000111 00101101 10100011
11000111 00101101 10100011 11000111 00101101
10100011 11000111 00101101 10100011 11000111
00101101 10100011 11000111 00101101 10100011
11000111 00101101 10100011 11000111 00101101
10100011 11000111 00101101 10100011 11000111
00101101 10100011 11000111 00101101 10100011
11000111 00101101 10100011 11000111 00101101
10100011 11000111 00101101 10100011 11000111
00101101 10100011 11000111 00101101 10100011
But ulimately whatever semantic is chosen determines syntax and that
syntax in turn determines how flexible the system is and how much
programming work I need to perform in the future when it doesn't
satisfy someone else's needs. It's not "just semantics" -- semantics
is EVERYTHING man. Why else do you think there are so many freaking OO
vs. Procedural debates?
> I don't think a generalized security system needs to know
> more than that.
Okay... I don't think a security system that's as generic as you
describe is really a worthwhile endeavor... It leads to more
programming work later for something that I could have just provided
the user with a tool to perform.
s. isaac dealey 954.522.6080
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.fusiontap.com
http://coldfusion.sys-con.com/author/4806Dealey.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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:217386
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
