Kerberos: Three-Headed Stardog
Get the latest in your inbox
Get the latest in your inbox
We added Kerberos support to Stardog. Now the Knowledge Graph works with enterprise-wide single sign-on with encryption.
Let’s dive into the details.
Kerberos is a strong authentication system with a central key management server. It’s the authentication protocol implemented by Microsoft’s Active Directory and is common for enterprises that use Windows. There is also a very popular open source MIT implementation that many companies interested in strong authentication use.
Let’s review the big picture about how Kerberos works; you can learn more in this discussion. Every Kerberos deployment, called a realm, has a central key management server called the Key Distribution Center (KDC). The KDC stores details about users including their usernames and passwords. The password acts as a shared secret between the user and the KDC. A person uses that password to create a time boxed ticket which will then automatically be used to prove her or his identification to any other server in the realm. In this way a “single sign-on” mechanism is established.
Servers in a Kerberos realm must also have a shared secret. Typically this is
kept in a file called keytab
(key table). The
keytab
file stores an encrypted hash of a password associated with each
server. In that way a server can participate in third-party mediated
authentication without human intervention.
When a client wants to authenticate with a server it first requests a ticket by communicating with the KDC and proving that it has the right password. It also tells the KDC which server it wants to communicate with. The KDC then creates a magic blob of data which contains the ID of the client and is encrypted by the server’s key. The client takes that magic blob and gives it to the server.
Because the server’s key was used in encryption, the server can now decrypt it without any additional communication with the KDC. Thus the workload on the server is actually lighter than that on the client with Kerberos authentication. Once the magic blob is decrypted, the server can see (and trust) the identity of the of the client. It is then up to that server to decide if the client will be authorized.
This post discusses Kerberos in Stardog proper; a future post will discuss Kerberos support in Stardog Studio, our IDE for the Knowledge Graph, which is based on the Electron platform.
We will skip the hairy details of running a MIT KDC or a Microsoft Active Directory deployment, but we will walk through the process of getting a Stardog server deployed into both of those environments.
The steps to achieve this are straightforward. The first is to run a Stardog
server with a proper license on your network as discussed
here. Next, create a
keytab
file for that Stardog instance. Finally, configure Stardog to use the
krb5 realm. Three easy steps for the three-headed
dog.
keytab
fileThe steps to create a keytab
file differ depending on the implementation being
used. There are many ways to create this file, but we will discuss the
techniques that worked for us. It may be different for your environment.
keytab
file (MIT env)If your entire Kerberos realm is deployed using an MIT setup, then you can
create the keytab
file from the same Linux server that will be running the
Stardog server, but you will need administrator access to the KDC.
The first step is to create a principal for the server. The principal
can be thought of as the identity of the server in the realm. For
a Stardog service the principal should look like:
HTTP/<canonical dn of the Stardog Host>@<REALM NAME>
. For example:
HTTP/demo1.stardog.com@REALM1.STARDOG.COM
To create the principal run the following command:
kadmin -p <admin principal> -q "addprinc -randkey HTTP/<DN of the Stardog host>"
Once the principal has been created you can extract the keytab
file with the
following command:
kadmin -p <admin principal> -q "ktadd -k <output keytab file> HTTP/<DN of the Stardog host>"
Remember, and securely handle, the newly created keytab
file.
keytab
file (Active Directory).The easiest way to create a keytab
file in an Active Directory setup is
to log into a Windows machine with an account that has admin rights to
create users.
Once this is done, go to Start->Windows Administration Tools->Active Directory Users and Computers
and add a user under the Kerberos realm. This user will be the principal
associated with the Stardog server. An example is shown below:
Now that a principal exists under which the server will be run, we
can extract a keytab
file. To do this open a DOS shell and run:
ktpass -princ HTTP/<DN of the Stardog host>@<REALM NAME> -mapuser <user name>@<REALM> -pass <some password> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out <output keytab file>
This command maps the newly created user name (<user name>
) to the publicly
visible principal (<HTTP/<DN of the Stardog host>@<REALM NAME>
)
Remember, and securely handle, the newly created keytab
file.
To run Stardog there must exist an admin user for the Stardog server. You can
use the admin user for the existing realm or create a new user. If you are
creating a new user for this, follow the principal creating instructions above
to create the keytab
file but use a different user name.
Now that you have a keytab
file, copy it to the Linux machine where Stardog is
installed and edit the file ${STARDOG_HOME}/stardog.properties
adding the
following lines:
krb5.principal = HTTP/<DN of the Stardog host>@<REALM NAME>
krb5.debug = true
krb5.keytab = <path to the keytab file>
krb5.admin.principal = <admin principal>
This will denote the named Kerberos principal as a Stardog administrator. Once
that’s done, start Stardog. To verify that it is working, use the
stardog-admin
command to list the users. An example session follows:
$ kinit admin/stardog
$ stardog-admin --krb5 --krb5-disable-rdns user list
+-----------+
| Username |
+-----------+
| admin |
| anonymous |
+-----------+
Stardog users in a Kerberos environment are created and managed in the same way that regular Stardog users are as described here. The only caveat is that the user names must match the Kerberos principal names.
Stardog is committed to producing high quality, secure software. Kerberos environments are often part of such an environment in large enterprises. Stardog is now compatible with these environments and the increased security they bring.
In a future blog we will discuss Kerberos support in Stardog Studio.
How to Overcome a Major Enterprise Liability and Unleash Massive Potential
Download for free