We are currently planning an authentication/authorization scheme on a system involving a Java Webstart application workstation doing mainly presentation and configuration, delegating the demanding memory & CPU intensive calculation tasks and the persisting of the configuration settings to stateless session beans running on a JBoss cluster.
JAAS approach with ClientLoginModule seems like the obvious choice on the Java application client side and checking the credentials from Ldap on the serer side, but there is one problem: Client login and role info would already be needed when parsing the JNLP file for the webstart application, because the workstation software is contructed from different set of pluggable modules based on user profiles.
To avoid double sing-on, we thought we had to do the login with a separate servlet against Ldap and pass the user credentials to the webstart application by giving them as properties in the gererated JNLP file. I did not like this, giving the user's plain text password in the JNLP file is out of the question.
So what I was thinking was that the login servlet would do the login against our existing external LDAP server (using the LdapLoginModule), generate a temporary password, store it in the user DB with other user session information and put this temporary password in the JNLP file as a property. Then the Webstart app would use the userid and this temporary password as user credentials with the ClientLoginModule when making EJB calls to the JBoss cluster. The EJBs would be configured in other security domain than the login servlet configured to do the authentication and authorization using DatabaseServerLoginModule against the user DB containing the userid and the temporary password (if login was successful and the session is still valid).
If the session gets invalidated, the Webstart app would still have to ask the user for the real password to make a new session using the login servlet and start using the new returned temporary password bound to the new session when communicating with the EJBs (thus two JAAS login contexts on the client side).
Now this is not exactly how things are done in the manual, so I would like to ask if anyone sees any obvious security holes or problems with this kind of scheme? An comments would be appreciated as I'm not exacly a network security wizard.