...
- Data layer access in Synapse requires one or more approval steps.
- In Synapse granting data access is synonymous with providing the URL to the stored data.
(This URL may have an embedded access token.)
- Currently (i.e. as of Jan. 2012), the backend has a representation of EULAs and of Agreements (i.e. that a particular user agrees to a EULA)
- The work flow logic for creating the agreement is embedded in the Web client, so other clients would have to maintain duplicate logic.
- There is no provision in our permissions scheme for an "IRB role" which can grant or revoke 'download permission' to a user.
- If the approval process changes, a user who has already been approved needs to go through the approval process again.
- Currently we've identified three tiers of access restriction/approval:
...
2) Instead of granting individual permissions on an entity to a principal, we grant a role to a principal
So instead of <Principal, Entity, AccessType> we have <Principal, Entity, Role> where Role=<Property, AccessType>.ACL=<Entity, {<Principal, AccessType>}> (where "{}" indicates a set and "<>" a tuple) we have ACL= <Entity, {<Principal, Role>}> where Role={<Property, AccessType>}. (Q: Is a 'role' entity specific? How do we grant access to non-property aspects of an entity?)
Under this model we can separately grant read access to a layer's basic properties (name, created date, description) and its location. Read access to a layer's location is the equivalent of download access.
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
Should the approval process be represented on the server side (e.g. in the repository)?
How does *approval state* map to *permissions*?