...
Note: This 'enhanced' security model can be used in advance of creating services for defining roles: We can define the currently required roles 'in the backend' and later add services and UIs for defining new roles.
Workflow Model
One design approach, explored below, is to put the workflow sequence in an external workflow system. An alternative is to put it in Synapse.
Tier 1 Approval Process
Here the user signs the Tier 1 agreement upon account creation and is added to a "Tier 1 group". The group has the Download role for all Tier 1 data layers.
...
Version 1: Synapse interacts with User. This is not feasible since the User-Synapse interaction is synchronous while the Synapse-WF interaction is meant to be asynchronous (at least for the SWF workflow system). | Version 2: Synapse starts workflow; Worker interacts with User via email |
|---|---|
| |
Below we see an alternative for synchronous user interaction.
Tier 2 Approval Process
This approval requires two hurdles, the Tier 1 agreement plus a new agreement which may be specific to the requested layer. Upon approval Synapse adds the User to the Access Control List for the Layer.
The following variation has the properties that (1) interaction between Synapse and the User is synchronous, (2) there is no representation of the required workflow in the client, (3) there is no representation of the workflow *state* in the back end:
This approach is based on the pattern used by "Basic Authentication", e.g. http://httpd.apache.org/docs/1.3/howto/auth.html#basicworks
in which a request can be denied, the denial containing information about what's required for the request to be approved.
Note: the "/accessRequest" service 'knows' to check that eula 456 is signed before adding user to group 789
changed services:
GET /layer: has to check whether there is an approval process and, if so, include the final step in the rejection
new services:
/accessRequest: checks precondition; can (1) add user to group or (2) add Role to User
POST /approvalProcess: creates an approvalProcess object whose parent is a Layer and
whose content is the sequence of requests that need to be fulfilled (specific to the layer)
POST /accessRequirements: creates an object containing the requirements for adding a User
to the ACL for an entity (e.g. the user must have signed a certain EULA)
Design considerations:
System does not track the 'state' of the approval process. That's left to the client. The risk is that the process might have to start over if it fails partway, but the benefit is in simplifying the server.
How do you set up an approval process?
POST /accessRequirements
POST /approvalProcess
How do you revoke approval?
1) remove the <User, Role> from the layer's ACL (or the <Group, Role> if all the users were added to a group)
2) delete the approvalProcess and accessRequirements objects
Tier 3 Approval Process
Here we have the added complexity of an external IRB. An "IRB daemon" is added to send approval requests to the IRB and to listen for replies. The interaction with the user is asynchronous: While waiting for approval the user may do other things (though not access the requested layer). Finally she receives an email saying the request was approved.
...