Thanks for the questions. Now I have a cleaner explanation to add to the documentation.
On Mon, Sep 9, 2013 at 10:50 AM, Arthur Vaïsse-Lesteven < [email protected]> wrote: > Okay ! We made different choices, but our goals are the same. I thank you > for your quick answer, and for this explanation. > > In my opinion the explanation you give here is a little clearer than the > one on the site. > > I'll surely use this when it will be release. > > VAISSE-LESTEVEN Arthur. > > > > > ________________________________ > De : Claude Warren <[email protected]> > À : [email protected]; Arthur Vaïsse-Lesteven <[email protected]> > Cc : [email protected] > Envoyé le : Lundi 9 septembre 2013 11h36 > Objet : jena-security > > > Arthur, > > I moved this discussion to it's own subject rather than flood the > Approaching release conversation with details of the security > implementation. > > Jena-security is more of a framework that ensures that whatever > implementation you want to apply is easy to execute. > > The work comes from my experience working at DERI on several security > projects there (they had radically different solutions but they all needed > to filter the graph) as well as some work on my own for a side project > (again that project had different requirements from the others). The one > commonality was the ability to filter the graphs or triples that actions > were preformed upon based upon who the user is. > > Jena-security provides a framework to do that. > > It does not specify how to determine who the user is, just that a Principal > identifying the user is available. > > It does not specify how to determine what the user has access to. > > It does require that a developer (integrator?) implement the > SecurityEvaluator so that when the system asks if the current user can > perform an action (say read graph X) there is a yes or no answer. > > The framework does all the work of intercepting the calls to the graph and > making appropriate calls to the Evaluator before allowing the call to go > ahead. There are numerous unit tests to ensure that this is done correctly > and the required permissions are specified in the javadoc for object > classes (e.g. SecuredGraph, SecuredModel). > > Conceptually the framework implements 2 levels of security: graph and > triple. > > The graph restrictions are applied before triple restrictions. So the > system will call > > evaluate( Action action, SecNode graphIRI ); > > to ask can the current user "Read" (Action) graph X (graphIRI) as > evaluate( Action.READ, X ) > > if the answer is yes then the system will call > > public boolean evaluate( Set<Action> actions, SecNode graphIRI, > SecTriple triple ); > > to ask if the current user can "Read" (Action) from graph X (graphIRI) all > triples (SecTriple) as evaluate( Action.READ, X, SecTriple.ALL ) > > if the answer is yes then the system will execute the call, if the answer > is no then for each potential triple the user might read the system will > call > > public boolean evaluate( Set<Action> actions, SecNode graphIRI, > SecTriple triple ); > > to ask if the current user can "Read" (Action) from graph X (graphIRI) the > triple in question (<triple>) > > It performs similar checks for all creates, reads, updates and deletes. > (CRUD). And it does this for all classes that can be returned from the > secured classes. For example an RDFList returned from a SecuredModel is > secured so that the filtering above is performed against the items in the > list. > > I do not have any bibliographic references for this work, however my early > work was influenced by Owen Sacco http://www.deri.ie/users/owen-sacco and > his work on security while at DERI. > > Claude > > -- > I like: Like Like - The likeliest place on the web< > http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
