---

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

---

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.

WebService API

   //
   // 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

---

Hmmm I think we might want to have our conference call early this week lets say tomorrow. Is tomorrow at 10:00 a.m. fine with everybody. I can get the details of the phone later. I will place this in the wiki under CommunityDiscussion2 and feel free to keep adding to it. Hopefully we will get their.

Here is an attempt to answer your questions though

> So dave@cam is authenticated by commnunity server at cam.ac.uk.
> and kbm@mssl is is authenticated by commnunity server at mssl.ucl.ac.uk
Yes

> So community is synonymous with institute ?
Yes

> Does community at ed.ac.uk contain a record allowing dave@cam to access
> the HPC system ?
Well Yes and no. It would contain a record dave@cam only if you have some special access. I was thinking in the local community db would be something like this. HPC- read DTC - denyall Edinburgh - read Dave@cam - write

Now you would have write permissions, but myself would be have read permissions. Now obviously their is a huge flaw if they say denyall like you said at the Edinburgh line. If they do that then yes this would be sort of a problem because they have to input all these users. Also keep in mind that Tony wants to allow "guest" to do reads right now everywhere. I do expect to have a "User Groups" can be defined in their so as you say a person might just put "3d visualaztion group", but I really did not think we could implement something like that in this first iteration because it would require going out and getting the users for that project from another community. In which case if we do have "User Groups" then that does simplify things a lot because you would not have to put all those users. We can discuss if we really think this is viable for this iteration.

> Does system refer to the HPC resurce at ed.ac.uk, or the JES at cam.ac.uk
? Edinburgh. Hmmm in this first iteration I was thinking no validation on the user exists in the other community at this stage so if the Admin person puts in deva@cam then it will never find the access permissions of dave@cam obviously this would be changed where there is cross-community checking in a later iteration.

> Is this the admin at ed.ac.uk controlling the local community policy for
> the HPC at ed.ac.uk
> Or is this the admin at cam.ac.uk controlling the local community policy
> JES at cam.ac.uk
Most likely HPC, but I would like to think in our system that the HPC admin can log in to the web interface and give Dave@cam Admin rights allowing you to be a administrator. I would think this would be a big no no.

> >Now as you mentioned a user such as Myself might have registered with
> >several communities and I might want to lets say share data between my
> >communities.
> >
> I think we need to check this one with Keith.
> From what I've heard, Keith and Tony invisage a system where one user
> has one community and uses one portal.

Whoops my mistake I did not make some things clear. You are right their is only Dave@cam registered at cambridge and you would have to have a seperate registered login for Dave@edinburgh

---

Original Message ----- From: "Dave Morris" <dave@ast.cam.ac.uk> To: "KevinBenson" <kmb@mssl.ucl.ac.uk> Cc: "Brian McIlwrath^?" <B.K.McIlwrath@rl.ac.uk>; "Paul Harrison" <pah@jb.man.ac.uk> Sent: Monday, July 28, 2003 2:30 PM Subject: Re: Awkward questions

