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
