On Sat, Nov 16, 2019 at 9:57 PM Andy Seaborne <[email protected]> wrote:
> > > What would be the requirements for permissions-extensions? If not in > use, I'd like it to be invisible - security can also be in application > via request processing (the usual ACL stuff). > All the permissions are implemented via a SecurityEvaluator interface. (that should be changed to PermissionsEvaluator). Currently the wrapper uses dynamic proxies to call the SecurityEvaluator, but much of that code could be moved into a class (call it PermissionsContext here) that we could put into the context. If permissions were being the PermissionsContext class would have the SecurityEvaluator otherwise it would be null. The method that perform CRUD operations on the model or graph would call to the PermissionsContext to see if the operation was permitted. The default permissions context would simply return true for all calls, a permissions context that was active would make calls to the security evaluator to verify permission. Failure of the permission yields an OperationDeniedException. We currently have OperationDeniedException and children thereof for Permissions errors. This change would require the creation of the PermissionsContext (and a way to instantiate it) and each method that performs a CRUD operation would have to make the call check the permissions. The current permissions system maintains a cache of recent checks so that the overhead for common requests is low. I am curious as to whether the permissions capabilities could be > provided at the Graph level on find/add/delete. > > > That is provided currently in the Permissions layer. However there is a difference between calling Graph g = Permissions.Factory.getInstance( Evaluator, name, Graph); Model m = ModelFacotry.createModelForGraph( g ); and Model m1 = ModelFactory.createModelForGraph( Graph ); Model m = Permissions.Factory.getInstance( Evaluator, name, m1); In the first case all the permissions checking is performed on the graph and the graph has no concept of Update so to perform the update operations on the graph the user has to have "delete" and "create" permissions. In the second case the model has an update operation so the user only needs to have "update" permissions. The specific case is model.createList() which replaces triples in a graph by deleting and inserting. Permissions currently requires a new concept: the Future node. I don't know if this has use anywhere else but the Permissions system has to be able to ask the security evaluator if the user can perform an operation where the specific node is unknown (e.g. an operation that will create an anonymous node like createList(). I just mention this because it is in the system and may be of use to other components. Claude
