JBossDeveloper

Gotta love TRACE output ... now I have something to change and test!  Woohoo!

2010-04-06 14:46:52,453 TRACE [org.jboss.resource.security.JaasSecurityDomainIdentityLoginModule] (HDScanner) Failed to decode password: javax.management.MBeanException
    at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:184)
    at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
    at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
    at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
    at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271)
    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670)
    at org.jboss.resource.security.JaasSecurityDomainIdentityLoginModule$DecodeAction.run(JaasSecurityDomainIdentityLoginModule.java:209)

but why you ask ...

Caused by ...

Caused by: java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long
    at com.sun.crypto.provider.SunJCE_ab.a(DashoA13*..)
    at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineInit(DashoA13*..)
    at javax.crypto.Cipher.a(DashoA13*..)
    at javax.crypto.Cipher.a(DashoA13*..)
    at javax.crypto.Cipher.init(DashoA13*..)
    at javax.crypto.Cipher.init(DashoA13*..)
    at org.jboss.security.plugins.JaasSecurityDomain.decode(JaasSecurityDomain.java:538)
    at org.jboss.security.plugins.JaasSecurityDomain.decode64(JaasSecurityDomain.java:584)

Who knew :-)  That was not in the example file documented ... :-)

Ok, gonna try with this new piece of info and report back shortly.

Woohoo ... it works ...

2010-04-06 14:59:13,843 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.EncryptedMySQLDbRealm] (HDScanner) Begin isValid, principal:null, cache info: null
2010-04-06 14:59:13,843 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.EncryptedMySQLDbRealm] (HDScanner) defaultLogin, principal=null
2010-04-06 14:59:13,843 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] (HDScanner) Begin getAppConfigurationEntry(EncryptedMySQLDbRealm), size=13
2010-04-06 14:59:13,859 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] (HDScanner) End getAppConfigurationEntry(EncryptedMySQLDbRealm), authInfo=AppConfigurationEntry[]:
[0]
LoginModule Class: org.jboss.resource.security.JaasSecurityDomainIdentityLoginModule
ControlFlag: LoginModuleControlFlag: required
Options:
name=managedConnectionFactoryName, value=jboss.jca:service=LocalTxCM,name=MySqlDS
name=username, value=MyUserName
name=jaasSecurityDomain, value=jboss.security:service=JaasSecurityDomain,domain=ServerMasterPassword
name=password, value=****

If I mimic the example from hsqldb-encrypted-ds.xml in {JbossInstallDirectory}\docs\examples\jca exactly I get positive results.  So, I now have both senario's working.

I do not have Oracle, but will now try this with Postgres and see if I can reproduce positive results.  Also going to try different parameters on the password creation and salt values (but will keep the salt to 8 characters).

:-)

Thanks again for all the help!

I can confirm that I have both MySQL and Postgres working with JaasSecurityDomainIdentityLoginModule.  A small side not, if you place the mbean details in one of the *-ds.xml files, it is not required in the other.  It need only be registered once.  You can create two application policies that reference the one mbean.  Here is my current configuration that is working via Eclipse Java EE IDE for Web Developers Build id: 20100218-1602

JBoss 6.0.0.M2 installed and running via JBoss 6 server config in Eclipse point at the default server config.

SecureIdentityLoginModule - login-config.xml snipet

    <application-policy name="EncryptMySQLDbPassword">
        <authentication>
            <login-module code="org.jboss.resource.security.SecureIdentityLoginModule"
                flag="required">
                <module-option name="username">userName</module-option>
                <module-option name="password">generatedPassword</module-option>
                <module-option name="managedConnectionFactoryName">jboss.jca:name=MySqlDS,service=LocalTxCM</module-option>
            </login-module>
        </authentication>
    </application-policy>

replace userName with your login username for MySQL.

replace generatedPassword with password you generate using (the word password below should be the password for your MySQL username)

java -cp client/jboss-logging-spi.jar;common/lib/jbosssx.jar org.jboss.resource.security.SecureIdentityLoginModule password

