I've been working on a possible structure for the database tables and basic WebService API.

This is as far as I have got :

Database tables

   resources
      ident     SERIAL
      name      TEXT
      desc      TEXT
      path      TEXT
      owner     group

   permissions
      ident     SERIAL
      resource  resource
      group     group
      action    action

   groups
      ident     SERIAL
      name      TEXT
      desc      TEXT
      owner     group
      type      'MULTI' or 'SINGLE'

   members
      ident     SERIAL
      group     group
      account   account

   accounts
      ident     SERIAL
      name      TEXT
      desc      TEXT

Note, using a similar technique to the user groups in RedHat^? Linux, every user account has a corresponding group with the same name andonly one member.

So, when user account dave[at]ast.cam.ac.uk is created, a corresponding group is created containing one member, dave[at]ast.cam.ac.uk.

This means that the permissions table only needs to link resources and groups, but we can still assign permissions to an individual user account.

Hence the 'MULTI' or 'SINGLE' types for a group.

• A normal group of users is type 'MULTI', allowing zero or more members of the group.
• A 'SINGLE' group only allows one user, and cannot be changed.

This is really just a way of making accounts look like groups for the permissions search.

It means that we can assign read permissions to the '3D solar flare visualization' group, and read and write permissions to the dave[at]ast.cam.ac.uk group, irrespective of whether dave is a member of the '3D solar flare visualization' project.

Note, there are no restrictions on what the allowed 'actions' are. These would be up to the specific service making the request.

As far as the Community authorization system is concerned, these are just text strings. MySpace is likely to have actions for 'read' and 'write' for data items, plus 'create' and 'delete' for folders. However, if the MySpace team feel the need to add an action called 'funge', all they need to do is add the code to their system. The Community service will quite hapliy store action='funge' in the permissions table, and will happily respond to authorization requests to check if user 'dave[at]ast.cam.ac.uk' is allowed to 'funge' resource 'x31'.

• Bear in mind that hard coded binary flags are very limiting, and only really make sense in hand coded optimised machine code.
• Plus both web services and JDBC calls are inherently text based, so even if we cram all the flags into 8 bits, the web service and database calls will expand them into text anyway.

This means that we can allow the different services complete flexibility in what actions they want to check permissions for.

• MySpace will likely have 'read' and 'write' but the merit of 'execute' on an XML data file is questionable.
• Likewise, a database resource may want to allow users to 'read' some data or 'execute' a query, but 'write' is probably not applicable.

DaveM

---

Wow really good. I also came up with some db tables, but yours is better. I think I have it all pictured out what you have good db design, but any chance you can put on the wiki just a few example rows for the tables? Just to make sure I get it. Also before I normally mentioned the word "system" as the top level type of group. I really should have said "community", might ask the question when a person sets up a Community db that it should automatically populate the top level group "community" ex: leicester with a default policy in which I would think the admin would change the policy, but not allow him to delete the top level group "community". I will add this paragraph to the wiki as well.
Kevin

---

-- KevinBenson - 31 Jul 2003