Shared Authentication
CAS is a Single Sign-On mechanism. The user logs on once to the CAS server and identifies himself though that one server to all the applications on the network. However, CAS can only be used by Web based applications that can be adapted to use its protocol. When you cannot use SSO, then you still want to avoid ending up with a dozen different systems each with its own set of userids and passwords.
The next best alternative is a network based system of shared authentication. You select a reliable, secure system to hold the userid/password data. It must expose a network API that allows the password validation to be done by lots of different systems and languages. Then each system may provide a login form where the user has to enter a userid and password, but the validation is done centrally.
Back in the old days it was popular to validate passwords using the Novell Netware systems, or the Microsoft LAN Manager, or Unix NIS. However, modern systems tend to choose either Kerberos 5 or LDAP. Both of these protocols are supported by Active Directory, and most systems and languages have client support for one or both of them. Kerberos is inherently secure, while LDAP can be made secure if it runs over SSL.
Rather than coding specific Kerberos or LDAP authentication logic for every application, Unix systems developed the idea of a Pluggable Authentication Module (PAM). There is a single standard programming interface that every application can use. Behind that interface, a system administrator can plug in one or more service provider modules that use Kerberos, LDAP, a database system, or some network appliance to validate the userid and password and maybe return information about the user.
Shared authentication becomes more complicated as authentication itself becomes more involved. In the old days you just used passwords and that was good enough. In the new world it may be necessary to establish identity by using passwords and some physical device that plugs into a USB port. Pluggable authentication has to be able to extend to these more complicated environments.
JAAS - Pluggable Java Authentication
JAAS became the Java SE version of the PAM idea. Standard Java releases since 1.4 have included the javax.security.auth.* packages. They work like JDBC in exposing a single standard front set of classes that are extended by adding external libraries to the classpath that provide additional classes implementing a service provider interface. JDBC is extended by libraries of database drivers, while JAAS is extended by login providers.
Out of the box, Sun provides classes to do the Kerberos 5 and LDAP login function. Those are probably the best choices for any institution planning to use standard internet protocols and network based software solutions. However, hardware manufactures selling USB dongles and Smart Cards may also sell network appliances that authenticate users of these hardware devices. JAAS provides a standard interface that can be used for even exotic requirements. The vendor simply provides a JAR file with classes that implement the JAAS service provider interface, and then the system administrator can configure the vendor authentication as easily as one of the standard Sun classes.
The first time someone learns about JAAS, they probably use it to validate a userid and password against a standard network server (like Microsoft AD). At first, the API seems more complicated than you expect:
- The Java code creates a Callback object that holds the userid and password. This object will be passed to JAAS, which will call it in the middle of login to obtain the userid and password parameters.
- Then the program creates a LoginContext object passing a character string naming an external JAAS configuration parameter bundle in one of the login configuration files and the Callback object.
- The login() method of the LoginContext authenticates the userid and password using whatever service provider class was specified and parameterized by the configuration bundle.
The reason for the callback class is that userid and password are not the only credentials someone can use to prove their identity. In addition to password, a Kerberos 5 KDC can authenticate using a keytab file containing the secret private key derived from the password. Keytab files are a common way to identify not people, but specific services residing on machines in the network. When the private key is stored on a USB device, then the callback provides an opportunity for a special Java driver to use the device to prove identity.
JAAS is different from most of the standard Java services in that it is not designed to work exactly the same on all systems. The "write once run anywhere" rule applies to applications. JAAS removes the actual work of authentication from the application, leaving only the request interface. That request will "work" on all systems, but the algorithms that back it must vary not just between different types of operating systems, but more importantly between different institutions. Run the same application on the same container on the same OS, and authentication at Harvard is not necessarily the same thing as authentication at Yale.applications.
There are also some extra features to JAAS, particularly when it is used in Kerberos 5. However, before these features can be understood, we need to probe a bit more into the parts of the JAAS API that people do not learn when they are just using it to verify a password.
JAAS Login Context
To use JAAS