JBoss 3.0.1 and DataSource username/password encryption

[jtorres]

I would like to encrypt the username and password contained in my Interbase service. Any suggestions on the possibilities?

[davidjencks]

If you use the login module approach you do not need to have the username /pw in any config files, you just need to find a way for the login module to supply them when needed. You will have to write your own login module. If you have just a single db user, I'd start with ConfiguredIdentityLoginModule in connector/..../security.

I'm not very familiar with all the possibilities. Where are you going to keep the secured info and how do you secure it in such a way that you can still log in when needed?

If you come up with something you like please consider contributing it -- there have been similar questions in the past.

[jtorres]

Thanks for your reply! I was going to use a simple algorithm for basic password-based-encryption of the username and password. I will investigate the use of ConfiguredIdentityLoginModule, and if successful, contribute to the group.

[jtorres]

JBoss3.0.0 with Tomcat
OS: Windows XP
DB: MySQL

I have created a new class which extends ConfiguredIdentityLoginModule and in my datasource service (mysql-service.xml), I have updated the ?MySqlDbRealm? to use the new class. Upon deployment of my application I get the following exception:

[pre]
2002-08-25 21:44:18,441 ERROR [org.jboss.ejb.EjbModule] Initialization failed
java.lang.SecurityException: Invalid authentication attempt, principal=null
...
[/pre]

Any suggestions as to why the principal would be null? I have the following setup in the login-config.xml and mysql-service.xml:
[pre]
<application-policy name = "MySqlDbRealm">

<login-module code = "com.test.integration.ExtendedConfiguredIdentityLoginModule" flag = "required">
<module-option name = "principal">root</module-option>
<module-option name = "userName">root</module-option>
<module-option name = "password">somepassword</module-option>
<module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=MySqlDS</module-option>
</login-module>

</application-policy>
[/pre]

Code:
[pre]
public class ExtendedConfiguredIdentityLoginModule extends ConfiguredIdentityLoginModule {

/**
* Define this class' clogger within JBoss
*/
private static final Logger log = Logger.getLogger(ExtendedConfiguredIdentityLoginModule.class);

public ExtendedConfiguredIdentityLoginModule(){
super();
}

//-- Override the ConfiguredIdentityLoginModule methods, as needed --//

public void initialize(Subject subject, CallbackHandler handler, Map sharedState, Map options) {

//get the encrypted username and password and decrypt
String encryptedUserName = (String) options.get("userName");

//for now, just use the encrypted username...decryption code forth coming
String decryptedUserName = encryptedUserName;
log.debug("Decrypted username: "+decryptedUserName);
//set the decrypted username into the options map
options.put("userName", decryptedUserName);

String encryptedPassword = (String) options.get("password");

//for now, just use the encrypted password...decryption code forth coming
String decryptedPassword = encryptedPassword;
log.debug("Decrypted password: "+decryptedPassword);
//set the decrypted username into the options map
options.put("password", decryptedPassword);

//print the options map for debug only
log.debug("Options Map after decryption: "+options);

//call the super class' method to finish the rest
super.initialize(subject, handler, sharedState, options);


}

}
[/pre]


TIA...

[davidjencks]

As I recall this error usually occurs when the ManagedConnectionFactoryName option doesn't actually match the object name for your ConnectionManager mbean.

If this isn't it please supply more stacktrace. You might try a session bean that just gets a connection to see what is wrong more clearly if the cmp stuff hides some of the trace.

Shouldn't you call super.initialize before decrypting? I haven't looked at the code for a while, but won't the superclass overwrite what you just put in options?

Where are you going to get the decryption key from that won't let the casual observer also decrypt the user/pw?