Hi,
Is it possible to set a fine grain security by which we control who can access each class and property based on the values? I know we can use different named graphs but that is not detailed enough.
We would need to be able to define user roles to which we would assign access rights. And then assign those roles to users.
Thanks
Daniel
I get the gist of what you're asking but what do you need that is more detailed than named graphs? You can have a named graph with a single statement. Can you detail more specifically what your requirements are?
The most likely way forward is to write a custom named graph security manager but as with anything and security the devil is in the details.
Hi Zachary,
Thanks for your answer. It is true that security can get very complex and hard to implement.
I believe our use case is not something that can be handled by creating named graphs however. We just would have too much of them and that would be too hard to maintain. And that would probably not be enough anyway.
In fact, we have different use cases but they follow a common pattern. For one of them, we have portfolios in which some organizations are involved. We would want to limit the access to the portfolios and to the organizations associated to them. And the same thing for all other information linked to the same organizations. That's a long path but everything is about filtering by portfolios, directly and indirectly.
There is an implementation in the RDBMS world that is called Virtual Private Database. The virtualization is put in place by adding, in the background, some filtring rules in the where clause of every select statement. Something similar would deliver what we need.
Thanks again
Daniel
Can you explain what you feel would be hard to maintain? I think no matter what you do there would be the extra burden of determining what portfolio or organization a particular statement belongs to. You might be able to leverage the reasoner to help you out here though. I've always thought that Stardog+reasoner+ABAC security system would be a great combination.
What part wouldn't be enough and what would be enough.
I believe that that's essentially what Stardog is doing with the named graph based security although I've always wondered where it is applied and if it is included in the query plan or applied after the quey.
Hi Zachary,
I will try to provide you more details.
(1) Too much of them and hard to maintain:
If we need to create one graph for every triple or every resource, we would end up with billions of graphs. That is already hard to maintain.
Also, there is no way we include that much FROM clauses in our select statements. And those statements would be hard to maintain too.
(2) Would probably not be enough:
If we take the example of the organization and put each of them, with their triples, in a different graph. That is still not addressing the need to restrict the view of the organizations associated with portfolios assigned to each users. We need to go one step further and restrict based on portfolios.
Also, as each organization can be associated to many portofolios, we cannot create graphs for portfolios and include the required organzations there.
Finally, the portfolio example is only one example. There could be other ways to restrict organizations. And the graph segragation used for portfolios, would not address the other requirement.
(3) Virtualization:
I am not sure exactly what you are referring to. If you can point me in the right direction, I will have a look.
(4) Overall, you might be right and maybe there is something I am not getting about what Stardog can do for fine grain security. But if this is true, please just provide more documentation.
Thanks
Daniel
The graph solution can work if you are limiting to a resource. Not sure if this is the use case of Daniel but here one that I saw often
you have a record, that has a attribute called 'dept'. Now assume that you have different privilege if you are part of the HR, Dev and Marketing department. In most cases, this would require the application to handle the permission, but in that scenario you the custodian of the data as lost control of the data.
There are various other use case where fine grain is required, just wanted to show that in this case graph would not work.
-Serge
You'd only need to supply a graph name for each security boundary, a single statement per named graph is the extreme case. One problem that I've come across with this approach is that you're mixing the use of a named graph to group statements and to provide security boundaries which can be confusing, difficult to maintain. You end up with what would have been one logical named graph split in two because of some security boundary. It would be interesting if you could use sameAs reasoning on named graphs and union them. 
You'd need to write a custom plugin that would provide that functionality. Really simplistically you override a method that provides the graphs the user can access. I don't think there's any reason that the list of graphs can't be obtained from a sarql query. "Select all named graphs where the users is a member and the graph are members of this portfolio". It would have a performance impact and it might be significant but you might be able to build some sort of secondary indexing.
I think you can do what you're looking for but it's not going to be simple to implement and would involve some engineering.
You would basically be building an attribute based access control system but it would be a very coold abac system.
Hi Zachary,
I know what I am describing is very complex and I was not expecting to find a simple and complete solution. But I needed to ask before trying to design something from our side.
Thanks again for your help!
Daniel
No worries. I hope that I can be of some help. You'll want to get familiar with Stardog's plugin support by taking a look at some of the examples in the github exaples repo. GitHub - stardog-union/stardog-examples: Examples for working with and extending Stardog
Try looking around in the branches too. I don't think everything has made it's way into master. I'll get you some more specific pointers in a bit.
You'll want to be looking at implementing a NamedGraphSecurityManager. You'll probably want to be caching as much as possible but you'll need some sort of listener to clear or update your caceh when things change.
I think there is a way to apply arbitrary transformations on your queries before they're executed if you wanted to go that route with the "virtual private database" that you mentioned.
Hopefully someone can offer some more pointers. I've always thought it would be cool to use stardog for access control. By that I mean using Stardog instead of where you might use LDAP now. You could do some really interesting stuff with the reasoner. "only allow anyone that is a member of this account or can be inferred to be a member of this account because they workOn this account and is a manager and works within 10mi of the new york office during business hours." Pure awesomeness.
@zachary.whitley in one of my previous roles I did a POC around a Role-Based entitlement model.. Essentially you had Team, Service and Application which they themselves had sub-team, sub-service and sub-application which themselves could have sub ... . Sub element inherent-ed the privilege. In fact, even the role themselves use inheritance via the subclass property. Using the reasoner and the power of RDF recursive prowless it was easy to answer whether you had permission or not to a service or application
Therefore I agree with you assessment, and definitely would be cool.
I'm guessing that's basically what Stardog is already doing internally (although probably not using the reasoner). I get that it might not be a good idea to let users go twiddling around with something like that lest they mess up their installation. It might be nice though if you could have an internal implementation and basically clone it to user space where you could mess around with it. That way you could always fall back on the default implementation. You can already mess things up just as easily with LDAP auth.
I'd imagine something like a system.auth db that is locked down to admins, a SparqlAuthentication service and have it protected with ICV so you don't bork things up too bad. Then you could add a user with a sparql update query!
agreed about user having two much access. It should be in an internal graph and a user interface to add rules, unless they sign in blood that they are willing to take the risk
That's my first reaction too but when you think about it how much more dangerous would it be then an LDAP update? It could be arguably less dangerous. The LDAP DB is just going to dutifully do whatever it's told no matter how nonsensical it is. A Stardog authentication system would at least say, "I'm not doing it because, it's non-sensical , it violates the rules you setup, and here's why it doesn't make any sense and how you can fix it.
Trying some experiments with this is on my long list of things to try out.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.