My comments are inline as well...
Nando wrote:
comments inline ...
Nando -
This is helpful. The concept of a key ring with doors and locks is a
good real world example. However, in this case I am not sure a real
world model is the best example. If I were to do it this way, I would
have two different 'keys' for a janitor ... one if the janitor worked
on the 5th floor and one if the janitor worked on the 6th floor. This
seems like it could get very complicated in a hurry if you are working
on a 40 floor tower.
Instead, I am looking at a 2 tier model. The janitor may have a key to
the janitor's closet, of which there is one on every floor. But,
janitor A should only have access to floors 1 through 5. Therefore
instead of giving the janitor 5 different keys, we give them an
electronic passkey that opens janitor closets on floors 1 through 5,
but not on any other floor ... i.e. the combination of a janitor role
(with associated rights) plus permissions to work on floors 1 through 5.
[Nando]
Well, you see, in the end, a "Role"
simply becomes a permission key then. In this case, whatever we call
it, *at the door*, a certain key opens it.
Agreed. A few years ago, I protyped a 2-tier system similar to what
you described. It was pretty simple - query the DB for a list of keys
and then get all the key parameters associated with those keys. That
was easy, but managing a system like this was crazy!
I think it's confusing to call a "Key" that opens a door or a set of doors a
"Role" - Whether the janitor's key opens one door or 5 doors doesn't
matter, it's still a Key and not a Janitor. It's just that those 5
doors have the same lock. If you give the Key to someone else, it works
just the same. If the Janitor doesn't have the actual key, he can't
open the door, even if it has a sign on it that says "Janitor's Closet"
and he has the word "Janitor" emblazoned on the back of his uniform.
Just because I'm the head techie - doesn't mean I manage the mail
servers. ;-)
I don't think it's a problem in the
programmatic world to have 5 keys for floors 1 - 5, your user won't
have to fumble in their pockets to find the correct key - it will just
work. If you need more granular access to floors 1 - 5 (and who knows,
one day you might!) then you'll need an individual lock on each door.
If you need to assign those keys to users efficiently, then a Role can
assign a set of default keys.
Agreed again. I used to work in a building - all the doors had locks
of course. Some of my co-workers got single door keys, some got an
area key (like a floor etc) and a few got a general master. We were
all performed similar job functions, but needed different keys - hence
why we were given only the keys we needed. If some needs a key to
specific room, give him a single key. If everybody needs a key to a
'new' room - add it to the role.
To
continue a little further, there's nothing to prevent us from having 2
keyrings in a system. For instance, apartment buildings have often a
main entrance that everyone in the building has a key for. But each
tenent only has a key to their flat. And the apartment complex
supervisor has a key to each building. Then you could have an
ApartmentComplexKeyRing and a ApartmentBuildingKeyRing. Each user of
the system would have 2 keyrings and the appropriate keys on each ring.
That would come closer to the roles
concept, but i still have to say that a role is not a key. We can use
the word "role" to mean a key or a set of keys, depending on how
granular you want to get with your locks, but in my experience, the
moment you put the same lock on a set of tasks, a situation comes along
that asks for a separate lock on one of those tasks. It's trivial to
give a user a key for that specific task, it's not so trivial to go
around changing your locks and giving all your users new keys,
especially on a live system.
And, if you implement a permissionKey
only system at the "door" level, it's also trivial to add a new lock to
the system. All you need to do is add the necessary code in your
controller and make the new key available to your users.
This model seems fairly easy to implement ... a role object has one or
more rights. A user or group then has one or more roles in the
system. Then, each object (i.e. the janitor's closet) has an access
control list that says which users have access to that object. The
role/right combination is a property of the user (a user knows his
role), and the access control list is a property of the object (an
object knows who can access it). This way, things can get as granular
or as generic as needed ... individual users can be given permissions
to an object or the janitorial staff (user group) can be given
permissions to an object.
Assuming there is nothing in this model that I am overlooking, my
biggest problem at this point is where the authentication and
authorization functions happen. At what point does the user get
prompted to log in? For example, the building lobby might be open to
anybody that walks in and we don't want to check ID before you can even
come in the front door. Then, at what point does the user's
authorization get checked?
[Nando]
I
would say at the point that they try to enter the first locked door.
Yes...most likely - unless you are doing something strange. One
project for me at the moment, you have to login immediately - it's like
the secret service guys that check your ID at the White House. They
don't care about what you're going to be doing there, but only if you
are authorized to come in. That's why the White House has guards
inside.
I think I am making this part more complicated than it needs to be.
Should an actual object need to know how to check if a user is
authorized or should this functionality be moved up to the controller?
Thus, in the controller, when a user attempts to create a new document,
the controller will first check if the user is logged in, then check if
they have the editor role with the right to create documents, then
check if they have write permissions to the folder they are attempting
to create the document in.
This seems to make more sense than trying to fit these checks into the
user, document, or folder objects.
Any thoughts or suggestions?
[Nando]
Make
it as simple as possible. :)
I'm not sure if you're using a framework, but if you are, i'd put the
check at the controller level. That doesn't mean that that's really
intelligent or anything, i'd just do it that way. Plus, why would a
Document object know anything about security? It's clearly not within
the realm of its responsibility.
I think some of the smarter ones out here would create a Security
object whose responsibility it would be to check credentials. If you
had one of those IsLoggedIn boolean values running around in your app,
maybe you'd position an instance of Security at the door of every
function you want to secure and pass the boolean in, and go from there.
But maybe someone else with more experience there can comment.
Your document doesn't need to know anything about security. Let the
controller take care of that.
Thanks for the help.
-- 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]
--
Peter J. Farrell :: Maestro Publishing
blog :: http://blog.maestropublishing.com
email :: [EMAIL PROTECTED]
phone :: 651-204-0513
----------------------------------------------------------
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] |
