Link Search Menu Expand Document
Start for Free

Kerberos

This page discusses Stardog’s support for Kerberos as a means for authenticating users.

Page Contents
  1. Overview
  2. Example
  3. Guide
  4. Setup Kerberos Authentication for Stardog Applications
    1. Configuration of stardog.properties for Stardog applications
    2. Workstation configuration

Overview

Stardog can be configured to run in both MIT and Active Directory Kerberos environments. In order to do so a keytab file must be properly created.

Once the keytab file is acquired the following server properties can be set in stardog.properties.

Property Description
krb5.keytab The path to the keytab file for the Stardog server.
krb5.admin.principal The Kerberos principal that will be the default administrator of is service.
krb5.debug A boolean value to enable debug logging in the Java Kerberos libraries.
krb5.user.translation.regex A string value used to translate a krb5 principal name to a Stardog username. The string is an expression in two parts divided by a :. On the left side is a matching regex of the krb5 principal name to replace and on the right side is the string to replace it with. By default this is /:-. This means “replace any / character in the krb5 principal with a - character and use that as the Stardog username”. Thus the krb5 principal name stardog/admin will be translated to stardog-admin. The details of the substitution rules are that of Java String.replaceAll().
pack.krb5.principal The Kerberos principal that is authorized to connect as a cluster peer. Stardog cluster nodes connected directly to each other. This directive tells Stardog to use Kerberos authentication for this communication and to only allow connections from entities with the given Kerberos principal
pack.krb5.keytab The path to the keytab file that Stardog cluster peers will use to prove to other nodes they are authorized peers. The principal in this keytab must match the value of pack.krb5.principal.

Once Stardog is properly configured for Kerberos, Stardog user names should be created that match their associated Kerberos principal names. Authentication will be done based on the Kerberos environment and authorization is done based on the principal names matching Stardog users.

Example

For more details about configuring these values, see our example stardog.properties file.

Guide

See our blog, Kerberos: Three-Headed Stardog, for a more detailed walkthrough on using Stardog with Kerberos.

Setup Kerberos Authentication for Stardog Applications

As of Stardog version 7.4.5 you can configure your Stardog instance to authenticate via Kerberos when using Stardog Cloud.

Once the additional stardog.properties options are added as specified below, your browser should be able to negotiate with Kerberos credentials. To authenticate to a Stardog application via Kerberos, in the connection dialog leave the username and password fields blank and enter the endpoint url for your Stardog instance. When there is no username or password Studio will attempt to connect using browser credentials.

Configuration of stardog.properties for Stardog applications

Once Kerberos authentication is setup the following options can be set in stardog.properties for Explorer and Studio.

Application Property Description
Stardog Cloud cors.allowed.origins A comma separated list of domains to allow CORS requests. To enable Kerberos authentication from the browser-based Stardog Cloud the list must contain: https://cloud.stardog.com
All cors.allow.credentials A boolean value that instructs Stardog to allow credentials in CORS requests. This must be set to true to allow any Stardog application to request forwarding credentials.

Note that browsers and Stardog will not allow cors.allowed.origins to be set to * when cors.allow.credientials is set to true as it may expose credentials to malicious hosts.

Workstation configuration

In most cases the workstation should be properly configured for Kerberos Authentication, however it may be necessary to instruct your browser to whitelist the domain, usually if the host machine is not on the same domain as the Kerberos server. Set the following for your browser:

For Chrome:

$ defaults write com.google.Chrome AuthServerWhitelist "*.example.com"
$ defaults write com.google.Chrome AuthNegotiateDelegateWhitelist "*.example.com"

For Firefox:

  1. From the browser visit about:config
  2. For network.negotiate-auth.delegation-uris and network.negotiate-auth.trusted-uris set the domain against which you want to authenticate, for example, example.com.