Controlling access to a GraphDB repository and assigning user accounts to roles with specified access permissions is achieved with a combination of HTTP authentication and the Sesame server's deployment descriptor. Sesame and GraphDB have no separate access control mechanisms, therefore to control access, GraphDB must be deployed using the Sesame HTTP server.
Using this technique will allow an administrator to:
The Sesame HTTP server is a servlet-based Web application deployed to any standard servlet container - for the remainder of this section it is assumed that Tomcat is being used.
The Sesame server exposes its functionality using a RESTful API that is an extension of the SPARQL protocol for RDF. This protocol defines exactly what operations can be achieved using specific URL patterns and HTTP methods (GET, POST, PUT, DELETE). Each combination of URL pattern and HTTP method can be associated with a set of user roles, thus giving very fine-grained control.
The following diagram shows the URL patterns associated with groups of operations on a Sesame HTTP server.
This diagram is copied (with modifications) from chapter 4 of the online Sesame 2 system guide.
In general, read operations are effected using GET and with PUT, POST and DELETE for write operations. The exception to this is that POST is allowed for SPARQL queries. This is for practical reasons, because some HTTP servers have limits on the length of parameter values for GET requests.
The association between operations and security roles is specified using security constraints in the Sesame server's deployment descriptor - a file called web.xml that can be found in the .../webapps/openrdf-sesame/WEB-INF directory.
The deployment descriptor defines:
To enable authentication, add the following XML element to web.xml inside the <web-app> element:
Security constraints associate operations (URL pattern plus HTTP method) with security roles. Both security constraints and security roles are nested in the <web-app> element.
A security constraint minimally consists of a collection of web resources (defined in terms of URL patterns and HTTP methods) and an authorisation constraint (the role name that has access to the resource collection). Some example security constraints are shown below:
The ability to create and delete repositories requires access to the SYSTEM repository. An administrator security constraint for this would look like the following:
Also nested inside the <web-app> element are definitions of security roles. The format is best shown by example:
Tomcat has a number of ways to manage user accounts. The different techniques are called 'realms' and the default one is called 'UserDatabaseRealm'. This is the simplest one to manage, but also the least secure, because usernames and passwords are stored in plain text.
For the default security realm, usernames and passwords are stored in the file tomcat-users.xml in the Tomcat configuration directory, usually /etc/tomcat6/tomcat-users.xml on Linux systems. To add user accounts, <user> elemеnts must be added inside the <tomcat-users> element, for example:
To use a remote repository where authentication has been enabled, it is necessary to provide the username and password to the Sesame API. Remote repositories will usually be accessed via the org.openrdf.repository.manager.RemoteRepositoryManager class. Before attempting access, it is necessary to tell the repository manager the security credentials using the following method:
Alternatively, that can be passed in the factory method:
Skip to end of metadata Go to start of metadata