Datasets and Access Rights (structWSF)
From TechWiki
structWSF is guided by a flexible access and rights system that is linked to individual datasets. Different datasets can have different users and permissions. When combined with an external CMS system, these access rights can also be governed by profiles (patterns of users and access rights) and assignments to one or more user groups.
In this way, data can be made public or private; can be read only or altered; or data can reserved for internal work group purposes. Moreover, by using different profiles, a smaller group of owners or curators, defined in groups or not, may have creation, update or deletion rights different than various classes of general users or the public.
This simple but elegant system works as follows. First, every Web service is characterized as to whether it supports one or more of the CRUD (create - read - update - delete) actions. Second, each user is characterized as to whether they first have access rights to a dataset and, if they do, which of the CRUD permissions they have. We can thus characterize the access and use protocol simply as A + CRUD.
Thereafter, a simple mapping of dataset access and CRUD rights determines whether a user sees a given dataset and what Web services ("tools") are presented to them and how they might manipulate that data. When expressed in standard user interfaces this leads to a simple contextual display of datasets and tools. Note that if a user is not granted access rights to a tool or dataset, they are not shown in the user interface nor participate in search or browse functions.
Here is the basic matrix of these possible assignments:
| Web Service | Access | Create | Read | Update | Delete |
| Auth Registrar: Access | X | X | X | X | X |
| Auth Registrar: WS | X | X | X | X | X |
| Auth: Lister | X | X | |||
| Auth: Validator | X | X | |||
| Ontology: Create | X | X | |||
| Dataset: Create | X | X | |||
| Dataset: Read | X | X | |||
| Dataset: Update | X | X | |||
| Dataset: Delete | X | X | |||
| CRUD: Create | X | X | |||
| CRUD: Read | X | X | |||
| CRUD: Update | X | X | |||
| CRUD: Delete | X | X | |||
| Search | X | X | |||
| Browse | X | X | |||
| Import | X | X | X | ||
| Export | X | X |
At the Web service layer, these access values are set parametrically. The system, however, is designed to more often be driven by user and group management at the CMS level via a lightweight plug-in or module layer.
Groups, Datasets & Profiles
In actuality, the simple matrix above is a bit more involved in practice. That is because each cell in the matrix above is divided into a number of possible groups or assignments: owner, group, registered user, and the general public (anonymous). The "group" assignment can be from as many different groups as desired.
Owners (or curators) generally have the broadest rights including creation, update and deletions. But, these same rights can also be enabled for trusted colleagues as members of defined groups.
Of course, if desired, any and all restrictions by action, dataset or user type can be removed. This might be desired, for example, for demos and sandbox applications.