Jeff,
Here's my take on the issue. I found Hal's article really helpful, in the
sense that he reduces the high level concept of permissions down to a user
having a set of keys. Similar to an employee having a set of keys for doors in a
building. If you have a key, you can get in, if you don't, you can't. A manager
can be given a default set of keys according to their role when they are hired,
but if their responsibilities evolve and they need a key to the janitor's closet
to check on the building alarm system in the evening before going home, you just
give them a key.
You
don't need to create a new role for that manager. You don't need to change the
lock in the door so it works with 2 or 3 different types of roles. You
don't need 2 different types of lock & key systems present on the door, one
for the more general role, one for the more granular permission, with the
role key/lock overriding the permission key/lock.
You
just give the manager a key for the door on the janitor's closet.
Simple.
Also, i think most people have a key ring in their pocket or purse, not a
bunch of individual keys. We use key rings. We don't go fumbling in our pockets
for individual keys. And if you or i get another key, we slip it on a key
ring.
That's how it works in the real world. And i've found
that to be a very simple, effective, flexible way to handle permissions in an
app. A task or section to be secured has a single "lock" - perhaps an if
statement that tests for true. I think it makes more sense to put that lock
in the controller section of your app, not in the function itself with the roles
attribute. It's much more transparent that way.
A
user could be assigned a role, but a role isn't anything more than
a default set of permission keys. That allows a user's KeyRing to be
responsible for permissions.
Instead of thinking about the keys as individual members of an object
(like individual keys in your pocket, which makes it more difficult to add or
subtract keys from the system, you'd need to go in and add the getters
and setters to your KeyRing object), to me it makes more sense
to implement the keyRing as a struct. I serialize and store the
keyRing as a wddx string in the the user table, and when a user logs
in, the keyRing gets converted back to a struct, which you could place as
in instance variable in your session.User object, for instance,
if you wanted to keep it simple.
if
(session.User.getKeyRing().editDocs) {
let them edit
}
else {
sorry, you don't have permission to
edit
}
Or,
maybe better
if
(StructKeyExists(session.User.getKeyRing()), "editDocs")) {
let them edit
}
else {
sorry, you don't have permission to
edit
}
Do
we need to encapsulate the key ring in an object of it's own? Maybe ...
Some
people have lots of keys. I don't. But people with lots of keys, maybe
several key rings, might need a separate object to keep them in, some
sort of key ring purse. Applications with a lot of keys, or made by people who
like more abstraction rather than less, might be better off with a separate
object to store the keys in. That could be passed into your Session.User object
or stand on it's own. It could contain multiple key rings as instance data,
or just a single key ring.
Will
anything else in your system need to use the permission system besides Users? If
so, that might be another very good reason for encapsulating the key ring in an
object of it's own.
Also, if your app will have a lot of users and a lot of keys
- Roles might be important. An admin user adding new users to the system
might not want to go through the whole list of keys and choose which to assign
for each user. But if you'll have just a handful of users on the app and 10 or
15 keys, it might not be worth the bother to create and maintain Roles just to
assign default keyrings to new users.
What
about the Locksmith? Do we need an object to create locks and keys
... hmmm, generally the "lock" part of a permission scheme is
programmed into the app by the developer. In other words, the developer is
the locksmith. Programming your app to be it's own locksmith might be a lot more
work than it's worth. One thing worth noting tho' is that when you as a
developer function as the locksmith and add a lock and key to an existing
system, you'd probably want to make sure that when users log in, they
automatically pick up the new key (set to false) on their key ring if you
have use true / false keys. If you use StructKeyExists(), you can add new
keys to the system and not worry about existing users.
I've
seen a few pretty complex authentication schemes by some of the more
experienced OO'ers on the list here, but for what i've needed so far,
a simple model is more than enough - if you reduce the higher
level complexity and confusion that results when you try and combine
permissions defined by roles AND permissions on individual
tasks into some sort of 2-tiered system in your app - and
simply base your security model on what happens in the real world
with keys and locks. We don't use 2 tiers like that in the real world, at least
i can't think of a use case. If you have a key, you can get into and drive
the car. Whether you are Husband or Wife or Friend or Relative or
Teenager or Thief doesn't affect the key or the way the car responds
to it.
I
don't know if this is helpful, but sometimes it really helps me to get clear on
exactly what i'm trying to model before i start thinking about objects.
ciao,
Nando
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jeff Chastain
Sent: Tuesday, March 08, 2005 4:24 AM
To: [email protected]
Subject: RE: [CFCDev] OO Security?To better clarify this question, I have read the article by Hal Helms (http://www.halhelms.com/index.cfm?fuseaction=newsletters.show&issue=052203_rolesBasedSecurity) regarding the roles-based security. This is the type of security implementation that I am trying to implement .... a role (editor) has one or more rights (createDocument, editDocument, etc.), and a user is then assigned to one or more roles in the system. The part I am needing to add to this model is that the specific user may not have the permission to edit a document everywhere in the system. This user might be part of the marketing group which has permissions to edit documents in the marketing area, but not in the engineering area. So, I am adding one more layer of complexity to the security model.In addition, I am trying to implement it upon an OO model and all of discussions of this implementation that I have found are either totally abstract or are applied to a procedural app. How would one define this in an object oriented fashion? In other words, from my earlier post, which objects know about security and how to manage/check it?Hopefully this puts my question into a better context.Thanks for any help or pointers.-- Jeff
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Chastain
Sent: Monday, March 07, 2005 7:13 PM
To: [email protected]
Subject: [CFCDev] OO Security?Can anybody point me to an object oriented approach to security? I am looking to implement a role based security approach on a new application in which I am using an object oriented model developed with CFCs and a controller/view developed using FuseBox 4.I have two general questions with this approach. First, CFCs and specifically <cffunction tags have the roles security attribute. Utilizing this appears to require setting up security using the <cflogin etc. tags. This is not a problem with the exception that all of the examples I can find are showing these tags utilized in a typical procedural fashion. This leans me into the second question ... which objects know about security and how to manage it? Does a document know how to determine which users have what level of access to it or does a user object know all of the permissions that user has? At what level to methods like authentication and authorization come into play?Does anybody have a real obvious explanation on setting this up or know of any examples/articles I can go look at?Thanks-- Jeff---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
