The figure below gives a high-level overview of how JAAS achieves this pluggability. Your application-layer code deals primarily with a
LoginContext. Underneath that LoginContext is a set of one or more dynamically configured
LoginModules, which handle the actual authentication using the appropriate security infrastructure.
In addition to being pluggable, JAAS is stackable: in the context of a single login, a set of security modules can stack on top of one another, each called in order and each interacting with a different security infrastructure.
Using JAAS authentication from your application typically involves the following steps:
- Create a LoginContext
- Optionally pass a CallbackHandler to the LoginContext, for gathering or processing authentication data
- Perform authentication by calling the LoginContext's login() method
- Perform privileged actions using the returned Subject (assuming login succeeds)
The configuration file structure is
Application {
ModuleClass Flag ModuleOptions;
ModuleClass Flag ModuleOptions;
...
};
Application {
ModuleClass Flag ModuleOptions;
...
};
The options for "Flag" is REQUIRED, REQUISITE, SUFFICIENT and OPTIONAL.
REQUIRED
This option is the default setting for any Authentication Provider. A required Authentication Provider is always invoked, irrespective of the control flag settings on other providers. The overall authentication cannot succeed if any REQUIRED provider fails. Thus, REQUIRED providers are always invoked, and overall authentication fails if any one of them fails.
REQUISITE
This option also requires the Authentication Provider to succeed during the login sequence. However, all of the REQUISITE providers need not be invoked for the overall authentication to succeed. If a REQUISITE provider succeeds, the authentication proceeds as normal to other providers in the sequence. However, if it fails, the overall authentication cannot succeed, and control is immediately passed back to the application once all REQUIRED providers in the login sequence have been invoked.
SUFFICIENT
This option does not require the Authentication Provider to succeed during the login sequence. If a SUFFICIENT provider does succeed, the overall authentication proceeds to ensure that only the remaining REQUIRED providers in the login sequence are executed. However, if it fails, the overall authentication proceeds as normal to the other providers in the login sequence.
OPTIONAL
This option does not require the Authentication Provider to succeed during the login sequence. Regardless of whether an OPTIONAL provider succeeds, the authentication proceeds to other providers that have been configured as part of the login sequence.
* All REQUIRED modules must be invoked, and each must successfully validate the user.
* Any REQUISITE module that gets invoked must successfully validate the user.
* If a SUFFICIENT module successfully validates the user, the overall success depends on the success of all REQUIRED modules, and any REQUISITE modules invoked before the SUFFICIENT module.
* If the login sequence consists only of OPTIONAL modules, at least one module must successfully validate the user.
LoginContext lc = new LoginContext("JaasSample");
try {
lc.login();
} catch (LoginException) {
// Authentication failed.
}
// Authentication successful, we can now continue.
// We can use the returned Subject if we like.
Subject sub = lc.getSubject();
Subject.doAs(sub, new MyPrivilegedAction());LoginContext Configuration When your code instantiates a LoginContext, you pass it the name of one of the application blocks in the configuration file. The LoginContext will use LoginModules based on what you specify in the application entry. These specifications drive which LoginModules are invoked, in which order, and according to which rules.
JaasSample {
com.sun.security.auth.module.Krb5LoginModule required debug=true;
};
For example, the configuration file is saved as
jaas.config, then we would specify the location on the command line as follows:
java -Djava.security.auth.login.config=jaas.config JaasTestClassName
| Common | Subject, Principal, credential (credential is not any specific class, but can be any object) |
| Authentication | LoginContext, LoginModule, CallbackHandler, Callback |
| Authorization | Policy, AuthPermission, PrivateCredentialPermission |
The Subject class represents an authenticated entity.
Principals represent Subject identities.A Subject instance contains an array of Principals, it can thus have multiple name, such like a social security number, login ID, email address, and so on
Credentials can include any authentication artifact, such as a ticket, key, or password, that specific security systems might require.
CallbackHandlers and
Callbacks let a LoginModule gather necessary authentication information from a user or system.
