This page discusses Stardog’s support for Kerberos as a means for authenticating users.
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
|The path to the keytab file for the Stardog server.
|The Kerberos principal that will be the default administrator of the service.
|A boolean value to enable debug logging in the Java Kerberos libraries.
|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
|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.
|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
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
For more details about configuring these values, see our example
See our blog, Kerberos: Three-Headed Stardog, for a more detailed walkthrough on using Stardog with Kerberos.
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
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.
Once Kerberos authentication is set up, the following options can be set in
stardog.properties for Explorer and Studio.
|A comma separated list of domains to allow
CORS requests. To enable Kerberos authentication in Stardog Cloud, the list must contain:
|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
cors.allow.credentials is set to true, as it may expose credentials to malicious hosts.
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:
$ defaults write com.google.Chrome AuthServerWhitelist "*.example.com"
$ defaults write com.google.Chrome AuthNegotiateDelegateWhitelist "*.example.com"
- From the browser, visit
network.negotiate-auth.trusted-uris, set the domain against which you want to authenticate, for example,