Kerberos: Three-Headed Stardog

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 Authentication

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.

Setting it up

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.

Create a keytab file

The 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.

Create a 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.

Create a 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.

Create a Stardog Admin User

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.

Configure Stardog

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 |
+-----------+

User Management

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.

Summary

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.

• Kerberos
• Security