JAAS is a nightmare from the Enterprise Java Bean era, one which surfaces from the depths to pull the unwary under. You can see its heritage whenever you search for documentation; it's generally related to managing the context of callers to EJB operations.
JAAS provides for a standard configuration file format for specifying a login context; how code trying to run in a specific context/role should login and authenticate.
As a single jaas.conf
file can have multiple contexts, the same file can be used to configure the server and clients of a service, each with different binding information. Different contexts can have different login/auth mechanisms, including Kerberos and LDAP, so that you can even specify different auth mechanisms for different roles.
In Hadoop, the JAAS context is invariably Kerberos when it comes to talking to HDFS, YARN, etc. However, if Zookeeper enters the mix, it may be interacted with differently —and so need a different JAAS context.
Fun facts about JAAS
- Nobody ever mentions it, but the file takes backslashed-escapes like a Java string.
- It needs escaped backlash directory separators on Windows, such as:
C:\\security\\krb5.conf
. Get that wrong and your code will fail with what will inevitably be an unintuitive message. - Each context must declare the authentication module to use. The kerberos authentication model on IBM JVMs is different from that on Oracle and OpenJDK JVMs. You need to know the target JVM for the context —or create separate contexts for the different JVMs.
- The rules about when to use
=
within an entry, and when to complete an entry with a;
appear to be: start with the login module, one key=value line per entry, quote strings, finish with a;
within the same file.
Hadoop's UGI class will dynamically create a JAAS context for Hadoop logins, dynamically determining the name of the kerberos module to use. For interacting purely with HDFS and YARN, you may be able to avoid needing to know about or understand JAAS.
Example of a JAAS file valid for an Oracle JVM:
Client {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=false
useTicketCache=true
doNotPrompt=true;
};
-Djava.security.auth.login.config=/path/to/server/jaas/file.conf
In Hadoop applications, this has to be set in whichever environment variable is picked up by the command which your are invoking.
Or, as known on the Oracle JGSS docs under the section "Exceptions to the Model".
JAAS includes a rather obscure system property which can have a significant impact on how the LoginModule
(in our case, the Krb5LoginModule used to authenticate using Kerberos v5) uses the JAAS configuration which was provided.
-Djavax.security.auth.useSubjectCredsOnly=true
When this system property is set to true
(the default), the LoginModule
will never try to obtain credentials when they are not present in the context of the current call (e.g. the current doAs
scope). When this property is set to false
, the LoginModule
has the ability to try to obtain credentials by any other means
. This means that the implementation of the LoginModule
has the "latitude" to do whatever it likes.
For the Krb5LoginModule
on Oracle Java, the implementation will attempt to obtain credentials via a prompt on standard input/output.
When the provided JAAS configuration otherwise instructs the Krb5LoginModule
to never prompt or use a ticket cache, this can be a
very jarring and unexpected action.