Personal tools
 

A more complex scenario

In this scenario, one of the partners needs to check their part of the output before allowing the other party to read theirs.
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 2 of 2.

In this section we extend the previous scenario with a new requirement: Alice is not permitted to see her part of the output without Bob's permission. This is typically the case if Bob will need several iterations of the job to get the output correct. Once Bob is happy with the results, he will allow Alice to see hers. Bob still never actually sees Alice's results, however.

A more complex scenario.

The challenge here is to allow Bob to grant Alice read access to her results, without also allowing Bob to give himself read access. We can do this by introducing a new role and a couple of new PBAC states: empty-locked and full-locked. The sequence will now look like this:

  1. Bob creates the job as before.
  2. Bob adds a rule to Output-A granting himself the unlocker role and puts it into the empty-locked state.
  3. Bob then transfers control of the manager role to Alice, as before.
  4. When the job finishes, Output-A moves from empty-locked to full-locked. No-one can read the data while it is locked.
  5. Bob checks Output-B. When he is happy with the results, he unlocks Output-A, allowing Alice to read it.
As it happens, the data stager state model already has some locked states, but it uses them to prevent changes to the contents (i.e. as a write-protect feature). Ideally, we would add some different states and new operations to lock and unlock. However, the data service doesn't allow us to add extra operations so we're going to change the behaviour of the existing lock and unlock

operations instead.

 

We need to ensure that:

  • When a stager is locked, no-one can read it until it is unlocked.
  • When a stager is locked, no-one else can be granted the unlocker role (otherwise Alice can just make herself an unlocker).

Here is a suitable policy, which you can upload as before: lockable-data-policy.xml.

Previous: Running a job with inputs and outputs owner by different parties