JAAS has as its main goal the separation of concerns of user authentication so that they may be managed independently. While the former authentication mechanism contained information about where the code originated from and who signed that code, JAAS adds a marker about who runs the code. By extending the verification vectors JAAS extends the security architecture for Java applications that require authentication and authorization modules.

Login modules are primarily concerned with authentication rather than authorization and form a widely used component of JAAS. A login module is required to implement the javax.security.auth.spi.LoginModule interface, which specifies the following methods:

Note: A Subject is the user that is attempting to log in.

initialize: Code to initialize the login module, usually by storing the parameters passed into appropriate fields of the Class.

login: Actually check the credentials provided via an Object that implements the javax.security.auth.Callback interface (e.g. check against a database). This method could prompt the user for their login and password or it could use details previously obtained. It is important to note here that, if invalid credentials are supplied then a javax.security.auth.login.FailedLoginException should be thrown (rather than returning false, which indicates that this login module should be ignored, which potentially allows authentication to succeed).

commit: The identity of the subject has been verified, so code in this method sets up the Principal and Groups (roles) for the successfully authenticated subject. This method has to be written carefully in enterprise applications as Java EE application servers often expect the relationships between the Principal and Group objects to be set up in a certain way. This method should throw a javax.security.auth.login.FailedLoginException if authentication fails (e.g. a user has specified an incorrect login or password).

abort: Called if the authentication process itself fails. If this method returns false, then this Login Module is ignored.

logout: Code that should be executed upon logout (e.g. could remove the Principal from the Subject or could invalidate a web session).

Login modules can provide single sign on (SSO) via a particular SSO protocol/framework (e.g. SAML, OpenID, and SPNEGO), can check for the presence of hardware security tokens (e.g. USB token), etc. In an n-tier application, LoginModules can be present on both the client side and server side.

Login modules are written by implementing this interface; they contain the actual code for authentication. It can use various mechanisms to authenticate user credentials. The code could retrieve a password from a database and compare it to the password supplied to the module.

The login context is the core of the JAAS framework which kicks off the authentication process by creating a Subject. As the authentication process proceeds, the subject is populated with various principals and credentials for further processing.

Credentials are nothing but pieces of information regarding the subject in consideration. They might be account numbers, passwords, certificates etc. As the credential represents some important information, the further interfaces might be useful for creating a proper and secure credential – javax.security.auth.Destroyable and javax.security.auth.Refreshable. Suppose that after the successful authentication of the user you populate the subject with a secret ID (in the form of a credential) with which the subject can execute some critical services, but the credential should be removed after a specific time. In that case, one might want to implement the Destroyable interface. Refreshable might be useful if a credential has only a limited timespan in which it is valid.

Form authentication is another commonly used part of JAAS. In this process the user is typically presented with a web page containing a form asking for a username and password. This data is then submitted via POST to a URL containing the text j_security_check, e.g. www.example.com/j_security_check . The credentials are checked on the server side and a session ID is returned to the client via a cookie. This authentication method is flexible in that a Java HTTP client such as Apache HTTP client can be used in place of a web-browser, e.g. in a desktop application, as long as the following standard steps are followed:

Request a protected URL (i.e. secured via a security-constraint element) in web.xml (where the login-config element has specified an authentication method of "FORM").

The server will return a redirect (302) to the security check URL mentioned above along with a cookie containing the session ID (JSESSIONID=...).

Send the username and password (encoded as form fields) along with the cookie via an HTTP POST to the security check URL.

If authentication is successful, the server will send a 302 back to the original protected URL.

Send a GET request to that URL, passing the session ID cookie (preferably assert that the response contains what you would expect from that original URL).