[jira] [Created] (JENA-1666) Securing TDB dataset with SecurityEvaluator

[Vasyl Danyliuk (JIRA)]

Vasyl Danyliuk created JENA-1666:


 Summary: Securing TDB dataset with SecurityEvaluator
 Key: JENA-1666
 URL: https://issues.apache.org/jira/browse/JENA-1666
 Project: Apache Jena
  Issue Type: Question
  Components: Fuseki, Jena, Permissions, Security, TDB2
Reporter: Vasyl Danyliuk
Assignee: Claude Warren


Hi guys,

Can someone take a look if approach used in [this 
repository|https://github.com/linked-solutions/fuseki-auth] can be incorporated 
into Jena Permission project? Also, there is a question on 
[StackOverflow|https://stackoverflow.com/questions/54268950/how-to-secure-all-newly-created-graphs-in-apache-fuseki-with-securityevaluator]

The main idea is to apply SecurityEvaluator to whole dataset instead of one 
graph.

This repository, of course, is not ready to be incorporated just now, but if 
it's possible in general and does not conflict with the structure/architecture 
of the project I will refactor it to be more consistent.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1663) ModelAssembler does not protect prefix manipulation with a transaction.

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16762271#comment-16762271
 ] 

Andy Seaborne commented on JENA-1663:
-

[~ashleysommer] - thanks for the report.  It looks like an execution time 
variation of the problem of the original report for the ticket. 

 

Here, the {{MultiUnion}} is not fully pushing down the transaction to the 
component graphs.

 

 

> ModelAssembler does not protect prefix manipulation with a transaction.
> ---
>
> Key: JENA-1663
> URL: https://issues.apache.org/jira/browse/JENA-1663
> Project: Apache Jena
>  Issue Type: Task
>  Components: Core
>Affects Versions: Jena 3.10.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.11.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Another extra module

[ajs6f]

Agreed. Graphana is a very useful product (although I've only ever seen it 
deployed for IT monitoring and performance-- I don't know how much adoption it 
has outside of that) but a more generic solution would be best.

There are also some interesting potential "metrics" that would be specific (or 
nearly so) to Jena. For example, what if you wanted to track the action of your 
inferencing machinery?

ajs6f

> On Feb 6, 2019, at 3:39 AM, Bruno P. Kinoshita  wrote:
> 
> Hi Claude,
> 
> Wouldn't it be easier to actually have a module for exposing metrics, like 
> jena-prometheus? Or jena-metrics? JupyterHub does that 
> (https://github.com/jupyterhub/jupyterhub/blob/master/jupyterhub/metrics.py), 
> but it's as easy to implement that in Java as in Python.
> That way you could display the metrics on Graphana 
> (https://prometheus.io/docs/visualization/grafana/), or Kibana 
> (https://www.elastic.co/guide/en/beats/metricbeat/master/metricbeat-module-prometheus.html),
>  or even plug into another monitoring system like Nagios 
> (https://github.com/prometheus/nagios_plugins), Zabbix 
> (https://www.zabbix.com/integrations/prometheus), etc.
> 
> Having some Zeppelin module/kernel (use Python notebooks, but guess there's 
> something with the same name) would be interesting. Write SPARQL queries, 
> show how the installation of Jena Text can be done, with assembler files with 
> syntax highlighting. There are a few possible use cases, though I suspect it 
> should be possible to do these items with Python Notebooks/Zeppelin now (plus 
> some glue code).
> CheersBruno
> 
>On Wednesday, 6 February 2019, 8:19:54 pm NZDT, Claude Warren 
>  wrote:  
> 
> My understanding of Graphana is that they provide charts (aka visual graphs
> but just to keep the nomenclature clear I will call them charts) for data.
> They are source agnostic and currently talk to a number of databases.  The
> idea is to allow a user/admin to create queries that would be charted by
> Graphana.  Very early investigation.  I was just wondering if such a module
> would be a good fit for the "extras".
> 
> I also think that having adapters to make it easy to pull and display data
> from Jena/Fuseki might bring an up-tick in adoption.  At one time I thought
> about Zeppelin as a frontend.
> 
> Claude
> 
> On Tue, Feb 5, 2019 at 10:25 PM ajs6f  wrote:
> 
>> This would make Graphana metrics appear as RDF in the Jena API?
>> 
>> ajs6f
>> 
>>> On Feb 3, 2019, at 2:40 PM, Claude Warren  wrote:
>>> 
>>> After spending some time at FOSDEM this weekend, i am going to look into
>>> creating a Jena adapter for Graphana.  Is this the sort of module we
>> might
>>> consider for inclusion as an extra module?
>>> 
>>> Claude
>> 
>> 
> 
> -- 
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Another extra module

[Bruno P. Kinoshita]

 Hi Claude,

Wouldn't it be easier to actually have a module for exposing metrics, like 
jena-prometheus? Or jena-metrics? JupyterHub does that 
(https://github.com/jupyterhub/jupyterhub/blob/master/jupyterhub/metrics.py), 
but it's as easy to implement that in Java as in Python.
That way you could display the metrics on Graphana 
(https://prometheus.io/docs/visualization/grafana/), or Kibana 
(https://www.elastic.co/guide/en/beats/metricbeat/master/metricbeat-module-prometheus.html),
 or even plug into another monitoring system like Nagios 
(https://github.com/prometheus/nagios_plugins), Zabbix 
(https://www.zabbix.com/integrations/prometheus), etc.

Having some Zeppelin module/kernel (use Python notebooks, but guess there's 
something with the same name) would be interesting. Write SPARQL queries, show 
how the installation of Jena Text can be done, with assembler files with syntax 
highlighting. There are a few possible use cases, though I suspect it should be 
possible to do these items with Python Notebooks/Zeppelin now (plus some glue 
code).
CheersBruno

On Wednesday, 6 February 2019, 8:19:54 pm NZDT, Claude Warren 
 wrote:  
 
 My understanding of Graphana is that they provide charts (aka visual graphs
but just to keep the nomenclature clear I will call them charts) for data.
They are source agnostic and currently talk to a number of databases.  The
idea is to allow a user/admin to create queries that would be charted by
Graphana.  Very early investigation.  I was just wondering if such a module
would be a good fit for the "extras".

I also think that having adapters to make it easy to pull and display data
from Jena/Fuseki might bring an up-tick in adoption.  At one time I thought
about Zeppelin as a frontend.

Claude

On Tue, Feb 5, 2019 at 10:25 PM ajs6f  wrote:

> This would make Graphana metrics appear as RDF in the Jena API?
>
> ajs6f
>
> > On Feb 3, 2019, at 2:40 PM, Claude Warren  wrote:
> >
> > After spending some time at FOSDEM this weekend, i am going to look into
> > creating a Jena adapter for Graphana.  Is this the sort of module we
> might
> > consider for inclusion as an extra module?
> >
> > Claude
>
>

-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren