Last modified 22 months ago Last modified on 10/07/12 00:01:42

Graph Access Control

This feature, new in 1.1.5, implements access control at the graph level. Clients are identified via a CGI parameter in the HTTP query call. The name of this parameter is 'apikey'. If a user is not granted access to a set of graphs, those graphs will not be used by the query engine to answer SPARQL queries. It is like if the query was running in a KB where these graphs did not exist.

NOTE: 4store does not authenticate tuples of the form (API key value, password); if this is required it should be implemented at a proxy level.

Enable Access Control

The option '-A' in 4s-httpd enables access control in the 4store SPARQL server.

4s-httpd -p 8000 -A demo

Grant Access

By default all graphs, except <system:config>, are accesible to all API key values. The mechanism to grant/deny access to graphs is reversed. Once we assign one API key to a graph that graph becomes private and the only calls that can access it are the ones with that API key. Multiple API keys can be assigned to the same graph.

The following SPARQL query would link <graph:x> and <graph:y> with two and one api key respectively.

INSERT DATA { GRAPH <system:config> { 
<graph:x> <> "user1","user2" . 
<graph:y> <> "user1" . 
} }

Similarly, SPARQL deletes work on <system:config> to remove access to graphs.

Change Admin User

The permissions to access private graphs are establish in the system configuration graph <system:config>. By default the only apikey that can access <system:config>, when access control is enabled, is '4sadminuser'. This can be changed with the following SPARQL insert:

INSERT DATA { GRAPH <system:config> { 
[] <> "manuelso". } }

With access control enabled only admin users can query and modify <system:config>. To reset the admin user when the current admin user has been lost, just start 4s-httpd without the -A option and run the queries over the <system:config> graph.


Easy to follow examples can be found in the tests: