27-02-2013, 12:10 PM
Interface Login Module
Interface Login.docx (Size: 32.19 KB / Downloads: 41)
INTRODUCTION
Login Module describes the interface implemented by authentication technology providers. LoginModules are plugged in under applications to provide a particular type of authentication.
While applications write to the Login Context API, authentication technology providers implement the Login Module interface. A Configuration specifies the Login Module(s) to be used with a particular login application. Therefore different LoginModules can be plugged in under the application without requiring any modifications to the application itself.
The Login Context is responsible for reading the Configuration and instantiating the appropriate LoginModules. Each Login Module is initialized with a Subject, a Callback Handler, shared Login Module state, and Login Module-specific options. The Subject represents the Subject currently being authenticated and is updated with relevant Credentials if authentication succeeds. LoginModules use the Callback Handler to communicate with users. The Callback Handler may be used to prompt for usernames and passwords, for example. Note that the Callback Handler may be null. LoginModules which absolutely require a Callback Handler to authenticate the Subject may throw a Login Exception. LoginModules optionally use the shared state to share information or data among themselves.
The Login Module-specific options represent the options configured for this Login Module by an administrator or user in the login Configuration. The options are defined by the Login Module itself and control the behavior within it. For example, a Login Module may define options to support debugging/testing capabilities. Options are defined using a key-value syntax, such as debug=true. The Login Module stores the options as a Map so that the values may be retrieved using the key. Note that there is no limit to the number of options a Login Module chooses to define.
The calling application sees the authentication process as a single operation. However, the authentication process within the Login Module proceeds in two distinct phases. In the first phase, the Login Module’s login method gets invoked by the Login Context’s login method. The login method for the Login Module then performs the actual authentication (prompt for and verify a password for example) and saves its authentication status as private state information. Once finished, the Login Module’s login method either returns true (if it succeeded) or false (if it should be ignored), or throws a Login Exception to specify a failure. In the failure case, the Login Module must not retry the authentication or introduce delays. The responsibility of such tasks belongs to the application. If the application attempts to retry the authentication, the Login Module’s login method will be called again.