Fuseki can provide access control at the level on the server, on datasets, on endpoints and also on specific graphs within a dataset. It also provides native https to protect data in-flight.
Fuseki Main provides some common patterns of authentication.
Graph level Data Access Control provides control over the visibility of graphs within a dataset, including the union graph of a dataset and the default graph. Currently, Graph level access control only applies to read-only datasets.
Fuseki Full (Fuseki with the UI) can be used when run in a web application server such as Tomcat to provide authentication of the user. See "Fuseki Security" for configuring security over the whole of the Fuseki UI.
This section applies to Fuseki Main. HTTPS support is configured from the fuseki server command line.
Server Argument | ||
---|---|---|
--https=SETUP | Name of file for certificate details. | |
--httpsPort=PORT | The port for https | Default: 3043 |
The --https
argument names a file in JSON which includes the name of
the certificate file and password for the certificate.
The file is a simple JSON file:
{ "cert": KEYSTORE , "passwd": SECRET }
This file must be protected by file access settings so that it can only be read by the userid running the server. One way is to put the keystore certificate and the certificate details file in the same directory, then make the directory secure.
A self-signed certificate provides an encrypted link to the server and stops some attacks. What it does not do is guarantee the identity of the host name of the Fuseki server to the client system. A signed certificate provides that through the chain of trust. A self-signed certificate does protect data in HTTP responses.
A self-signed certificate can be generated with:
keytool -keystore keystore -alias jetty -genkey -keyalg RSA
For information on creating a certificate, see the Jetty documentation for generating certificates.
This section applies to Fuseki Main.
Authentication, is establishing the identity of the principal (user or program) accessing the system. Fuseki Main provides users/password setup and HTTP authentication, digest or basic).
These should be used with HTTPS.
Server Argument | ||
---|---|---|
--passwd=FILE | Password file | |
--auth= | "basic" or "digest" | Default is "digest" |
These can also be given in the server configuration file:
<#server> rdf:type fuseki:Server ; fuseki:passwd "password_file" ; fuseki:auth "digest" ; ...
The format of the password file is:
username: password
and passwords can be stored in hash or obfuscated form.
Documentation of the Eclipse Jetty Password file format.
If different authentication is required, the full facilities of Eclipse Jetty configuration are available - see the section below.
curl
¶See the curl documentation for full details. This section is a brief summary of some relevant options:
curl argument | Value | -- |
---|---|---|
-n , --netrc |
Take passwords from .netrc (_netrc on windows) |
|
--user= |
user:password |
Set the user and password (visible to all on the local machine) |
--anyauth |
Use server nominated authentication scheme | |
--basic |
Use HTTP basic auth | |
--digest |
Use HTTP digest auth | |
-k , --insecure |
Don't check HTTPS certifcate. This allows for self-signed or expired certificates, or ones with the wrong host name. |
wget
¶See the wget documentation for full details. This section is a breif summary of some relevant options:
wget argument | Value | -- |
---|---|---|
--http-user |
user name | Set the user. |
--http-password |
password | Set the password (visible to all on the local machine) |
wget uses users/password from .wgetrc or .netrc by default. |
||
--no-check-certificate |
Don't check HTTPS certifcate. This allows for self-signed or expired, certificates or ones with the wrong host name. |
ACLs can be applied to the server as a whole, to a dataset, to endpoints, and to graphs within a dataset. This section covers server, dataset and endpoint access control lists. Graph-level access control is covered below.
Access control lists (ACL) as part of the server configuration file.
fuseki --conf configFile.ttl
ACLs are provided by the ja:allowedUsers
property
ja:allowedUsers
¶The list of users allowed access can be an RDF list or repeated use of the property or a mixture. The different seting are combined into one ACL.
fuseki:allowedUsers "user1", "user2", "user3"; fuseki:allowedUsers "user3"; fuseki:allowedUsers ( "user1" "user2" "user3") ;
There is a special user name "*" which means "any authenticated user".
fuseki:allowedUsers "*" ;
<#server> rdf:type fuseki:Server ; fuseki:allowedUsers "user1", "user2", "user3"; ... fuseki:services ( ... ) ; ... .
A useful pattern is:
<#server> rdf:type fuseki:Server ; fuseki:allowedUsers "*"; ... fuseki:services ( ... ) ; ... .
which requires all access to to be authenticated and the allowed users are those in the password file.
When there is an access control list on the fuseki:Service
, it applies
to all requests to the endpoints of the dataset.
Any server-wide "allowedUsers" configuration also applies and both levels must allow the user access.
<#service_auth> rdf:type fuseki:Service ; rdfs:label "ACL controlled dataset" ; fuseki:name "db-acl" ; fuseki:allowedUsers "user1", "user3"; ## Choice of operations. fuseki:serviceQuery "query" ; fuseki:serviceQuery "sparql" ; fuseki:serviceReadGraphStore "get" ; fuseki:serviceUpdate "update" ; fuseki:serviceUpload "upload" ; fuseki:serviceReadWriteGraphStore "data" ; fuseki:dataset <#base_dataset>; .
An access control list can be applied to an individual endpoint. Again, any other "allowedUsers" configuration, service-wide, or server-wide) also applies.
fuseki:serviceQuery [ fuseki:name "query" ; fuseki:allowedUsers "user1", "user2"] ; fuseki:serviceUpdate [ fuseki:name "update" ; fuseki:allowedUsers "user1"] ;
Only user1 can use SPARQL update; both user1 and user2 can use SPARQL query.
Graph level access control is defined using a specific dataset implementation for the service.
<#access_dataset> rdf:type access:AccessControlledDataset ; access:registry ... ; access:dataset ... ; .
Graph ACLs are defined in a Graph Security Registry which lists the users and graph URIs.
<#service_tdb2> rdf:type fuseki:Service ; rdfs:label "Graph-level access controlled dataset" ; fuseki:name "db-graph-acl" ; ## Read-only operations. fuseki:serviceQuery "query" ; fuseki:serviceQuery "sparql" ; fuseki:serviceReadGraphStore "get" ; fuseki:dataset <#access_dataset> ; . <#access_dataset> rdf:type access:AccessControlledDataset ; access:registry <#securityRegistry> ; access:dataset <#tdb_dataset_shared> ; . <#securityRegistry>rdf:type access:SecurityRegistry ; . . . <#tdb_dataset_shared> rdf:type tdb:DatasetTDB ; . . .
All dataset storage types are supported. TDB1 and TBD2 have special implementations for handling graph access control.
The Graph Security Registry is defined as a number of access entries in
either a list format "(user graph1 graph2 ...)" or as RDF properties
access:user
and access:graphs
. The property access:graphs
has graph URI or a
list of URIs as its object.
<#securityRegistry> rdf:type access:SecurityRegistry ; access:entry ( "user1" <http://host/graphname1> <http://host/graphname2> ) ; access:entry ( "user1" <http://host/graphname3> ) ; access:entry ( "user1" <urn:x-arq:DefaultGraph> ) ; access:entry ( "user2" <http://host/graphname9> ) ; access:entry [ access:user "user3" ; access:graphs ( <http://host/graphname3> <http://host/graphname4> ) ] ; access:entry [ access:user "user3" ; access:graphs <http://host/graphname5> ] ; access:entry [ access:user "userZ" ; access:graphs <http://host/graphnameZ> ] ; .
For authentication configuration not covered by Fuseki configuration, the deployed server can be run using a Jetty configuration.
Server command line: --jetty=jetty.xml.