WebService API for Authorization

   //
   // Permission to perform an action.
   checkPermission(Account who, Action action, Resource resource)

      Is account <who> allowed to perform <action> on <resource>.
      Based on the tables described above, generates a query like this :

      SELECT
         action
      FROM
         tables
      WHERE
         permissions.resource = RES
      AND
         permissions.action = ACT
      AND
         permissions.group = members.group
      AND
         members.account = WHO

   //
   // Change permissions
   changePermission(Account me, Group group, Action action, Resource resource)
      Account <me> asking :
      Insert, change or remove permission for <group> to perform <action> on <resource>.
      Only allowed if account <me> is allowed action 'administer' for <resource>.

   //
   // Change group members
   insertMember(Account me, Account who, Group group)
   removeMember(Account me, Account who, Group group)
      Account <me> asking :
      Insert or remove <member> in <group>.
      Only allowed if account <me> is a member of owner for <group>.
      Not allowed if <group> is a single account group.

   //
   // Create account
   createAccount(Account me, Account who)
      Account <me> asking :
      Create account <who> in this community.
      Only allowed if account <me> is allowed to administer accounts on this community.
      Automatically creates the coresponding single user group for this account.

   //
   // Change owner
   changeOwner(Account me, Group group, Resource resource)
      Account <me> asking :
      Change ownership of <resource> to <group>.
      Only allowed if account <me> is allowed action 'administer' for <resource>, or is owner of <resource>.

Note, the only reason for a resource owner is to prevent removing all the permissions from a resource. The owner of a resource always has 'administer' permissions.

Likewise, the group owner is a short cut to ensure at least one group is allowed to 'administer' the group. The owner of a group always has 'administer' permissions.

This model does not deal with authentication. In this example, accounts and groups are identified by their serial ident values. Change this to a text identifier, and we can probably cope with accounts and groups from external communities.

This does not take into account the concept of a resource path, walking up the tree to find permissions for a parent node in the tree.

That depends on what the rules are for the permissions in a tree.

• +ve and -ve or +ve only ?
• Do permissions cascade down a tree ?

-- DaveMorris - 29 Jul 2003

-- KevinBenson - 31 Jul 2003