Securing Sesame 2

This page offers some help on how to secure your Sesame 2 server. Unlike the 1.x version, the 2.x server does not include any "native" support for authentication or authorization. There are some hints in the documentation that the developers possibly want to add that, but until then it'll be a bit of a pain.

Overall situation

As the the Sesame server doesn't handle authentication by itself, you only have limited options to secure it.

• Leave everything open to the world. Obviously not a serious option.
• Use the application server's (e.g. Tomcat's or glassfish's) facilities to provide authentication. This will work, but all administration tools that come with Sesame (that is, the "Workbench" page and the command line tool) will break because they don't handle basic authentication. (However, Talia can be configured to work with the secured repository). In this scenario, you can also use SSL encryption to add further security.
• Somehow isolate the server from the outside world and limit who can access. This will potentially leave the Workbench active, but provide only very limited security and requires network administration skills to set up.

Sesame Console Patch

We've gotten around to patch the "console" for Sesame 2.3.0 to handle authentication. This has also been submitted to Sesame Bug Report (note: The patch has accepted and should show up in version 2.3.1).

As long as the official download doesn't have this feature, you may download the sesame-console-2.3.0.jar file from this page (see bottom). If you have Sesame 2.3.0 installed you can copy it over the sesame-consol-2.3.0.jar in your "lib" directory, and the console application will allow you to provide a user and password for the connection.

Securing Sesame through Glassfish

We use the glassfish server here, but the method will also work with other Servers, like Tomcat. The difference is that users, roles and security realms are configured differently for other servers.

Creating a user for Sesame

First thing we need is to create a user for our sesame database, and enable the simplified role mapping. The latter will automatically create the security "role" for our user, so that we don't have to care about this. These things have to be configured before the application is deployed (if not, you will have to re-deploy the app).

To create the user and enable the simplified mapping:

• Log in to the Glassfish administration console
• Open "Configurations" in the sidebar panel
• Open "server-config" (if you have a "standard" installation)
• Click on "Security"
• Note the "Default Realm" (normally "file")
• Check the "Default Principal To Role Mapping" checkbox

• Click "Save"
• Open "Security" -> "Realms" in the sidebar
• Click on the default realm (the one you noted in the Security Panel before)
• Click "Manage Users", then "New"

• Enter an id for the user (e.g. "sesame-admin")
• Enter a group in the "Group List" (e.g. "sesame-admin"). Glassfish will create a security role of the same name.
• Enter a password and click "OK"

The user should now show up in the list of users and Glassfish is correctly configured.

Configure the Sesame Application

To configure the Sesame server application to use Glassfish's security, you need to modify the deployment descriptort (web.xml). If you do not want to build the whole war yourself, you can unpack the openrdf-sesame.war file, modify the existing web.xml and re-pack it. Since the *.war file is just a *.zip archive, this isn't all too difficult:

# cd openrdf-sesame-2.x.x/war
# mkdir unpacked_war
# cd unpacked_war
# unzip ../openrdf-sesame.war
# cd ..

After this you will have the whole structure of the application inside the unpacked_war directory. Use your favorite text or xml editor to open the web.xml file in the WEB-INF folder.

The file should already contain a section for security constraints. Comment it out and modify it like below.

<security-constraint>
        <!-- These define which paths of the application are protected in which way -->
        <web-resource-collection>
                <web-resource-name>config</web-resource-name>
                <url-pattern>/repositories/SYSTEM</url-pattern>
                <url-pattern>/repositories/SYSTEM/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
                <!-- Make this match the role that you define below -->
                <role-name>sesame-admin</role-name>
        </auth-constraint>
</security-constraint>

<login-config>
        <auth-method>BASIC</auth-method>
        <!-- Change the realm name to "default" in order to use the default 
                glassfish realm in which we created the user -->
        <realm-name>default</realm-name>
</login-config>

<security-role>
        <description>
                The role that is required to access the Sesame server configuration
        </description>
        <!-- The role name must match the "group" that you entered when creating the user -->
        <role-name>sesame-admin</role-name>
</security-role>

Note that this default configuration only protects the "SYSTEM" repositories and nothing else. If you want protect other things, you have to modify the configuration accordingly. Once you are happy with everything, you can re-pack the war:

# cd openrdf-sesame-2.x.x/war/unpacked_war
# zip -r ../new-openrdf-sesame.war *

This will create a new war file, "new-openrdf-sesame.war" which you can now deploy to the glassfish server in the usual way. Usually you want to make sure to deploy the application as 'openrdf-sesame' (not 'new_openrdf...'); if you have already install the application you can select the "redeploy" option to overwrite the existing version.

To test if everything worked just go to http://talia-rails-vm.local:8080/openrdf-sesame/repositories/SYSTEM (or wherever you installed the application). You should be greeted by a login prompt and should be able to login using the id and password of the user you created.

Using Talia with a secured repository

Once you have secured the server, you will not be able to use the web-based "Workbench" any more (at least not as long as the Sesame team doesn't fix that). Instead, you'll have to use the Sesame console utility to create your repositories. To use the sesame console with a secured repository, you'll need version 2.3.0 or later. See the TaliaDeployment#UsingtheSesameConsole section in the deployement guide.