JaasSecurityDomainIdentityLoginModule - login-config.xml snipet for both MySQL and Postgres

     <application-policy name="EncryptedMySQLDbRealm">
        <authentication>
            <login-module code="org.jboss.resource.security.JaasSecurityDomainIdentityLoginModule" flag="required">
                <module-option name="username">userNameForMySQL</module-option>
                <module-option name="password">encryptedPasswordForMySQL</module-option>
                <module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=MySqlDS</module-option>
                <module-option name="jaasSecurityDomain">jboss.security:service=JaasSecurityDomain,domain=ServerMasterPassword</module-option>
            </login-module>
        </authentication>
    </application-policy>

    <application-policy name="EncryptedPostgresDbRealm">
        <authentication>
            <login-module code="org.jboss.resource.security.JaasSecurityDomainIdentityLoginModule" flag="required">
                <module-option name="username">userNameForPostgres</module-option>
                <module-option name="password">encryptedPasswordForPostgres</module-option>
                <module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=PostgresDS</module-option>
                <module-option name="jaasSecurityDomain">jboss.security:service=JaasSecurityDomain,domain=ServerMasterPassword</module-option>
            </login-module>
        </authentication>
    </application-policy>

following the details in hsqldb-encrypted-ds.xml (found in docs\examples\jca), you need to first set up a server.password file in your conf directory.

Change directory to your conf directory and run the following ... (ensure you specify full path to jbosssx.jar or have it on classpath).

java -cp jbosssx.jar org.jboss.security.plugins.FilePassword 12345678 17 master server.password

replace 12345678 by any *EIGHT* numbers and letters - no special characters, replace 17 by a number for the number of iterations you want the algorithm to be applied ... something bigger than 50.  Change master to a password that is strong and would be typically used as a master password.   Something like 8@DA$$P@%%w0rd

:-)

ok, so now you replace  userNameForMySQL with your username for mysql (ideally a service account that has been permissioned properly)

you replace  userNameForPostgres with your username for postgres (ideally a service account that has been permissioned properly)

To generate  encryptedPasswordForMySQL, following the details in hsqldb-encrypted-ds.xml you run the following: (again, samething about the classpath and jbosssx.jar)

java -cp jbosssx.jar org.jboss.security.plugins.PBEUtils abcdefgh 13 master password

replace abcdefg by any *EIGHT* numbers and letters - no special characters, replace 13 by a  number for the number of iterations you want the algorithm to be applied  ... something bigger than 50.  Change master to the master password you used above ... replace the word password with the password used by the account for mySQL and it will generate something that looks like this:

2.9eeq1Hi7X0dvJHmHdl3

Put this in for  encryptedPasswordForMySQL ... repeat for Postgres.

Save the application policies at the top of your login-config.xml file in your conf directory.

Now configure your datasource files.  This is how I did mine.

mysql-ds.xml

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
    <local-tx-datasource>
        <jndi-name>MySqlDS</jndi-name>
        <connection-url>jdbc:mysql://127.0.0.1:3306/yourDBName</connection-url>
        <min-pool-size>5</min-pool-size>
        <max-pool-size>20</max-pool-size>
        <driver-class>com.mysql.jdbc.Driver</driver-class>
        <security-domain>EncryptedMySQLDbRealm</security-domain>
        <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter
        </exception-sorter-class-name>
        <metadata>
            <type-mapping>mySQL</type-mapping>
        </metadata>
    </local-tx-datasource> 
    <mbean code="org.jboss.security.plugins.JaasSecurityDomain"
        name="jboss.security:service=JaasSecurityDomain,domain=ServerMasterPassword">
        <constructor>
            <arg type="java.lang.String" value="ServerMasterPassword" />
        </constructor>
        <attribute name="KeyStorePass">{CLASS}org.jboss.security.plugins.FilePassword:${jboss.server.home.dir}/conf/server.password
        </attribute>
        <attribute name="Salt">Your*EIGHT*CharacterSALTusedAbove</attribute>
        <attribute name="IterationCount">YourNumberOfIterationsYouSpecifiedAbove</attribute>
    </mbean>
</datasources>

postgres-ds.xml - do not include the mbean in the file - if you are only using postgres - you will need to include the mbean from the example above.

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
    <local-tx-datasource>
        <jndi-name>PostgresDS</jndi-name>
        <connection-url>jdbc:postgresql://127.0.0.1:5432/yourDBName
        </connection-url>
        <driver-class>org.postgresql.Driver</driver-class>
        <min-pool-size>5</min-pool-size>
        <max-pool-size>20</max-pool-size>
        <security-domain>EncryptedPostgresDbRealm</security-domain>
        <metadata>
            <type-mapping>PostgreSQL</type-mapping>
        </metadata>
    </local-tx-datasource>
</datasources>

Save these *-ds.xml files in your deploy directory.

You should be good to go.

My persistence.xml looks like this (it is save in the META-INF directory)

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
    version="1.0">
    <persistence-unit name="titan">
        <jta-data-source>java:/PostgresDS</jta-data-source>
        <properties>
            <property name="hibernate.ejb.cfgfile" value="/META-INF/hibernate.cfg.xml" />
        </properties>
    </persistence-unit>
