Detailed access control for SPARQL queries

We are thinking of building a major MDM-type solution for a customer based on semantic technologies. It's not clear whether we can expose a SPARQL endpoint to the collected master data because we can't see how to implement the necessary access controls.

Basically, the solution needs to verify that the user sending the query has access to the given data types (say, person data, income data, and address data). It also needs to verify that the user has access to returned resources with certain attached metadata regarding security sensitivity. (For example, some people for various reasons have secret addresses. Very few users have access to these addresses.)

We need to be able to enforce these rules without placing restrictions on how the SPARQL queries can be written. To put it another way, we need to be able to enforce this without trusting the people who compose the SPARQL queries to get the security checks right.

With SQL we could do this with views, granting access rights to the various views for users, and implementing the sensitivity checks in the view logic. It's not clear to me that this is possible with SPARQL.

Anyone have any ideas how this could be done? Only the major SPARQL engines are really relevant here, like Oracle, Virtuoso and AllegroGraph.

I'd consider putting sensitive information in closed graphs and taking measures to ensure that the user must log in to access the data.

Using service definitions in sparql is relatively simple; alternatively, you could use a "Sail"-type set-up.

I'm guessing that both Stardog (using Apache Shiro security on DB level currently, but the development plan is for named graph and ultimately triple-level ACL) and Talis Platform (unsure what they use) would be better choices than the triplestores you mention in this respect.

You might also be interested in: Gabillon, A.; Letouzey, L.; , "A View Based Access Control Model for SPARQL," Network and System Security (NSS), 2010 4th International Conference on , vol., no., pp.105-112, 1-3 Sept. 2010 doi: 10.1109/NSS.2010.35 URL: