Access control via SPARQL construct queries & stardog rules

joern...@gmail.com

unread,

Apr 26, 2016, 10:41:04 AM4/26/16

to Stardog

Hi,

imagine a big corporate setting, central knowledge repository with many (ongoing) updates (several per second), a lot of triples (>> 1 G) and many users (>> 1 K).

As typical in a big company one wants to have a fine grained, role-based permission model.

What seems best suited is to model roles as SPARQL construct queries to define what each role can see (maybe a bit similar to SQL views).

Now each user can have several roles, there will be many different roles and some of those roles will see nearly everything.

Materialization of the roles into a named graph each seems at least undesirable in such a scenario (many updates, big materialization for probably specific queries...)

So my question is:

Can we somehow use stardog's rules to virtually populate "role named graphs" (without actually materializing), set access control on those and then query them with arbitrary user queries?

We already tried something along the lines of the following, but it seems to completely ignore the GRAPH keyword:

PREFIX rule: <tag:stardog:api:rule:>

PREFIX : <urn:test:>

PREFIX gr: <http://purl.org/goodrelations/v1#>

[] a rule:SPARQLRule ;

rule:content """

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

PREFIX gr: <http://purl.org/goodrelations/v1#>

PREFIX :<urn:test:>

IF {

GRAPH <urn:company:data> {

?offering gr:hasPriceSpecification ?ps .

?ps gr:hasCurrencyValue ?price .

FILTER (?price >= 200.00).

}

THEN {

GRAPH <urn:company:role1> {

?offering a :ExpensiveProduct .

}

""".

Also:

How well do you think this scales?

Would a very specific query (10 results) of a near admin (sees > 1 G triples) have an acceptable query time / memory footprint?

Cheers,

Jörn

Michael Grove

unread,

Apr 26, 2016, 11:45:58 AM4/26/16

to stardog

Have you considering using named graph security?

Cheers,

Mike

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

joern...@gmail.com

unread,

Apr 26, 2016, 12:30:41 PM4/26/16

to Stardog

On Tuesday, April 26, 2016 at 5:45:58 PM UTC+2, Michael Grove wrote:

Have you considering using named graph security?

Yes, we've successfully used that on materialized named graphs before and it's what i meant with "set access control on those" in the previous post.

To my knowledge it doesn't solve the problem of not materializing those named graphs though, does it?

To rephrase:

We'd be happy to use named graph security on graphs that are not actually filled with triples, but built dynamically when queried (to an extent which is sufficient to just answer the query).

We hoped to find the answer in SPARQLRules, but couldn't get that to actually work (as described above)...

Best,

Jörn

Zachary Whitley

unread,

Apr 26, 2016, 12:46:19 PM4/26/16

to Stardog

I think I have a vague idea of what you're getting at. Do you want to enforce access control to the rule? I have an idea that you can try but I've never tried it myself. You can use named graph security, load the rules into the graph you want it applied to and then set query.all.graphs [1] and it should only see the rules that you have access to see.

As far as it "ignoring" the named graph in the rule it makes sense since the Stardog Rules Syntax is based on SPARQL (construct queries I'm guessing) and construct queries don't support named graphs in the construct portion. I could be totally wrong about this so someone will have to chime in and confirm.

[1] http://docs.stardog.com/#_stardog_configuration

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

---
You received this message because you are subscribed to the Google Groups "Stardog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stardog+u...@clarkparsia.com.

Michael Grove

unread,

Apr 28, 2016, 2:48:56 PM4/28/16

to stardog

On Tue, Apr 26, 2016 at 12:30 PM, <joern...@gmail.com> wrote:

Sorry, I misunderstood at first what you were trying to do with the rule.

Rules and axioms are graph agnostic; there's no way to specific where an inference goes, so they are computed based on the active graph of the query and are inferred to be a part of the default graph.

We could make it work with SPARQL rules leveraging the GRAPH keyword so what you're trying to do would work. We'll consider this feature in a future release.

Cheers,

Mike

Best,
Jörn

Zachary Whitley

unread,

Apr 28, 2016, 3:24:03 PM4/28/16

to Stardog

On Thu, Apr 28, 2016 at 2:48 PM, Michael Grove <mi...@stardog.com> wrote:

On Tue, Apr 26, 2016 at 12:30 PM, <joern...@gmail.com> wrote:
On Tuesday, April 26, 2016 at 5:45:58 PM UTC+2, Michael Grove wrote:
Have you considering using named graph security?

Yes, we've successfully used that on materialized named graphs before and it's what i meant with "set access control on those" in the previous post.

To my knowledge it doesn't solve the problem of not materializing those named graphs though, does it?

To rephrase:
We'd be happy to use named graph security on graphs that are not actually filled with triples, but built dynamically when queried (to an extent which is sufficient to just answer the query).
We hoped to find the answer in SPARQLRules, but couldn't get that to actually work (as described above)...

Sorry, I misunderstood at first what you were trying to do with the rule.

Rules and axioms are graph agnostic; there's no way to specific where an inference goes, so they are computed based on the active graph of the query and are inferred to be a part of the default graph.

We could make it work with SPARQL rules leveraging the GRAPH keyword so what you're trying to do would work. We'll consider this feature in a future release.

Cheers,

Mike

I had thought he was trying to tie the rule to the graph only as a proxy to associate the rule to a specific role. I could be totally wrong there. Would role base access to a graph allow or prevent the application of a rule loaded into the graph? ie.

UserA has access to GraphA has loaded RuleA

UserB has access to GraphB has loaded RuleB

Would UserA only see the rule results of RuleA and UserB only RuleB? Would be do access controls apply to rules and axioms or are they extracted before applying access controls?

Best,
Jörn

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

Michael Grove

unread,

Apr 28, 2016, 3:39:13 PM4/28/16

to stardog

On Thu, Apr 28, 2016 at 3:24 PM, Zachary Whitley <zachary...@wavestrike.com> wrote:

On Thu, Apr 28, 2016 at 2:48 PM, Michael Grove <mi...@stardog.com> wrote:

On Tue, Apr 26, 2016 at 12:30 PM, <joern...@gmail.com> wrote:
On Tuesday, April 26, 2016 at 5:45:58 PM UTC+2, Michael Grove wrote:
Have you considering using named graph security?

Yes, we've successfully used that on materialized named graphs before and it's what i meant with "set access control on those" in the previous post.

To my knowledge it doesn't solve the problem of not materializing those named graphs though, does it?

To rephrase:
We'd be happy to use named graph security on graphs that are not actually filled with triples, but built dynamically when queried (to an extent which is sufficient to just answer the query).
We hoped to find the answer in SPARQLRules, but couldn't get that to actually work (as described above)...

Sorry, I misunderstood at first what you were trying to do with the rule.

Rules and axioms are graph agnostic; there's no way to specific where an inference goes, so they are computed based on the active graph of the query and are inferred to be a part of the default graph.

We could make it work with SPARQL rules leveraging the GRAPH keyword so what you're trying to do would work. We'll consider this feature in a future release.

Cheers,

Mike

I had thought he was trying to tie the rule to the graph only as a proxy to associate the rule to a specific role. I could be totally wrong there. Would role base access to a graph allow or prevent the application of a rule loaded into the graph? ie.

Jörn can correct me, but I don't think that's what he was going for.

Strictly speaking, that behavior is what is prescribed in the entailment regime spec. That is, that the schema used at query time is defined by the active graph of the query. This would have the consequence that the TBox would need to be extracted and classified for _every single query_. For any non-trivial schema or database size, that can be significant overhead. So we extract the schema as part of the transaction lifecycle and pre-classify so at query time we only have to rewrite wrt to the active graph for the Abox.

Cheers,

Mike

Zachary Whitley

unread,

Apr 28, 2016, 4:14:40 PM4/28/16

to Stardog

On Thu, Apr 28, 2016 at 3:39 PM, Michael Grove <mi...@stardog.com> wrote:

On Thu, Apr 28, 2016 at 3:24 PM, Zachary Whitley <zachary...@wavestrike.com> wrote:

On Thu, Apr 28, 2016 at 2:48 PM, Michael Grove <mi...@stardog.com> wrote:

On Tue, Apr 26, 2016 at 12:30 PM, <joern...@gmail.com> wrote:
On Tuesday, April 26, 2016 at 5:45:58 PM UTC+2, Michael Grove wrote:
Have you considering using named graph security?

Yes, we've successfully used that on materialized named graphs before and it's what i meant with "set access control on those" in the previous post.

To my knowledge it doesn't solve the problem of not materializing those named graphs though, does it?

To rephrase:
We'd be happy to use named graph security on graphs that are not actually filled with triples, but built dynamically when queried (to an extent which is sufficient to just answer the query).
We hoped to find the answer in SPARQLRules, but couldn't get that to actually work (as described above)...

Sorry, I misunderstood at first what you were trying to do with the rule.

Rules and axioms are graph agnostic; there's no way to specific where an inference goes, so they are computed based on the active graph of the query and are inferred to be a part of the default graph.

We could make it work with SPARQL rules leveraging the GRAPH keyword so what you're trying to do would work. We'll consider this feature in a future release.

Cheers,

Mike

I had thought he was trying to tie the rule to the graph only as a proxy to associate the rule to a specific role. I could be totally wrong there. Would role base access to a graph allow or prevent the application of a rule loaded into the graph? ie.

Jörn can correct me, but I don't think that's what he was going for.

Strictly speaking, that behavior is what is prescribed in the entailment regime spec. That is, that the schema used at query time is defined by the active graph of the query. This would have the consequence that the TBox would need to be extracted and classified for _every single query_. For any non-trivial schema or database size, that can be significant overhead. So we extract the schema as part of the transaction lifecycle and pre-classify so at query time we only have to rewrite wrt to the active graph for the Abox.

Cheers,

Mike

Makes sense. Thanks for the clarification.

joern...@gmail.com

unread,

May 13, 2016, 10:21:43 AM5/13/16

to Stardog

Hi,

thanks for the feedback and sorry for the late follow-up... was busy trying several ideas coming out of this, but sadly can't make any of them work as i'd like...

On Thursday, April 28, 2016 at 9:39:13 PM UTC+2, Michael Grove wrote:

On Thu, Apr 28, 2016 at 3:24 PM, Zachary Whitley <zachary...@wavestrike.com> wrote:

I had thought he was trying to tie the rule to the graph only as a proxy to associate the rule to a specific role. I could be totally wrong there. Would role base access to a graph allow or prevent the application of a rule loaded into the graph? ie.

Jörn can correct me, but I don't think that's what he was going for.

My intention was to (ab-)use rules for access control, as materializing and named graph only access control doesn't cut it in our scenario, so somewhat yes and somewhat no.

Let me make a more concrete example:

We have a corporate wide knowledge repository with the "world" state of knowledge...

For the sake of simplicity let's say it's in data.n3, which looks like this:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:bert a foaf:Person .

:bert foaf:member :corp_group_a .

:peter a foaf:Person .

:peter foaf:member :corp_group_b .

Now i can load this into a named graph <urn:data> like this:

stardog-admin db create -n corpdb

stardog-admin metadata set -o "query.all.graphs=true" -o "security.named.graphs=true" corpdb

stardog data add --named-graph "urn:data" corpdb "data.n3"

GOAL:

Now i'd love to have two users, Bert and Peter who can each only see people from their group (including themselves):

Bert's view (select * { ?s ?p ?o } will return this):

:bert a foaf:Person .

Peter's view:

:peter a foaf:Person .

In this simplistic example it would obviously work to serialise the triples into a named graph per user and set their access control in a way that they only see their named graph, but in practical scenarios with huge views and a lot of updates that leads to a lot of duplicated triples and a lot of caching problems.

Hence, i'd like to actually not materialise the triples into named graphs but instead write SPARQL CONSTRUCT queries per user defining what they're allowed to see.

Such construct queries could be re-written to rules like this:

bert.ttl:

@prefix rule: <tag:stardog:api:rule:> .

[] a rule:SPARQLRule ;

rule:content """

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

IF {

?p a foaf:Person .

?p foaf:member :corp_group_a .

} THEN {

?p a foaf:Person .

}

""".

peter.ttl:

@prefix rule: <tag:stardog:api:rule:> .

[] a rule:SPARQLRule ;

rule:content """

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

IF {

?p a foaf:Person .

?p foaf:member :corp_group_b .

} THEN {

?p a foaf:Person .

}

""".

I tried setting them up in a named graph each and grant access to it by user like this:

for user in bert peter ; do

stardog-admin user add --new-password "$user" "$user"

stardog-admin user grant -a read -o "db:corpdb" "$user"

view_uri="urn:$user"

view_rule_file="$user.ttl"

stardog data add --named-graph "$view_uri" corpdb "$view_rule_file"

stardog-admin user grant -a read -o "named-graph:corpdb\\$view_uri" "$user"

done

As admin i get the following result:

stardog query -r corpdb 'select * { graph ?g { ?s ?p ?o } }'

+----------+---------------+----------------------------------+----------------------------------+

| g | s | p | o |

+----------+---------------+----------------------------------+----------------------------------+

+----------+---------------+----------------------------------+----------------------------------+

Query returned 8 results in 00:00:00.133

Nevertheless, when querying as one of the users, e.g. bert, i only see this:

stardog query -r -u bert -p bert corpdb 'select * { ?s ?p ?o }'

+-------+-------+-------+

| s | p | o |

+-------+-------+-------+

Query returned 0 results in 00:00:00.117

So, am i doing something wrong here or do i maybe completely misunderstand this feature?

Any other tipps on how to achieve "SPARQL CONSTRUCT"-based access control?

Best,

Jörn

Zachary Whitley

unread,

May 13, 2016, 10:55:12 AM5/13/16

to Stardog

So graph views defined by sparql construct queries with access restrictions over these views? You could possibly write a web service that proxies the query and rewrites it based on the user so that your "construct query" is now a sub query and the queries can only access data through that subquery. You'd have to think long and hard about the security implications though.

Michael Grove

unread,

May 13, 2016, 11:30:53 AM5/13/16

to stardog

On Fri, May 13, 2016 at 10:21 AM, <joern...@gmail.com> wrote:

Hi,

thanks for the feedback and sorry for the late follow-up... was busy trying several ideas coming out of this, but sadly can't make any of them work as i'd like...

On Thursday, April 28, 2016 at 9:39:13 PM UTC+2, Michael Grove wrote:

On Thu, Apr 28, 2016 at 3:24 PM, Zachary Whitley <zachary...@wavestrike.com> wrote:

I had thought he was trying to tie the rule to the graph only as a proxy to associate the rule to a specific role. I could be totally wrong there. Would role base access to a graph allow or prevent the application of a rule loaded into the graph? ie.

Jörn can correct me, but I don't think that's what he was going for.

My intention was to (ab-)use rules for access control, as materializing and named graph only access control doesn't cut it in our scenario, so somewhat yes and somewhat no.

Right, I understood what you're trying to do; it's a perfectly reasonable thing to want to do.

I think the salient point was missed in my previous email:

> Rules and axioms are graph agnostic; there's no way to specific where an inference goes, so they are computed based on the active graph of the query and are inferred to be a part of the default graph.

There's currently no way to infer statements into graphs other than the default. This is something we'll consider in a future release.

The schema is extracted from the entire database (or the subset as specified in the configuration) and is the same for _all users_. There's no way to have a ruleset for one user different from another.

If inferences data could be inferred into any graph, with an extended SWRL syntax, the global KB would work since you could restrict bert's access sufficient that it would appear as if only his ruleset was used.