Personal tools
You are here: Home → GRIA Documentation → Documentation 5.2 → Tutorials → Collaboration on a job using a trusted third-party → Running a job with inputs and outputs owner by different parties
 

Running a job with inputs and outputs owner by different parties

Two organisations wish to run a job without letting the other see their part of the input or output data.
The standard access control policies supplied with the GRIA basic applications package are suitable for an environment where the submitter of a job owns all inputs and outputs. In this tutorial we consider a more complex scenario, where different organisations each contribute input data to a job without exposing their data to the other partners.
Page 1 of 2.

The diagram below shows a scenario in which two organisations need to collaborate to run a job. They each provide some of the input data for the job, and they both see some of the output data. However, neither party should be able to see the other's data. An example of this type of situation would be safety testing the interactions between two products which are still under development.

Sharing a job

Two organisations collaborate to run a job.

If one organisation doesn't mind the other seeing its data, the solution is simple. Bob creates a job, gives Alice write access to Input-A and read access to Output-A and then runs the job. How to do this is explained in the Delegating access to a data stager section of the client user guide.

If Alice needs to be sure that Bob won't be able to read her data then things are slightly more complicated. The trick is for Bob to put Input-A into a state where he can't read it and where he can't change the access control rules any further. Alice can check the access control rules and verify that this is the case before uploading her data.

The default data stager policy that comes with GRIA 5.1 is not sufficient for this, because it does not allow delegation of the 'manager' role. Alice needs this role in order to check that Bob doesn't have it. Therefore, the trusted third party must first modify their data stager policy to allow a 'manager' to add, remove and list manager roles:

  1. Go to the web administration pages.
  2. Click on Access control in the navigation bar at the top of the screen.
  3. Select http://www.it-innovation.soton.ac.uk/grid/resource/data and undeploy it.
  4. Replace it with a suitable policy, for example: new-data-policy.xml.

Alice and Bob can now run jobs as follows (the examples show Java code, but this can also be done using the Swing client):

  1. Alice creates a MatchPattern which will match her and sends it to Bob. Typically, this is just Alice's X.509 certificate along with the CA certificate that signed it:
    2. MatchPattern isAlice = new MatchPattern(alice, CAofOrganisationA);
  2. Bob creates the job, which automatically causes the inputs and outputs to be created:
    3. Job job = jobService.createJob(JOB_URI, "My shared job");
  3. Bob adds rules granting Alice ownership of the job, Input-A and Output-A (the inputs are actually owned by the job, so we give Alice the manager role instead):
    4. job.addPolicyRule(new PolicyRule(isAlice, "owner", PolicyRuleType.SUFFICIENT));
job.input("Input-A").addPolicyRule(new PolicyRule(isAlice, "manager", PolicyRuleType.SUFFICIENT));
job.output("Output-A").addPolicyRule(new PolicyRule(isAlice, "manager", PolicyRuleType.SUFFICIENT));
  4. Bob removes the default rules granting him access to Input-A and Output-A:
    5. job.input("Input-A").removePolicyRule(bobIsManager);
job.output("Output-A").removePolicyRule(bobIsManager);
  5. Bob tells Alice the EPR for the job.

 

Alice now needs to check that things are set up correctly before uploading her data:

  1. Alice checks that the address in the EPR is that of the trusted third party's job service.
  2. Alice fetches information about the job:
    3. JobStatus status = job.checkJob();
if (!JOB_URI.equals(status.getApplicationURI())) throw new Exception(...);
PolicyRule[] inputRules = job.input("Input-A").getPolicyRules();
PolicyRule[] outputRules = job.output("Output-A").getPolicyRules();
  3. Alice must ensure that the only rules are the ones she asked Bob to add:
    4. PolicyRule expected = new PolicyRule(isAlice, "manager", PolicyRuleType.SUFFICIENT);
if (inputRules.length != 1 || outputRules.length != 1) throw new Exception(...);
if (inputRules[0].compareTo(expected) != 0) throw new Exception(...);
if (outputRules[0].compareTo(expected) != 0) throw new Exception(...);
  4. Finally, she uploads her data and runs the job (or asks Bob to run it; they both have permission):
    5. job.submitJob(...);

 

Both parties can monitor the progress of the job. When it completes, they can each download from their output stager.

 

Alice knows that Bob can't read Input-A or Output-A because:

  • There is no rule granting Bob read access to either resource, and
  • There is no rule granting Bob permission to change the rules.

Likewise, there are no rules on Input-B or Output-B allowing Alice to do anything.

 

Next: A more complex scenario