If you think that this is plausinble, then I'll have a go at implementing a prototype in Java.

-- DaveMorris - 30 Jul 2003

For the purposes of this model, we will assume that a Community is synonymous with an Institute, and that authentication for a user account is handled by a Community service run by the user's home Institute.

The following use case scenario for the system involves three Institutes : Leicester, Edinburgh and Rutherford with a HighPerformanceComputing^? Resource located at Edinburgh and a SolarFlares^? Project based at Leicester.

When the project is set up, the project managers at Leicester would create a group in the Community server at Leicester for the project members. This group would include both local and external Accounts from other Community services.

For example, the initial team may consist of

• tony[at]leicester
• keith[at]leicester
• brian[at]rutherford.

The project manager would create the group in the Leicester Community and then add the individual members to the group.

To add brian[at]rutherford to the group in Leicester, the Community server at Leicester would need to query the Rutherford Community server to locate the user Account at Rutherford for brian[at]rutherford.

The local Community service at Leicester would display this list, enabling the administrator at Leicester to select brian[at]rutherford, and add it to the solar[at]leicester.

Note that this assumes that the Community services at Leicester and Rutherford know about, and trust, each other. Depending on the level of trust established between the service, part or all of the conversation between the services may need to be done using signed and authenticated messages.

This would result in the following records in the Community database at Leicester.

Once the project is set up, the project manager can negotiate access to the HPC Resource at Edinburgh for members of the SolarFlares^? project.

The system administrator at Edinburgh would then grant access to the HPC Resource for members of the SolarFlares^? Group at Leicester. The access permissions for the HPC resource would be entered into the local Policy database at Edinburgh.

In order to do this, the Community service at Edinburgh would need request a list of groups from the Community service at Leicester to enable the administrator at Edinburgh to choose the solar[at]leicester Group and add it to the local Policy database for the HPC resource.

This would result in the following records in the Policy database in Edinburgh.

With the permissions granted, members of the SolarFlares^? group should now be able to access the HPC resource in Edinburgh.

For example, if brian[at]rutherford wanted to run a computing job on the HPC Resource at Edinburgh, he would use the Portal at Rutherford to contact his local JobEntrySystem^? to create the job.

If we assume that brian[at]rutherford knows that the reason he is allowed to use the HPC Resource at Edinburgh because he is a member of the SolarFlares^? project in Leicester. Then, when he creates the task in the JobEntrySystem^? at Rutherford, Brian can specify membership of the solar[at]leicester group as the credential he wants to use for this task.

In order to present the list of groups to choose from, the Community service at Rutherford would need to know which groups brian[at]rutherford belongs to.

If we need to, it may be possible to add some business logic to the JobEntrySystem^? at Rutherford to automate some of this. The JobEntrySystem^? at Rutherford could ask the local Community service at Rutherford what groups brian[at]rutherford belongs to. It could also ask the Policy service at Edinburgh what groups are allowed to use the HPC Resource. The JobEntrySystem^? could then present Brian with a list of matching credentials that would allow him access to the HPC Resource at Edinburgh.

Asking the user to select the credentials they want to use for the job may have some additional benefits. If brian[at]rutherford is a member of two groups, solar[at]leicester and star[at]rutherford, both of which are allowed to access the HPC Resource in Edinburgh, then asking Brian to specify which credentials he wants to use for the job may enable us to add additional logging and accounting features. For example, the two groups may have different allocations of CPU time on the system at Edinburgh, or we may need to know which group to send the bill to.

Once the job has been entered, the Rutherford JobEntrySystem^? can contact the HPC Resource at Edinburgh on Brian's behalf, passing the job information across.

Before it starts the job, the HPC Resource at Edinburgh first needs to check that brian[at]rutherford is who he claims to be. This involves an authentication call from a component at Edinburgh, possibly through the local Community service, back to the Community service at Rutherford to verify the message signatures and certificates in the message.

Once the system at Edinburgh is happy that brian[at]rutherford is who he claims to be, it then examines the message to see what he wants to do and the credentials to do it with.

Brian has chosen to use his SolarFlares^? at Leicester credentials, so the system at Edinburgh needs to call the Community service at Leicester to verify that brian[at]rutherford is a member of solar[at]leicester.

By passing a reference to the credentials the user wants to use for the task we avoid making the service at Edinburgh sort through a potentially large and complicated list of groups.

Without this, the service at Edinburgh would have to look at its local list of groups who are allowed to access the resource and check each of them in turn to see if brian[at]rutherford is a member of the group.

If there were 50+ external groups allowed access to the HPC Resource at Edinburgh, then this would result in a large number of redundant calls to external services. Plus, if brian[at]rutherford is a member of two groups both of which are allowed to access the HPC Resource, the service at Edinburgh would not know which account to deduct the CPU time from.

Having validated the credentials, the service at Edinburgh can now query the local Policy service to check that members of solar[at]leicester are allowed to access the HPC Resource.

Having validated that members of solar[at]leicester are allowed to access the HPC Resource and that brian[at]rutherford is a member of solar[at]leicester, the service at Edinburgh can go ahead and schedule the job on the HPC Resource.

The main reason for all of this cross checking is so that the Policy service at Edinburgh can contain an entry allowing members of solar[at]leicester access to the HPC Resource without having to maintain a full list of solar[at]leicester members. This means that a new team member, paul[at]joderell, can join the project and the service at Edinburgh does not need to know.

To enable the new member to use the Resource in Edinburgh, the administrator for the SolarFlares^? project, can add paul[at]joderell to the solar[at]leicester group.

This would need to create two records, the main authoritative record in the Community service at Leicester, identifying paul[at]joderell as a member of solar[at]leicester.

In addition, an information only record would need to be created in the Community service at Joderell.

The second record at Joderell is required by the local JobEntrySystem^? to display a list of credential to choose when creating a job for the HPC Resource in Edinburgh,.

The authoritative records for members of Groups at Leicester are always kept at Leicester. This is the Community service used by the system at Edinburgh to verify that paul[at]joderell as a member of solar[at]leicester.

If the two records get out of sync, paul[at]joderell can try to schedule a job on the HPC Resource in Edinburgh using his solar[at]leicester membership, but if the Community service at Leicester does not confirm his membership, then the system in Edinburgh will not allow him access to the resource.