-
Notifications
You must be signed in to change notification settings - Fork 0
Security Model
| User Permission | view (read or find) | edit | run | delete | grant (edit permissions) |
|---|---|---|---|---|---|
| none (object is private) | X | X | X | X | X |
| none (object is public) | ✓ | X | ✓ | X | X |
| run | X | X | ✓ | X | X |
| read | ✓ | X | ✓ | X | X |
| write | ✓ | ✓ | ✓ | X | X |
| own | ✓ | ✓ | ✓ | ✓ | ✓ |
- Permissions are relations between a user and an object. A user must own an object to set permissions that affect it.
- Processes (running functions, etc) have the permissions of the user that started them.
- Created objects are private and owned by their creator, by default. Unauthenticated users cannot create objects.
- Unauthenticated users have no permissions on any objects
Besides particular users (defined by username) there are 2 user groups that can have permissions on an object:
- any - any user. anonymous users use this permission set
- local - any user local to this clotho instance
Field permissions are defined on the Schema, and thus can be edited by any user with edit permissions on the Schema object.
Field visibility levels and associated behavior:
Clotho uses Apache Shiro to manage authentication (users, passwords, logins) and authorization (what a user can see and do.) I suggest you familiarize yourself with Shiro by reading the 10 minute tutorial, the authentication guide and the authorization guide; these will get you up to speed with the concepts and terminology.
Clotho manages security by implementing its own Shiro Realm, o.c.c.security.ClothoRealm. (This dependency is injected using Guice; the injection module is o.c.c.security.ShiroWebModule.) The underlying interface that gets and updates accounts, groups and permissions is o.c.c.security.CredentialStore; it is implemented by o.c.c.persistence.jongo.JongoConnection, which stores the credentials in the MongoDB database that the rest of the Clotho objects are stored in. The credentials and roles are stored in the Mongo collections cred and roles, respectively.
The Clotho Realm also has one special Subject, the singleton class ServerSubject. This is a subject with the username o.c.c.s.ServerSubject.SERVER_USER (currently _server) that has all permissions on all objects. This Subject is used for things like initializing the persistor and setting up test data in ClothoTestEnvironment.
These are two different subjects, but they relate to each other, so I will discuss them here. Permission deals with whether the system allows certain requests, while Attribution is the assignment of legally-recognizable acknowledgement of the contribution of an individual to the current state of a Sharable. The distinction between Permission and Ownership, as described by SP, is around two specific permission concerns: deleting a sharable and changing its permissions, and thus ownership is just a state of the more general set of concerns that are Permissions. Attribution and Authorship similarly have this relationship. Attribution deals generally with who contributed to a project and what exactly did they do. First let's consider the things that are generally attributed to projects that could be applied to sharables:
- Direct Authorship: this means who has ever called set, get, create, destroy on a Sharable
- Project Management: added value to the Sharable through a means other than its direct reduction to practice
- Organizational Management: they wrote the grant, were the VP in charge of the project, etc.
- Institutional Management: they hired the authors during the time they did the work, the author was affiliated with the institution when the work was performed.
The simplest attribution framework would just have you add a name and a comment to a list, but I think these topics can (and should) be more robustly and automatically handled. In such an automated system, it will be necessary to distinguish these different aspects of contribution because there would not be comments explaining people's roles. If I want to make legal claim that a person made a technical contribution to a project, it is only necessary that I get them to do some trivial thing, like add a @bob to the text. So, you can compress attribution to the 'Direct Authorship' model, but this doesn't really capture what they did. For patents, the first two tiers of contribution here would be considered 'inventorship' while organization management and institutional management would have implications for 'ownership' but not 'inventorship'. Thus, these distinctions need to be captured in an automated system. So, let me try to define these things in operational terms:
- Direct Authorship: This one is easy. For redo/undo/redo functionality we are already capturing the revision history of the Sharable. Ideally this is captured directly, or via query, as data structures like: { "sharable" : "id_of_sharable_that_was_modified", "operation" : "SET", "user" : "id_of_user_that_did_it", "newvalue" : {...}, "dateModified" : "2009-04-12T20:44:55" }
From a trace of such data through time, you could contruct a diff between any version and the previous version and thus deduce exactly what the user contributed. Thus, maintaining this 'sharable modification' history will enable software to enumerate who did one in terms of direct authorship.
-
Project Management: I don't really think this must be distinguished from conventional authorship. It just requires that the manager's contribution is captured in an electronic form. There is never a way to capture a contribution that is not recordered. You could capture a meeting as a video, you could collect a recording of a phone call, you could upload a comment containing notes from a meeting, you could provide a link to wiki edits. All these evidentiary objects could be captured as Sharables. As long as it is possible to arbitrarily link Sharables to an object (ie, the Sharable has a Set or it can be constructed by query by a dedicated xref table), then there are no extra pieces required to capture managerial contributions to a project. Of course the mechanisms for generating video sharables and so forth require coding, but these are just Functions, Schemas, and Instances that would exist in the dynamic layer and thus have no special consequences to the core.
-
Organizational Management: This is the property that ICE makes an attempt to capture: which grant was an entry associated with. In Clotho, the notion of a grant could (and should!) be captured as a Schema. It could be arbitrarily appended to a Sharable if you can arbitrarily add links to a Sharable, as discussed above. Any Grant instance would minimally need: { "agency" : "NSF", "program" : "Biosustainability for a better future", "pi" : "id_of_Person_who_is_the_official_pi", "co-pi" : ["id_of_copi1","id_of_copi2"], "dateFunded" : "2009-04-12T20:44:55" }
But would probably have more stuff. That info would be sufficient to capture the required info for constructing the contributions done during the period that the work was funded by the grant. When a Sharable is being constructed under one Grant's funding, you attach the link from the Grant to the Sharable. When that funding ends, you remove the link. The history of the linkage existing is still persisted because all the objects modifications are captured in the revision history. Thus this also deals with the problem of an object that was under one funding stream during one period of development, and under another during a later phase of development.
- Institutional Management: For this we need to model the institution, which we have already done (in a preliminary form) with Institution and Lab. There needs to be linkage between the LabPerson and the Lab, which I think we also capture already. Because there are dates in the versioning history associated with when a user's affiliation changes, it can be algorithmically deduced whether the user was associated with the Lab or the Lab was associated with the Institution. The abstraction "institution" should not only apply to Universities. It could also be government labs, NGOs, or companies. Thus, we should probably redefine the Institution Schema to more close match the legal definition of an Institution, and probably rename the top level abstraction to "Organization". Point being, there is already well-established legal definitions for Organizations and definitions of what information must be provided to the government to establish that legal status. The Schemas in Clotho should capture this. If this is done consistently with legal definitions and terms, then attribution can be algorithmically defined in that context. It just requires Schemas for these things exist, and that they have linkages to the Users.
In summary, what we need to enable attribution is first the ability to 1) persist the versioning history, and 2) append arbitrary sharables to another sharable. Clearly there are additional things needed to perform the crawl through the data and apply date logic and collate it all into reports. However, this is just a Function. There also need to be UI means of facilitating all this. For example, when a User leaves one Organization or joins another, ideally that is being done in Clotho and thus these functionalities are managed by Clotho -- which they are, as long as there is a Schema describing those objects.
Licenses provide the linkage between attribution and permissions. Consider BSD. The act of applying a BSD license is equivalent to saying that a Sharable is now publically viewable and copyable, but not editable--it is open source and open use, but not open development. A specific license between two entities means that any read, write, delete, etc. permissions are being changed from one set of users to another set. Thus, applying a License is an action, and thus could be captured as a Function, such as "ApplyBSD". That Function would take as argument the Sharable being modified, and would change all the permissions. Because only an owner can change permissions, only an owner could successfully execute a call like clotho.run(ApplyBSD, [shar1, shar2]). In this arrangement, a License is simply a component of dynamic content, and is unknown to Clotho's core. Let's consider another example: Apache license. Here, the Function is very similar to ApplyBSD because in terms of the Permissions granted, Apache and BSD are the same (I think, or at least consider that true for purposes of discussion). What Apache also requires is that a readme file of sorts be included with distribution of the code. That could be captured generally by having a License object, of which Apache is an Instance that includes the readme file, and this can be arbitarily appended to a Sharable, and that can be part of the ApplyApache Function to add that appendage. So, I think that is still fine. Consider, though, the GNU license where the implications of the license are viral. Meaning, any Sharable that becomes appended to the GNU-licensed Sharable should also automatically have its permissions changed to reflect this. Implementing such functionality would require that Clotho be aware of the existence of the license. Like, when a user calls SET on a Sharable to append the linkage, Clotho would need to inspect the linked Sharable, look for GPL licenses, and change the permissions. That would require a license-aware Clotho and thus affects core development. I'm not sure what the right solution is here. I tend to prefer a license-unaware Clotho, but I don't see how you would deal with viral licenses.
One solution here, that keeps Clotho mostly unaware, is to include a Permission for "can transfer" which is inspected when a dependency stack is inspected in a copy request. We don't currently have 'copy' as an API method, presumably because it can be expressed as a macro of 'GET' followed by 'CREATE'. Let's suppose I GET then call CREATE on a Feature that is heavily decorated with licenses and other info. The GET request will return data with the depth specified by the Schema, and unless I specify full depth I will get just the top-level objects. If I then call create on this object, the new URL is presumably the recipient sister's URL followed by the same ObjectId. Thus, the new object has a new complete URI, but internally to the recipient sister the ObjectId would refer to the local copy. That all seems appropriate. The internal references to licenses, grants, etc. would not be transferred to the recipient under such conditions -- the depth of the copy depends on the depth of the data pull and whether the URIs returned in the GET request specify just the ObjectId or also provide the full URL+ObjectId. If the 'appended' objects are not always included in a GET, then the copy lacks them. That is fine as long as those items were not meant to be viral. Ihe viral nature of GPL and many business-to-business agreements (ie, you MUST allow others to GET the object, or you MUST-NOT allow GETs) will get lost when the object is copied.
I tend to think the right way to license is to keep it simple and administrative. Like, if you don't want the internal guts of your software/code/parts/etc. to be cloned by a user, you don't allow 'GET', and if you do need them to be able to clone, then you make that object public. You control this access as the owner of the Sharable on your instance of Clotho, and it is your legal responsibility to apply the appropriate GET permissions. The rationale here is that it is never cost effective to deal with licensing through lawyers. Ideally it is enforced mechanistically whenever possible. If a legal agreement leaves one controlled domain and goes to another, there is no way to control anything about what they do with it. If they do something you don't like, then there is at least an evidence chain on both ends as to what was done. If you as a user changed the 'GET' permissions of a GPL-licensed Sharable. So, if you don't want them to clone things, you don't allow them to get things. This doesn't deny them access to those objects. They may still be able to run a non-gettable Function, but execution happens on the donor sister via a relay.