...
- In the entity schema we allow a field to have a (some?) permission(s) which a user need to have before the field can be accessed.
- We add a 'LocationDownload' permission to the location field of the Layer entity. To control download ability on a Layer, we control whether a user has the "LocationDownload' permission on the Layer.
Workflow Model
Design Assumptions
Things the client should
...
NOT 'know'
- what requirements need to be met to access a Layer's location obtain a permission (e.g. you need to sign a EULA to access a Layer's location)
- what requirements have/have not been met by a User (e.g. whether a EULA has been signed)
...
- how to fulfill a requirement (e.g. if a EULA needs to be signed, knows how to retrieve and display the EULA, get it signed, and submit the appropriate request to the repo service)
Design Approach
The
...
permission service
- Add a new service 'permissionRequirements'permission' service which (1) grants permissions if requirements are met or (2) otherwise reports what requirements need to be met. E.g. GET POST /permissionRequirementslayer/101/permission/Download, where '101' is an entity ID, would either (1) grant the requested permission (Download) if the user meets the requirements or (2) return a (401) response with a body of the form
| Code Block |
|---|
{
Location:[ {type:EULA, params:{uri:/eula/987}, msg:status-msg}, {type:EULA, params:{uri:/eula/654}, msg:status-msg}, {type:ACT, params:{uri:/act/321}, msg:status-msg}]
}
|
The response lists listing the unmet requirements for each permission associated with the object, in the form <permission>:<requirement-list>.
(Optionally, just one of multiple unmet requirements could be returned, allowing the server to control the order in which requirements are considered by the client.)
There are three parts to a requirement:
- type: from an ENUM, e.g. 'EULA', 'ACT'.
- params: a map of parameters used by the given 'type'. The client needs to know what to do for each enum, and how to use its parameters. This will be documented in the developers' API.
- msg: An optional status message, suitable for display to the user.
If a requirement has no type or params but has a message, then there is nothing for the user to do and the message helps explain why, e.g. {msg:"ACT approval pending"}(Optionally, we could include this in the body of a 401 response.)
Permission
...
Manager
The repository service will have a Permission Requirements Manager, which computes the response to the /permissionRequirements permission request from a given user for a given entity. E.g. if a Layer required EULA 987 to be signed for a user to access it, and EULA 987 is not yet signed by the user, then the Permission Requirements Manager adds this requirement to the response to the /permissionsRequirements thepermissions request. The unmet requirements are stored *implicitly* in the state of the repository services, and the PRM PM determines the 'requirements gap' on the flyunment requirements upon request.
Object Model for Permission Requirements
An entity may have Requirement child entities (or should these be properties of an entity?). These entities (properties?) contain the details of what is required to obtain specific permissions on the object (e.g. <Location<Download,EULA,/eula/987>). The PRM PM refers to these objects entities (properties?) to make its assessment.
Additional Services
...
- requirements CRUD services: allows the owner of an object to craft requirements for an object (or should this be rolled into the current permissions managermanagement?)
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.
"WF" refers to an envisioned workflow system which knows the approval workflows and can tell each participant what its next step is.
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.
...