This is a live design document on how to support authorization at the level of project spaces. The primary driver of this development is the SEAD project.
The current design tries to support requirements described in this document:
The following notes are from a meeting on 06/09/15 attended by Indira Gutierrez Polo, Mario Felarca, Winston Jansz, Rob Kooper, Luigi Marini.
Goals:
- Meet the requirements of the above document
- Meet the outcomes of the SEAD all hands meeting in May 2015
- Simplify the design as much as possible to not overwhelm the user and provide a stable implementation within the current efforts
- Accommodate other use cases
Features Needed:
The following are already available in the current implementation:
- A dataset can be in multiple collections
The following need to be implemented:
- A file can only exist as part of a dataset (currently it can exist in multiple or none)
- A dataset can be part of multiple spaces (currently it can exist in multiple or none)
- A collection can be part of multiple spaces (currently it can exist in multiple or none)
- Use permissions on space, collection, dataset page to pick what is available and what is not in the GUI
- Nested collections (which are different from folders because a collection can be in multiple collections)
- Ability to list who has access to a dataset or collection on its page
- (Bonus) Folders in dataset to organize files similar to a file system
Notes:
- Implement access control only at the level of spaces
- Datasets and collections authorization is based on space
- For resources in multiple spaces take the union of permissions
- Only the owner can add a dataset/collection to a new space
- In a world where resources can be in multiple spaces, spaces becomes a view into the data, not a simple self contained place
- What happens if D1 is in C1, C1 is in S1, but D1 is not in S1?