</persistence>

hibernate.cfg.xml is also located in META-INF - this configured for my postgres instance.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
          "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
          "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
    <session-factory>
        <property name="c3p0.min_size">5</property>
        <property name="c3p0.max_size">20</property>
        <property name="c3p0.timeout">300</property>
        <property name="c3p0.max_statements">50</property>
        <property name="c3p0.idle_test_period">3000</property>
        <property name="show_sql">true</property>
        <property name="hbm2ddl.auto">create-drop</property>
        <property name="archive.autodetection">class, hbm</property>
        <property name="dialect">org.hibernate.dialect.PostgreSQLDialect</property>
        <property name="transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>
        <!--
            thread is the short name for
            org.hibernate.context.ThreadLocalSessionContext and let Hibernate
            bind the session automatically to the thread
         -->
        <property name="current_session_context_class">thread</property>
    </session-factory>
    <!--
        c3p0 is very tunable, and offers a somewhat bewildering array of
        configuration parameters. For the complete list, see
        http://www.mchange.com/projects/c3p0/index.html#appendix_a Here are a
        subset of the most important features:
    -->
    <!-- initialPoolSize: C3P0 default: 3  
    -->
    <!--
        minPoolSize: Must be set in hibernate.cfg.xml (or
        hibernate.properties), Hibernate default: 1
    -->
    <!--
        maxPoolSize: Must be set in hibernate.cfg.xml (or
        hibernate.properties), Hibernate default: 100
    -->
    <!--
        timeout: Must be set in hibernate.cfg.xml (or hibernate.properties),
        Hibernate default: 0 The seconds a Connection can remain pooled but
        unused before being discarded. Zero means idle connections never
        expire.
    -->
    <!--
        idleTestPeriod: Must be set in hibernate.cfg.xml (or
        hibernate.properties), Hibernate default: 0 If this is a number
        greater than 0, c3p0 will test all idle, pooled but unchecked-out
        connections, every this number of seconds.
    -->
    <!--
        maxStatements: Must be set in hibernate.cfg.xml (or
        hibernate.properties), Hibernate default: 0 The size of c3p0's
        PreparedStatement cache. Zero means statement caching is turned off.
    -->
    <!--
        propertyCycle: Must be set in c3p0.properties, C3P0 default: 300
        Maximum time in seconds before user configuration constraints are
        enforced. c3p0 enforces configuration constraints continually, and
        ignores this parameter. It is included for JDBC3 completeness.
    -->
    <!--
        acquireIncrement: Must be set in hibernate.cfg.xml (or
        hibernate.properties), Hibernate default: 1 Determines how many
        connections at a time c3p0 will try to acquire when the pool is
        exhausted.
    -->
    <!--
        testConnectionOnCheckout: Must be set in c3p0.properties, C3P0
        default: false Don't use it, this feature is very expensive. If set to
        true, an operation will be performed at every connection checkout to
        verify that the connection is valid. A better choice is to verify
        connections periodically using c3p0.idleConnectionTestPeriod.
    -->
    <!--
        autoCommitOnClose: Must be set in c3p0.properties, C3P0 default: false
        The JDBC spec is unfortunately silent on what should happen to
        unresolved, pending transactions on Connection close. C3P0's default
        policy is to rollback any uncommitted, pending work. (I think this is
        absolutely, undeniably the right policy, but there is no consensus
        among JDBC driver vendors.) Setting autoCommitOnClose to true causes
        uncommitted pending work to be committed, rather than rolled back on
        Connection close. [Note: Since the spec is absurdly unclear on this
        question, application authors who wish to avoid bugs and inconsistent
        behavior should ensure that all transactions are explicitly either
        committed or rolled-back before close is called.]
    -->
    <!--
        forceIgnoreUnresolvedTransactions: Must be set in c3p0.properties,
        C3P0 default: false Strongly disrecommended. Setting this to true may
        lead to subtle and bizarre bugs. This is a terrible setting, leave it
        alone unless absolutely necessary. It is here to work around broken
        databases / JDBC drivers that do not properly support transactions,
        but that allow Connections' autoCommit flags to be set to false
        regardless. If you are using a database that supports transactions
        "partially" (this is oxymoronic, as the whole point of transactions is
        to perform operations reliably and completely, but nevertheless, such
        databases exist), if you feel comfortable ignoring the fact that
        Connections with autoCommit == false may be in the middle of
        transactions and may hold locks and other resources, you may turn off
        c3p0's wise default behavior, which is to protect itself, as well as
        the usability and consistency of the database, by either rolling back
        (default) or committing (see c3p0.autoCommitOnClose above) unresolved
        transactions. This should only be set to true when you are sure you
        are using a database that allows Connections' autoCommit flag to go to
        false, but that it offers no other meaningful support of transactions.
        Otherwise setting this to true is just a bad idea.
    -->
    <!--
        numHelperThreads: Must be set in c3p0.properties, C3P0 default: 3 c3p0
        is very asynchronous. Slow JDBC operations are generally performed by
        helper threads that don't hold contended locks. Spreading these
        operations over multiple threads can significantly improve performance
        by allowing multiple operations to be performed simultaneously.
    -->
    <!--
        factoryClassLocation: Must be set in c3p0.properties, C3P0 default:
        null DataSources that will be bound by JNDI and use that API's
        Referenceable interface to store themselves may specify a URL from
        which the class capable of dereferencing a them may be loaded. If (as
        is usually the case) the c3p0 libraries will be locally available to
        the JNDI service, leave this set to null. Regards, Anthony (see
        http://forum.hibernate.org/viewtopic.php?t=934779 for more details)
    -->
</hibernate-configuration>

I hope you find this helpful.

Good luck with your pursue of secure applications!

Tim, good to know you got it working And thanks for posting the details.

Here are my configs that worked for SecureIdentityLoginModule:

The policy in the login-config.xml file:

       <application-policy name="EncryptMySQLDbPassword">

            <authentication>
                <login-module
                    code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required">
                    <module-option name="username">myUserName</module-option>
                    <module-option name="password">theGeneratedEncryptedPassword</module-option>
                    <module-option name="managedConnectionFactoryName">jboss.jca:name=MySqlDS,service=LocalTxCM</module-option>
                </login-module>
            </authentication>
        </application-policy>

myUserName is the appropriately permissioned MySQL user associated with the mysql-ds.xml MySqlDS JNDI name

theGeneratedEncryptedPassword is the password generated from excuting the following:

java -cp client/jboss-logging-spi.jar;common/lib/jbosssx.jar org.jboss.resource.security.SecureIdentityLoginModule password

where the word password is replaced by the password for the MySQL user above.

My mysql-ds.xml is as follows that worked with this application policy:

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
    <local-tx-datasource>
        <jndi-name>MySqlDS</jndi-name>
        <connection-url>jdbc:mysql://127.0.0.1:3306/myDBName</connection-url>
        <driver-class>com.mysql.jdbc.Driver</driver-class>
        <security-domain>EncryptMySQLDbPassword</security-domain>
        <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
        <metadata>
            <type-mapping>mySQL</type-mapping>
        </metadata>
    </local-tx-datasource>
</datasources>

To turn on Tracing and get **MASSIVE** log output ... do the following in the jboss-logging.xml I did the following:

<periodic-rotating-file-handler
         file-name="${jboss.server.log.dir}/server.log"
         name="FILE"
         autoflush="true"
         append="true"
         suffix=".yyyy-MM-dd">  <!-- To roll over at the top of each hour, use ".yyyy-MM-dd-HH" instead -->

      <level name="TRACE"/>

dot dot dot

<console-handler name="CONSOLE" autoflush="true" target="System.out">
      <error-manager>
         <only-once/>
      </error-manager>

      <level name="TRACE"/>

dot dot dot


   <root-logger>
      <!-- Set the root logger priority via a system property, with a default value. -->
      <level name="${jboss.server.log.threshold:TRACE}"/>
      <handlers>
         <handler-ref name="CONSOLE"/>
         <handler-ref name="FILE"/>
      </handlers>
   </root-logger>

Be warned, do not leave your server running for too long ... it generates a hugh amount of data!

Hi Mercer,

Thanks for your help. I was trying to use SecureIdentityLoginModule but there was an error "Unauthenticated Caller : null" occurring everytime on JBoss Server startup (I am using Jboss 6.1.0Final). In the end, I got rid of this error by adding the module option "principal" as

<application-policy name="MyDBRealm">
    <authentication>
      <login-module code="org.jboss.resource.security.SecureIdentityLoginModule"
        flag="required">
        <module-option name="principal">manpower</module-option>
        <module-option name="userName">root</module-option>
        <module-option name="password">6f8e652f571678f2</module-option>
        <module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=manpowerds</module-option>
      </login-module>
    </authentication>
  </application-policy>

- manpower is MySQL database name