Kerberos authentication in Spotfire

Intention

This article will focus on Constrained Delegation since there are several security issues with using unconstrained delegation. There are however still some data sources that have poos support for constrained delegation (e.g. cross domains) so there is not only one perfect way to set up Spotfire which has the potential for very many interconnected dependencies.

Very short overview

All end-user authentications happen on the TIBCO Spotfire Server(s) (TSS) and it is here that the Kerberos delegation chain starts.

Once the user session is established on a TSS and the end user opens a Web Player (WP) session (Opens a file or Opens the Analysis App), the TSS user session makes a Kerberos authentication (the negotiate ping-pong) towards the chosen WP. 

During the authentication on the WP there is an authentication back to the TSS, which puts immediate demand on the delegation chain from the WP onwards.

When there is a stable Kerberos session on the WP, the further delegation when loading data is depending on allowing the delegation to all the possible data sources (SPNs are needed for all possible used addresses), this is also true from the TSS in the case of using Information Services (which is executed on the TSS).

The delegation to Data Sources from the TSS when using Information Services is also used when using Analyst, so that part is caught yearly (compared to the WP where files can have a long development phase before they are tried to get "published".

What happens when the TSS is starting up

1. The TSS read the Kerberos "principal" from the configuration

2. The krb5.conf (location in the configuration) is read and the KDC for the REALM

3. KDC is contacted to get a Ticket Granting Ticket (TGT) for the principal

4. The returning TGT is checked against the keytab (location in the configuration)

This can fail in every step of the way, and the resulting Error in the server.log or SEVERE in the catalina.log can give hints in their "caused by" which can tell a lot after some internet searching.

E.g., in step 3 the principal string is used which means that that string needs to the same as the User Principal Name (UPN) of the account used to create the keytab. This is normally not an issue if the keytab is created with the standard ktpass command, but if it is created in other ways, the UPN might need to be altered manually.

There are many more things to think about whern it comes to the keytab, but there is a very complete writeup around that

All you need to know about Keytab files

One thing to note is the use of the security feature of Key Version NO (KVNO) which some instructions turn off (set it to zero in the ktpass command)

All delegation from the TSS is depending on the rights of the keytab account, the account running the Spotfire Service can be anything in this regard.

The steps for a normal Browser authentication to the TSS (nothing special compared to a text-book Kerberos negotiate)

1. Browser connects to the TSS to the login.html

2. TSS responds with a 401 and a header with WWW-authenticate: Negotiate

3. The browser (if set to use Windows Authentication to the TSS address) uses the address used to the TSS to ask for a ticket (from AD)

4. The KDC in AD handling the request matches the string (address used in browser) with the SPNs registered (e.g. HTTP/TSSFQDN) to find the account (the keytab account since that is what the TSS is using to handing incoming tickets). It is the password of this account that is used to wrap the ticket.

5. If the account is found and all rights and options are ok, the KDC returns a ticket to be used for the browser authentication header for the next request to the TSS

6. The browser sends a new request to the login.html, now with an authentication header containing the ticket from the KDC

7. The TSS recognizes the authentication header and tries to handle it with the keytab (the password stored in it)

8. If all is well the TSS now has authenticated the session and the username can be seen on the log lines.

Every step in this process can brake, and there is usually information hidden in the stack traces of errors that can be used as the basis for internet searches.

SPNs

All tickets that are requested from TSS or WP are requested without a port, so the SPNs registered for the service account running the WP (this is .Net so no keytab is needed) which is the Node Manager service account should be registered without the port. If you register extra SPNs with the port (e.g. 9501) does not matter, since the string used to get the ticket is the one without the port (it is simple case insensitive string matching in the AD, no logic about hostname vs FQDN and nothing around ports).

Placeholder for more information about SPNs, especially a link to the old nice article by Robert ?The SPN Doctor? Greene was to the bottom paragraph on part 3 sums up the encryption of tickets in a nice way (encrypted using the service account password hash, which explains a lot of logic).