I want to comment a little more (concisely?) on some of what I was
saying on the call yesterday.
I feel like a lot of the web interfaces of the mail list tools (and web
tools in general) have an account-action authorization model. That is,
they define a (sometimes long) list of actions that can be performed in
the application, like "post to list" "moderate" "subscribe" etc. They
then go about associating accounts with the actions they can perform.
When per-account assignements become combersome, the tools typically move
to a role based assignment of authorizations. This allows you to assign
roles to actions and accounts to roles. At the very least, this keeps you
from having to modify a lot of accounts if you decide to change
authorizations. You just modify the role. This approach can also support
the previous method by just defining a distinct role for each account.
The other angle from which to approach authorization is to define
object-owner authorizations. This requires the system to define the
internal objects that can have owners. You can then give owners (accounts)
permission to control the object they own, eg. a mailing list or
subscriber list.
You can obviously introduce roles (or groups) into this approach in an
effort to help manage the complexity of object ownership assignments. You
then assign accounts to groups and groups as object owners.
You can also combine the account-action and object-owner models and get
various degrees of flexibility and/or complexity. For example, you could
define the accounts "joeuser" and "moeadmin", the action roles "read" and
"write", the owner group "admin" (with moeadmin as a member), and the
object "subscriber list". You could then describe permissions like "joe
user is allowed to read the subscriber list and moeadmin is allow to read
and write the subscriber list".
The authorization model in your application can then become fairly
flexible if you promote your actions and data abstractions to the same
level and have your authorization system worry only about enforcing the
owners and actions for each object and not worry about what the type of
the object is (ie. what it contains).
For example, a fairly simple system could add the action role "execute"
for objects to the definitions in the previous example. Execute gives the
owner of that object the permission to "set the object in motion" (so to
speak). In this system you could define the objects "moderate", "mailing
list A", and "mailing list B". The admin group could be given execute
permission on the "moderate" object. The account "joeuser" could be added
to the admin group and given ownership of "mailing list A" object but not
of the "mailing list B" object. With this, you could describe something
like "joeuser can moderate any mailing list that he owns".
I haven't seen interfaces to mailing list systems which are that abstract.
(Please let me know if you know of some. I may just be looking at them at
the wrong level.)
The point here isn't to imply that these are new ideas about
authorization. It's mainly to help describe the implementation options to
consider while we generalize the domain model. We shouldn't prevent one
implementation by describing another.
Hope this description has been clear enough and useful. I'm not sure if
I've used all the terms correctly, but I've tried to be internally
consistent.
~jpr
