Usecase 2 - A streamlined and secure way of distinguishing open from closed data
Title (goal) | A streamlined and secure way of distinguishing open from closed data |
|---|---|
| Primary Actor | curator |
| Scope | |
| Level | |
| Story | the curator manages three collections: a completely open one, a mixed access collection (e.g. password-access to copyrighted materials), and a completely dark one (e.g. personally identifiable information). The cost to the institution of anything dark accidentally being made public is high. However, materials do sometimes intentionally move back and forth (bidirectionally) between open, mixed, and dark. The curator needs this process streamlined.
Explanation: right now there are really two ways of distinguishing between a dark and an open Fedora collection. The wholly secure way to have entirely segregated Fedora instances on entirely different systems; This solution has minimal convenience. The wholly convenient way is to trust to XACML, FESL, or something higher level such as Hydra access controls; this solution relies on the shifting landscape of Fedora access controls for something with a high risk cost. Is there a middle ground between the two models? |
4 Comments
Michael Durbin
The features available in Fedora 4 (alpha 4) allow at least one relatively easy way to organize your content and authn/authz scheme to support this use case.
Because access restrictions are inherited through Fedora 4's native hierarchy you could have root level nodes such as "dark", "mixed" and "open". You could apply a very restrictive group access policy to the "dark" node and rest assured that everything below that path would only be accessible to Fedora administrative users and more relaxed rules to the other base nodes. Everything under the path dark/ would be inaccessible and everything under open/ would be accessible. You can configure your servlet container to require authentication for every path except those under "/open/".
With such an organization you could manage your access control simply by moving your resources between these "buckets" which define the access policies. While this may not be the clearest organization for all content, when access restrictions are paramount, this might make sense.
Andrew Woods
Having three separate "workspaces" may also be a similar option.
David Wilcox
As of 4.0-Alpha-4 there are some viable options to satisfy this use case. We just need to contact the author to verify - would that be Deborah Kaplan?
David Wilcox
This use case can be considered satisfied unless we receive feedback to the contrary from the owner or the broader Fedora community.