...
The general CAS community has agreed that the third option is best. The cas-server-ldap module to go directly to LDAP (in Yale's case through the LDAP forwarding VIP on the F5) also provides us with the option to test the "last password change" timestamp (for password expiration) and to fetch additional AD properties about the user (which we do not use but is essential for CAS 3+ SAML support that other schools use). However, we did use JAAS at one time and it is a complicated enough feature of Java that the documentation below is still useful for other purposes.
A Java SE Web application or a Tomcat server runs under a native operating system userid. When it uses files and other local resources, it does so under the authority of that local system login.However, when an SE application accesses a service on a remote system, the local userid doesn't necessarily propagate through the network. Some Java APIs expose their own custom mechanism to provide runs on a machine under the userid that starts the server (typically "tomcat"). Java programs typically do not have any other credentials.
However, JAAS provides Java programs with a generic interface to various different network based "login" protocols. Through JAAS a Java program can present a userid and password (in the JDBC connection or in a Web URL). JAAS provides a common service that can be used by other Java network services.A J2EE container may want to identify a remote user and associate this identity with a Request, the thread processing the Request, and perhaps a Session object shared across requests. JAAS provides a common API and some standard services that can support container based authentication, but it is up to the container to save the results generated by the JAAS authentication in its own management objectsKerberos keytab file) and login to Kerberos or an LDAP server. Other than validating the userid and password, it is unclear what else you get from this. For example, JDBC still requires you to present the userid and password separately on the database Connection, and JNDI still requires you to present the userid and password when setting up the InitialContext.
The one useful feature of JAAS is that it allows a Java program to obtain a Ticket Granting Ticket from Kerberos, and using it to obtain and validate Service Tickets. This is a mostly undocumented feature, however, and it is fairly technical and requires a lot of additional setup.
So in practice JAAS is an API that is not really "connected to anything". You can use it to login, but then you can't do anything with the login. However, if in the future anyone developed a reason to use a login API, one would already exist.
CAS can use JAAS to validate the userid and password to a Kerberos KDC or an LDAP server. AD supports both of these protocols. Currently we use LDAP, but we call it through JNDI rather than JAAS.
In the standard Java Runtime from Sun, there are JAAS plug-in LoginModule classes for Kerberos 5, LDAP, and several legacy network protocols (NT Lan Manager, NIS) that are probably no longer of current interest. However, given the standard interface exposed by JAAS, you can obtain software from third party vendors that either provide better versions of these protocols or new protocols for servers or network appliances.
...