ORA-01017: invalid username/mot de passe; connexion refusée lors de l'utilisation de wss4j

J'ai beaucoup de tests qui accèdent à notre Oracle DB sans problème, cependant quand je lance ces tests avec d'autres tests dans notre base de code qui utilisent un fichier de clés, les tests qui interagissent avec le DB ne sont plus en mesure de se connecter. Ici est l'exception:

Causés par: java.sql.SQLException: ORA-01017: invalid username/mot de passe; connexion refusée
chez oracle.jdbc.le pilote.T4CTTIoer.processError(T4CTTIoer.java:439)
chez oracle.jdbc.le pilote.T4CTTIoer.processError(T4CTTIoer.java:388)
chez oracle.jdbc.le pilote.T4CTTIoer.processError(T4CTTIoer.java:381)
chez oracle.jdbc.le pilote.T4CTTIfun.processError(T4CTTIfun.java:564)
chez oracle.jdbc.le pilote.T4CTTIoauthenticate.processError(T4CTTIoauthenticate.java:431)
chez oracle.jdbc.le pilote.T4CTTIfun.recevoir(T4CTTIfun.java:436)
chez oracle.jdbc.le pilote.T4CTTIfun.doRPC(T4CTTIfun.java:186)
chez oracle.jdbc.le pilote.T4CTTIoauthenticate.doOAUTH(T4CTTIoauthenticate.java:366)
chez oracle.jdbc.le pilote.T4CTTIoauthenticate.doOAUTH(T4CTTIoauthenticate.java:752)
chez oracle.jdbc.le pilote.T4CConnection.ouverture de session(T4CConnection.java:359)
chez oracle.jdbc.le pilote.PhysicalConnection.(PhysicalConnection.java:531)
chez oracle.jdbc.le pilote.T4CConnection.(T4CConnection.java:221)
chez oracle.jdbc.le pilote.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)
chez oracle.jdbc.le pilote.OracleDriver.connect(OracleDriver.java:503)
au org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:37)
au org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
au org.apache.commons.dbcp.BasicDataSource.validateConnectionFactory(BasicDataSource.java:877)
au org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:851)
... 68 plus

Évidemment le nom d'utilisateur et mot de passe sont corrects. Je vais avoir vraiment un moment difficile de déterminer ce qui, dans notre code à l'origine de l'échec de la connexion, et je ne sais pas vraiment comment déboguer ce qui se passe lorsque le pilote Oracle tente de se connecter. J'utilise l'Oracle mince pilote avec Oracle 11g. Nous utilisons Spring, Hibernate, et Apache Commons DBCP. Il semble que le pilote est peut-être pour essayer d'établir une connexion SSL à la DB? Je n'en suis pas sûr. Je crois me souvenir d'une très similaires problème avec SQL Server, lorsque nous étions encore à l'aide de qui, sur le moment j'ai juste ignoré. Droit maintenant, nous exécutez les tests qui interagissent avec le fichier de clés dans un lot distinct et JVM.

Toute aide serait grandement appréciée.

Mis à JOUR

J'ai fait un tas plus de débogage et enfin tracé ce jusqu'à notre utilisation de la wss4j bibliothèque (version 1.5.9) via Spring-WS. Finalement, le WSSConfig de classe devient un ensemble de code qui fait cela:

int ret = 0;
for (int i = 0; i < provs.length; i++) {
    if ("SUN".equals(provs[i].getName())
        || "IBMJCE".equals(provs[i].getName())) {
        ret =
            java.security.Security.insertProviderAt(
                (java.security.Provider) c.newInstance(), i + 2
            );
        break;
    }
}

Immédiatement après le code de mes connexions à Oracle d'arrêt de travail. Ça ressemble quand la insertProviderAt méthode est appelée à l'aide d'un château gonflable fournisseur de ma connexion Oracle commence à tomber en panne. Des idées?

Minimal De Cas De Test

La première tentative de connexion réussit, mais la deuxième tentative échoue.

Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@server/servicename", "username", "password");
conn.prepareStatement("select * from dual").getResultSet();
conn.close();
org.apache.ws.security.WSSConfig.getDefaultWSConfig();
conn = DriverManager.getConnection("jdbc:oracle:thin:server/servicename", "username", "password");
conn.prepareStatement("select * from dual").getResultSet();
conn.close();

WSSConfig Méthode Initialize

private synchronized void
    staticInit() {
        if (!staticallyInitialized) {
            org.apache.xml.security.Init.init();
            if (addJceProviders) {
                /*
                 * The last provider added has precedence, that is if JuiCE can be added
                 * then WSS4J uses this provider.
                 */
                addJceProvider("BC", "org.bouncycastle.jce.provider.BouncyCastleProvider");
                addJceProvider("JuiCE", "org.apache.security.juice.provider.JuiCEProviderOpenSSL");
            }
            Transform.init();
            try {
                Transform.register(
                    STRTransform.implementedTransformURI,
                    "org.apache.ws.security.transform.STRTransform"
                );
            } catch (Exception ex) {
                if (log.isDebugEnabled()) {
                    log.debug(ex.getMessage(), ex);
                }
            }
            staticallyInitialized = true;
        }
    }
Quand vous dites que "à l'Évidence, le nom d'utilisateur et mot de passe sont corrects" voulez-vous dire que vous avez réussi à vous connecter à la DB directement (par exemple avec sqlplus) à l'aide du nom d'utilisateur/mot de passe ?
Je veux dire tant que je ne pas exécuter les tests qui utilisent un fichier de clés, l'exécution des tests est très bien et se connecter sans problème. À moins que le magasin de clés manipule les informations d'identification d'une certaine manière, mais je ne vois pas comment ça pourrait arriver?
J'aimerais entendre la réponse.
Je voudrais vérifier qui sont les valeurs par défaut de l'obtenir par getDefaultWSConfig(). Peut-être que vos informations d'identification sont chiffrées ou d'obfuscation en quelque sorte
J'ai ajouté la méthode d'initialisation de WSSConfig, je ne suis pas totalement comprendre ce qui se passe ici, mais il semble casser dès que le château gonflable JCE fournisseur est ajouté. Finalement, ce code est appelé java.security.Security.insertProviderAt((java.security.Provider)c.newInstance(), i + 2);

OriginalL'auteur jjathman | 2012-07-10