Kerberos
This page discusses Stardog’s support for Kerberos as a means for authenticating users.
Page Contents
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 the 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 connect 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 usernames 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.
Note that enabling Kerberos will disable username / password based authentication by default. This can be overridden via setting security.disable.password=false in stardog.properties.
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.
Set up Kerberos Authentication for Stardog Applications
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, leave the username and password fields blank in the connection dialog 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 set up, 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 in 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.credentials 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. This is usually the case 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:
- From the browser, visit
about:config. - For
network.negotiate-auth.delegation-urisandnetwork.negotiate-auth.trusted-uris, set the domain against which you want to authenticate, for example,example.com.