[jboss-jira] [JBoss JIRA] Updated: (JBAS-7062) Number of options and behaviour of login modules should be extended to allow complex login configurations

[Oleg Stepanov (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBAS-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Stepanov updated JBAS-7062:
--------------------------------

    Attachment: modified_modules.zip


Here's the archive with modified AbstractServerLoginModule and UsernamePasswordLoginModule. The first contains methods for parsing the additional options and accessing the shared states, the second has its login method modified according to the proposed behaviour.

I believe these modifications won't affect any configurations with the new options being not specified.

> Number of options and behaviour of login modules should be extended to allow complex login configurations

> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7062
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7062
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.3.GA, JBossAS-5.1.0.GA
>         Environment: OS: Windows XP, JDK: Sun 1.6.0 Update 10, JBoss AS: 4.2.2.GA
>            Reporter: Oleg Stepanov
>            Assignee: Anil Saldhana
>            Priority: Optional
>         Attachments: modified_modules.zip
>
>
> 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 {scheme} 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira