I am thinking to use Stardog to support persistent web sessions by recording user and session information in a named graph.I would like to exclude the contents of this graph from any query (except for the web application session queries which would be performed with a special userid and passwd and would refer to this graph).As I read the current spec, I would need to explicitly authorize reading each named graph except the one holding session data for the "webuser" role and authorize for reading and writing the named graph holding the session data for the "session" role.The database is configured so that queries run against all graphs.
This is going to entail some permissions bookkeeping as named graphs will come and go as the database evolves.OTOH, I could put the session information in a separate Stardog database. This configuration would have one session database and N user databases. The only linkage with Stardog security would be a map in the session database to one of a small number of Stardog users (one for each authorization profile) from a large number of users. But - this is just inventing an RBAC model that Stardog already has.IWBNI it was possible to just exclude the one named-graph in a set of role permissions. Using wildcards would work if the role permissions were intersected - for example "named-graph:mydb\* rw" and "named-graph:mydb\sessiongraph --" would combine to exclude "sessiongraph" from being read or written by this role while allowing all other named graphs and the default graph to be read/written. Any chance that this could be implemented? One would want to implement a check to prevent superusers from shooting themselves (or not).
I could kludge together MongoDB and Stardog - there is lots of prefab stuff for node using MongoDB to support persistent sessions. No more needs to be said about this.
--
-- --
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
On Wed, Jul 29, 2015 at 8:57 PM, <jrh...@thematix.com> wrote:I am thinking to use Stardog to support persistent web sessions by recording user and session information in a named graph.I would like to exclude the contents of this graph from any query (except for the web application session queries which would be performed with a special userid and passwd and would refer to this graph).As I read the current spec, I would need to explicitly authorize reading each named graph except the one holding session data for the "webuser" role and authorize for reading and writing the named graph holding the session data for the "session" role.The database is configured so that queries run against all graphs.Correct.This is going to entail some permissions bookkeeping as named graphs will come and go as the database evolves.OTOH, I could put the session information in a separate Stardog database. This configuration would have one session database and N user databases. The only linkage with Stardog security would be a map in the session database to one of a small number of Stardog users (one for each authorization profile) from a large number of users. But - this is just inventing an RBAC model that Stardog already has.IWBNI it was possible to just exclude the one named-graph in a set of role permissions. Using wildcards would work if the role permissions were intersected - for example "named-graph:mydb\* rw" and "named-graph:mydb\sessiongraph --" would combine to exclude "sessiongraph" from being read or written by this role while allowing all other named graphs and the default graph to be read/written. Any chance that this could be implemented? One would want to implement a check to prevent superusers from shooting themselves (or not).If you disabled query.all.graphs, you might be able to selectively construct your active graph in the query such that you get the behavior you're looking for.At some point we might add some facilities for blacklisting named graphs, or wildcards, but those are not on the near term roadmap.