A login configuration contains the following information. Note that this example only represents the default syntax for the {@code Configuration}. Subclass implementations of this class may implement alternative syntaxes and may retrieve the {@code Configuration} from any source such as files, databases,or servers.
Name { ModuleClass Flag ModuleOptions; ModuleClass Flag ModuleOptions; ModuleClass Flag ModuleOptions; }; Name { ModuleClass Flag ModuleOptions; ModuleClass Flag ModuleOptions; }; other { ModuleClass Flag ModuleOptions; ModuleClass Flag ModuleOptions; };
Each entry in the {@code Configuration} is indexed via anapplication name, Name, and contains a list of LoginModules configured for that application. Each {@code LoginModule}is specified via its fully qualified class name. Authentication proceeds down the module list in the exact order specified. If an application does not have a specific entry, it defaults to the specific entry for "other".
The Flag value controls the overall behavior as authentication proceeds down the stack. The following represents a description of the valid values for Flag and their respective semantics:
1) Required - The {@code LoginModule} is required to succeed.If it succeeds or fails, authentication still continues to proceed down the {@code LoginModule} list.2) Requisite - The {@code LoginModule} is required to succeed.If it succeeds, authentication continues down the {@code LoginModule} list. If it fails,control immediately returns to the application (authentication does not proceed down the {@code LoginModule} list).3) Sufficient - The {@code LoginModule} is not required tosucceed. If it does succeed, control immediately returns to the application (authentication does not proceed down the {@code LoginModule} list).If it fails, authentication continues down the {@code LoginModule} list.4) Optional - The {@code LoginModule} is not required tosucceed. If it succeeds or fails, authentication still continues to proceed down the {@code LoginModule} list.
The overall authentication succeeds only if all Required and Requisite LoginModules succeed. If a Sufficient {@code LoginModule} is configured and succeeds,then only the Required and Requisite LoginModules prior to that Sufficient {@code LoginModule} need to have succeeded forthe overall authentication to succeed. If no Required or Requisite LoginModules are configured for an application, then at least one Sufficient or Optional {@code LoginModule} must succeed.
ModuleOptions is a space separated list of {@code LoginModule}-specific values which are passed directly to the underlying LoginModules. Options are defined by the {@code LoginModule} itself, and control the behavior within it.For example, a {@code LoginModule} may define options to supportdebugging/testing capabilities. The correct way to specify options in the {@code Configuration} is by using the following key-value pairing:debug="true". The key and value should be separated by an 'equals' symbol, and the value should be surrounded by double quotes. If a String in the form, ${system.property}, occurs in the value, it will be expanded to the value of the system property. Note that there is no limit to the number of options a {@code LoginModule} may define.
The following represents an example {@code Configuration} entrybased on the syntax above:
Login { com.sun.security.auth.module.UnixLoginModule required; com.sun.security.auth.module.Krb5LoginModule optional useTicketCache="true" ticketCache="${user.home}${/}tickets"; };
This {@code Configuration} specifies that an application named,"Login", requires users to first authenticate to the com.sun.security.auth.module.UnixLoginModule, which is required to succeed. Even if the UnixLoginModule authentication fails, the com.sun.security.auth.module.Krb5LoginModule still gets invoked. This helps hide the source of failure. Since the Krb5LoginModule is Optional, the overall authentication succeeds only if the UnixLoginModule (Required) succeeds.
Also note that the LoginModule-specific options, useTicketCache="true" and ticketCache=${user.home}${/}tickets", are passed to the Krb5LoginModule. These options instruct the Krb5LoginModule to use the ticket cache at the specified location. The system properties, user.home and / (file.separator), are expanded to their respective values.
There is only one Configuration object installed in the runtime at any given time. A Configuration object can be installed by calling the {@code setConfiguration} method. The installed Configuration objectcan be obtained by calling the {@code getConfiguration} method.
If no Configuration object has been installed in the runtime, a call to {@code getConfiguration} installs an instance of the defaultConfiguration implementation (a default subclass implementation of this abstract class). The default Configuration implementation can be changed by setting the value of the {@code login.configuration.provider} security property to the fullyqualified name of the desired Configuration subclass implementation.
Application code can directly subclass Configuration to provide a custom implementation. In addition, an instance of a Configuration object can be constructed by invoking one of the {@code getInstance} factory methodswith a standard type. The default policy type is "JavaLoginConfig". See the Configuration section in the Java Cryptography Architecture Standard Algorithm Name Documentation for a list of standard Configuration types. @see javax.security.auth.login.LoginContext @see java.security.Security security properties
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|