You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Claude Warren <cl...@xenei.com> on 2013/09/09 11:36:09 UTC
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
Re: jena-security
Posted by Claude Warren <cl...@xenei.com>.
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 <
arthurvaisse@yahoo.fr> 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 <cl...@xenei.com>
> À : users@jena.apache.org; Arthur Vaïsse-Lesteven <ar...@yahoo.fr>
> Cc : owen.sacco@deri.org
> 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
Re: jena-security
Posted by Arthur Vaïsse-Lesteven <ar...@yahoo.fr>.
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 <cl...@xenei.com>
À : users@jena.apache.org; Arthur Vaïsse-Lesteven <ar...@yahoo.fr>
Cc : owen.sacco@deri.org
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