Using Java programmatically log in multiple kerberos realms with different keytabs

Question

For some reason my client needs to log into two kerberos realms..let's say REALM1 and REALM2. My principal has been signed in both realms, with two different keytabs created(principal/host@REALM1 with keytab1 and principal/host@REALM2 with keytab2). In another word, I can kinit and klist my principal against two different realms.

Now I need to run an application in which first of all a few tasks needed to be done in the realm1, and then other tasks needed to be done in realm2, so I have to log in realm1 first,finish some work and then log in realm2. I tried to do it by resetting System property "java.security.krb5.conf" in the middle of my program but failed to switch from realm1 to realm2(failed at log-in, it seemded the default realm remained the same.)

I searched over and saw a relevant post's answer(Kerberos Auth with JAAS and multiple realms) and I understand a keytab is bound to a realm--what I do not understand is -- I have generated two keytabs for two realms --why can't log in two realms consequently? is the only way to do it through cross-realm authentication..?

Answer 1

Don't do that. Establish a cross-realm trust and you can use the original keytab of your client to perform all tasks in the foreign realm. We have at least 30 realms here and my Unix machine is joined in one realm of course. This works pretty neat.

Answer 2

In your case you might be able to get away with simply forcing a reload on the configuration before each use using the refreshKrb5Config=true option in KRB5LoginModule in JAAS login.conf (See Reload Kerberos config in JAVA without restarting JVM).

This won't work well in a multi-threaded application though as you'll have to serialize access to this shared resource. The fact that the Java Kerberos implementation uses System properties (and a single configuration file) is an unnecessary restriction, perhaps even a bug.

The accepted answer of use cross domain trusts might be good sometimes, but not always. For example if your network administrators don't want ALL services to trust the other domain, just this one particular service then you are out of luck. Say you have a multi-threaded application that is written in Java and provides a service that wants to accept tickets from multiple realms you would have to run one instance of this application per realm (krb5.conf hostname is static, just keytab and kdc changes). This becomes a big headache if this one specific application is a web service running on port 443 using SPNEGO. Now you'll need two application server instances on different ports? Ouch.