With the current AbstractLoginModule/UsernamePasswordLoginModule design (which all the rest modules are sublcasses of) it is impossible to compose complex login configurations.
Consider the following scenario: there are two authentication subsystems, the database and LDAP. Let's say that database stores passwords being SHA1 hashed while LDAP instance uses MD5. For this case we could have used the following (for now yet imaginary) configuration of login modules:
0. ClientLoginModule. Used on the client side to push credentials into SecurityAssociations for passing along with EJB calls.
1. DatabaseServerLoginModule with SHA1 hash option and sufficient flag
2. ModifyPasswordLoginModule (subclass of UsernamePasswordLoginModule) that a) hashes password, b) adds

prefix to the hashed password as required by the section 5.3 of RFC2307 and c) stores the resulting password in the shared state accessible by the following modules.
3. LdapLoginModule with required flag and (at least the guess would be) the useFirstPass option.

With the current implementation it won't work. If we use useFirstPass option for any module and it finds shared credentials then no actual login is ever performed. Moreover, there's no way to tell the specific module that credentials should be taken from a callback handler but still stored in the shared state (or vice versa).

Proposed is to add more options to affect a login module's behavior:

• useInternalPass - if set to true, the module will try to use credentials stored under private keys in the sharedState instead of useFirstPass keys
• saveSharedPass - if true, the resulting credentials will be stored under javax.security.auth.login.name and javax.security.auth.login.password keys in the sharedState map.
• saveInternalPass - if true, the resulting credentials will be stored under private keys in the sharedState map (independently of useFirstPass flag).
• forceLogin - if true, the module will attempt to perform the login operation even if credentials were read from the sharedState.