All articles

Simple Security for Fuseki

This entry describes an interim solution for providing a minimal level of access control to a Fuseki server.

Fuseki, a part of the Jena family of linked data tools, is an Open Source SPARQL server. It provides the REST-style SPARQL HTTP Update, and SPARQL Query and SPARQL Update using the SPARQL protocol over HTTP.

Though a security model is expected to be developed in future, Fuseki currently has no means of restricting access to the server.

This note describes how to implement simple access control by restricting access to Fuseki’s direct network connection and providing access through an Apache virtual host acting as a reverse proxy.  I have implemented this on an Ubuntu 11 machine.

Restricting Access to Fuseki

To restrict direct access to Fuseki’s own network port, I have added an argument to the fuseki-server command.

    fuseki-server --mem --update --host=127.0.0.1 /dataset

The –host=x.x.x.x argument can take an IP address or a domain name as a value.  It instructs Fuseki to accept incoming requests only on that network interface.  By specifying local host, it is possible to restrict Fuseki to only accept requests from the server on which it is running.

A patch with this update has been submitted to the Fuseki project and accepted into the development build.

If you don’t have, or don’t want to make a version of Fuseki that supports the –host option, see below for an alternative way to restrict access to Fuseki’s direct port.

Setting Up Apache

This not a detailed guide on how to configure Apache.  For that see the Apache documentation.

Whilst there are many ways to set this up, the approach I chose was to:

  • configure a virtual host to front Fuseki
  • use mod-proxy to send all requests to the virtual host to Fuseki (note that Fuseki will see all requests as coming from localhost)
  • configure basic access control on all requests to the virtual host

On Ubuntu, the Apache configuration files are in /etc/apache2.  I chose to use a port based virtual host so that I didn’t have to configure a new domain name in DNS.  To do this:

  • add a ‘Listen 4040’ directive to ports.conf (or whatever port number you want)
  • created a fuseki virtual server configuration file in sites-available by cloning a standard virtual server configuration file and adding the following to it:
# proxy configuration

    ProxyRequests Off
    ProxyVia Off
    ProxyPreserveHost On
    <Proxy *>
        AddDefaultCharset off
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyStatus On
    <Location /status>
        SetHandler server-status
        Order Deny,Allow
        Allow from all
    </Location>
    ProxyPass / https://localhost:3030/
    <Location />
         # access control
         AuthType Basic
         AuthName "password required"
         AuthUserFile /etc/apache2/passwd
         Require valid-user
     </Location>
  • add a symlink in the sites-enabled directory to the Fuseki virtual host configuration file.
  • configure some users and passwords using the htpasswd command.

That’s it.  Fuseki should now be accessable through the port configured for the virtual host.  Any authorised user can access it.  Requests to Fuseki’s own port from remote machines should be dropped.

Alternative to –host

If your version of Fuseki does not support the –host argument, then on Linux it is possible to limit access to the Fuseki port with IPTables.  The following command:

   sudo iptables -A INPUT -p tcp -i eth0 --dport 3030 -j DROP

will cause all tcp traffic to port 3030, Fuseki’s default port, arriving through the network device eth0, to be dropped.  On a machine with multiple network devices, then a command for each device would be needed.