Moved from https://issues.library.cornell.edu/browse/NIHVIVO-3404, dated 5/4/12:
Add another level of security on N3 editing. Once we have determined which statements need to be retracted from the model and which statements need to be added, check that we are authorized to add/retract each of these statements.
If we are not authorized for any of the statements, then don't do any of them. Instead, show the users a message "You are not authorized for this editing operation."
Jim Blake added a comment - 09/Jan/12 11:27 AM
If we fix this issue without addressing NIHVIVO-2935, then VivoPolicy will make some properties un-editable. It's intent is to force the use of a custom form.
Jim Blake added a comment - 30/Mar/12 4:33 PM
This becomes more complex because an N3 editing form may create statements that are inter-dependent. For example, if a self-editor wants to add himself as Author on a Book, the N3 form will create an Authorship with connections to the editor's profile and to the Book.
However, until the self-editor is recorded as an Author of the Book, he has no authority to add a statement that ties the Authorship to that Book.
Does this mean that the N3 editing framework must know the sequence in which the statements must be added to the model? But that would require that the N3 editing framework know the logic contained in the Policies.
The solution seems to be to ask a different question. Instead of asking of each statement, "am I authorized to add this to the model?", we should ask "if I had added all of the other statements in this batch, would I then be authorized to add this one?"
This requires that we change the AddObjectPropStmt and similar RequestedAction classes, so instead of asking "am I authorized to add this statement?" it asks "am I authorized to add this statement to this model?" That way, we can create the model which assumes the other statements have been added, and ask the question of whether we are authorized to add this statement.
As long as we are making these fairly radical changes to AddObjectPropStatement and related RequestedAction classes, it seems like a good time to rationalize the classes a little bit. They are overdue for it.
Jim Blake added a comment - 04/Apr/12 12:03 PM
I have implemented a solution to the previous challenge. However more challenges arise.
Jim Blake added a comment - 04/Apr/12 12:08 PM
Some N3-editing forms are sloppy in the sense that they try to add statements that already exist in the model. It's possible that the user is not authorized to add such statements, but since they already exist they should not be considered a problem.
In discussion with Huda and Brian, we decided that "The user is always authorized to do anything which would accomplish nothing".
So, the user is authorized to add any statement that already exists, or to drop any statement that does not exist. The user is also authorized to add any statement that does not exist if they then immediately delete that statement.
This has not yet been implemented.
Jim Blake added a comment - 04/Apr/12 12:18 PM
We find that it is difficult to implement a policy like "A self-editor can add or drop any statement about himself" at a statement level, since we really mean for this to include relationships to other objects through context nodes.
There is no rigorous statement of what constitutes a context node. That is, they don't all belong to the ContextNode type (there is none). So the best we can do is to make a list of properties that lead to context nodes and say that any object of one of those properties is ipso facto a context node.
But we also want to be able to edit properties of the context nodes, and some of them are implemented through other nodes. In particular, if we are authorized to edit a context node, we should be authorized to create a DateTimeInterval on that node, and to create DateTimeValues than are tied to that DateTimeInterval.
How to implement these authorizations? It doesn't seem that they can be defined by a simple rule, so we need either to explicitly implement them in code, or to create a language by which we can describe them. Possibilities include:
- implement explicitly by method calls against the OntModel, to determine whether relationships exist that permit the request.
- implement by one or more explicit SPARQL queries, to determine the same
- describe some annotation which can be added to properties to signal that authorization is propogated along those properties, and then write framework code which will follow those annotations.
- create a set of rules to describe these authorizations and implement those rules using calls to pellet reasoner.
Jim Blake added a comment - 04/Apr/12 12:20 PM
In addition to the general SelfEditing policy, we also have extensions to that policy which suffer from the same flaws.
For example, we say that any SelfEditor is allowed to edit any document on which he appears as an Author or an Editor, and that is sufficient to display the edit links on that document's page.
However, on a statement-basis, it will allow alterations of the data properties on that document, and on the object properties if they don't involve context nodes. It will not allow the alteration of context nodes that are tied to that document.
Jim Blake added a comment - 04/Apr/12 12:24 PM
The issue has just been emailed to: "firstname.lastname@example.org", "email@example.com", "firstname.lastname@example.org", "email@example.com", with subject: "With regard to statement-level authorization in N3 editing", and content:
This issue just keeps getting more complex. I'm going to put it aside for a while, but I welcome your thoughts and suggestions. Please feel free to add comments.
Jim Blake added a comment - 19/Apr/12 1:21 PM
This has turned into a much larger problem, as we try to define what a self-editor should be able to add, delete or modify. Putting it on the back-burner for now.
Jim Blake added a comment - 04/May/12 1:51 PM
Turns out to be more complex than expected. Exactly what statements should be authorized? What object are we allowed to edit? Date/Time intervales? etc.