> KevinBenson^? wrote:
>
> >Alright I will give it a go.
> >
> >On first note:
> >You are quite right Dave I have totally need to update the Iteration3
> >Community description their. At the time I just wanted to get rid of the
> >"latin" crap that was on their.
> >
> Can anyone read latin ?
> I'd really like to know what this stuff says
>
> >You said:
> >
> >
> >>Ok, turn it round and make the 'project' the community.
> >>
> >>
> >Well this is probably what I am sort of visioning. Even though in the
first > >iteration as you read below it is going to sort of "straddle" both of
your > >views.
> >
> >Here is what I am thinking for this iteration:
> >Authorization is done only to your local community (meaning looking up
users > >in the local community database.)
> >
> So dave@cam is authenticated by commnunity server at cam.ac.uk.
> and kbm@mssl is is authenticated by commnunity server at mssl.ucl.ac.uk
>
> >DataCenters are really the only component/resource that lives outside a
> >Community. Meaning a user will be calling JES, Myspace, Registry that
are > >local to it's community (I hope this is right.). So if I am getting this
> >right if DaveM^? logs in at Cambridge he will only be using components that
> >are local to his community. (Please tell me if you think I am wrong on
> >this.)
> >
> Ok, so far ....
> dave@cam uses JES and MySpace services at cam.ac.uk
> So community is synonymous with institute ?
>
> >Now DataCenter^?'s are different for this iteration they will still lookup
a > >user in their local community.
> >
> So data center at Edinburgh uses local community at ed.ac.uk
> But this is a Grid system, so dave@cam is using JES at cam.ac.uk to run
> a job on the HPC resource in Edinburgh.
> So some service at ed.ac.uk needs to use authentication at cam.ac.uk to
> check dave is dave@cam.
> Then, service at ed.ac.uk needs to check if dave@cam is allowed to use
> the HPC resource.
> Does community at ed.ac.uk contain a record allowing dave@cam to access
> the HPC system ?
> If so, then this implies cross community interaction, a record for
> dave@cam in the community policy DB at ed.ac.uk.
> Someone needs to tell admin@ed.ac.uk that dave@cam should be allowed
> access to the HPC resource.
> The reason for this is that dave@cam is a member of the '3D solar flare
> visualization project', but that project is run from mssl.usl.ac.uk
> If a new member at jb.man.ac.uk joins the '3D solar flare visualization
> project', then how does the team lead at mssl.usl.ac.uk arrange for them
> to have access to the HPC resource at ed.ac.uk ?
>
> >If the user is not found then it cycles up
> >to what ever the default policy is for the system.
> >
> Does system refer to the HPC resurce at ed.ac.uk, or the JES at cam.ac.uk
? > If system refers to the HPC resurce at ed.ac.uk, then the policy will be
> likely to be 'deny all', I doubt if admin@ed.ac.uk will allow joe public
> to run jobs on their HPC cluster without specific authentication.
> If system refers to the JES at cam.ac.uk, then the policy will be likely
> to be 'deny all', doubt if the admin@cam.ac.uk will allow all
> undergraduates at cam.ac.uk access to HPC cluster in Edinburgh.
>
> >If it is found then
> >great return the access rights. So "yes" this means in this first
iteration > >we have just made things harder for the System Administrator for the
> >Datacenter because if they want to give a user special permission then
they > >must input that user specefically for their local community.
> >
> Without cross community authorization/authentication and managed groups,
> admin@ed.ac.uk is going to spend most of their day adding and removing
> users from their local community policy as people join and leave
> projects across the world.
>
> >Back to Jes, Myspace, and Registry I have mentioned them as
> >components/resources my thought is in the database these will be setup as
> >groups and will most likely have a sub-group. See
>
>http://wiki.astrogrid.org/pub/Astrogrid/AuthorizationDiscussion/Authorizati
onDTCSequenceAttempt1.dfSequence.wmf > >this is just an image file so you should be able to see this.
> >
> >As you can
> >see this makes things a little easier for the System Administrator, the
> >Admin simply sets up a group such as Jes and gives it a default policy.
> >
> Hang on ... sorry, but can we be specific about who we are talking about
> here.
> Is this the admin at ed.ac.uk controlling the local community policy for
> the HPC at ed.ac.uk
> Or is this the admin at cam.ac.uk controlling the local community policy
> JES at cam.ac.uk
>
> > And
> >if the admin wants to he can go another level down and define an actual
> >resource for that system and give it a policy. And further go down to the
> >user level. So as you can see we are sort of straddling both your views
> >because we still make life a little hard because he is specefying a
> >particular user, but he is still able to set a policy at higher up which
> >should be the majority of the cases.

> >Here is the hiearchy, and system is the only one that is required.
> >system
> > resourcetype
> > resource
> > user
> >
> >Notice at the moment for this iteration I am always thinking of "User"
level > >"userid/username" Another words for this iteration do NOT allow for a
> >person to create groups of users. Such as "SolarFlaresProjectGroup". So
we > >are only dealing with userid's.
> >
> If we can't create the '3D solar flare visualization project' group
> (probably created in local community at mssl.usl.ac.uk by team lead
> at mssl.usl.ac.uk)
> Then the system admin@ed.ac.uk has to be notified every time someone
> joins or leaves the project.
>
> >Now as you mentioned a user such as Myself might have registered with
> >several communities and I might want to lets say share data between my
> >communities.
> >
> I think we need to check this one with Keith.
> From what I've heard, Keith and Tony invisage a system where one user
> has one community and uses one portal.
>
> >Well as far as the Authorization goes I think it might be
> >plausible to setup that folder based type sharing for a user that we
> >discussed in a earlier e-mail. I still need to put together a little
> >diagram of this and place it on the wiki. But I need to get together
with > >the Myspace group leader because I really think we can setup this on our
> >side, but I don't know if they can figure out about sharing of data
between > >the users. Another words we can tell Myspace what users are in that
folder, > >but not sure if Myspace in this iteration can do anything about it.
> >
> >>Either way that I look at it, we need some way of authenticating,
> >>sharing data and administering groups across Community boundaries.
> >>
> >>
> >Your right this will probably come about, but not really in this
iteration. > >The Community does not have to really worry about sharing of data.
Another > >words my view is we can tell other components/resources what the
> >authorization policy is and if a user is authenticated. But as far as
what > >to do witht he data that is up to the calling component/resource.
> >
> >So as you can see in this first iteration we are not crossing any
Community > >boundaries that I can see. Am I wrong?
> >
> Potentially lots of times ... see above.
> If the aim of iter 03 is to bring the system upto a state where we can
> look at running some of the real science use cases, then
> we are going to have to address the core problem of Grid ...
> authentication and authorization across institute boundaries.
> Sorry, but I think this is one of the core problem inherent in Grid
systems. >
> If we are going to discuss further this should we move this to a Wiki page
? >
> Dave
>
>
>
>

-- KevinBenson - 28 Jul 2003