2015-10-19 35 views
13

Stiamo eseguendo la migrazione di un'app Web WebLogic 10.3.5 a WebLogic 12.1.3 e abbiamo riscontrato un problema che riteniamo possa essere correlato alla sicurezza dei servizi Web. L'app utilizza Axis 1.5.6 per chiamare un servizio SOA Suite SOA (ancora in esecuzione su WebLogic 10.3.5). Quando la sicurezza del servizio Web è disattivata, torniamo la risposta attesa:Dati da SOA Suite a Axis2 interrotti

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<ns3:getNamesResponse 
    xmlns:ns2="http://www.example.com/ABC/Common" 
    xmlns:ns3="http://www.example.com/ABC/Profile"> 
    <ns3:OperatingName> 
     <ns3:Number>123456789</ns3:Number> 
     <ns3:Name>Company Name, Inc.</ns3:Name> 
    </ns3:OperatingName> 
</ns3:getNamesResponse> 

Ma non appena la sicurezza servizio web è abilitata (usando Apache Rampart 1.5.2, Apache Neethi 2.0.5), abbiamo iniziare a ricevere risposte vuote :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<ns2:getNamesResponse 
    xmlns:ns2="http://www.example.com/ABC/Profile" 
    xmlns:ns4="http://www.example.com/ABC/Common" /> 

la cosa strana è che quando si guarda attraverso la console SOA Suite, la risposta di SOA di nuovo alla web app (con la sicurezza abilitata) appare corretta:

<message> 
    <properties> 
     <property name="tracking.compositeInstanceId" value="2110209"/> 
     <property name="tracking.ecid" value="0058XKIkdpHFw00Fzzw0w00004Et005Kmk"/> 
     <property name="ws.wsu.id" value="Body-Body_tTzuB5XmRNQPR7Y7"/> 
    </properties> 
    <parts> 
     <part name="getNamesResponse"> 
      <bp:getNamesResponse> 
       <bp:OperatingName> 
        <bp:Number>123456789</bp:Number> 
        <bp:Name>Company Name, Inc.</bp:Name> 
       </bp:OperatingName> 
      </bp:getNamesResponse> 
     </part> 
    </parts> 
</message> 

Nessuna eccezione registrata. Qualcun altro ha sperimentato e risolto questo tipo di problemi?

+0

Avete controllato i log per gli errori? Weblogic ha le sue librerie XML, quindi potrebbe essere un conflitto di libreria. –

+0

Stai usando la stessa richiesta di sapone? Capisco che dovrebbe avere nuovi tag per la sicurezza (WS - Security 1.1, ecc.) E probabilmente il client interno SOA sta andando direttamente al tuo endpoint (bypassando il livello di sicurezza). – devwebcl

+0

I registri non indicano alcun tipo di errore. Il codice del client SOAP non è stato modificato, né le versioni dei componenti client come descritto sopra (rampart, ecc.). Mi sembra che SOA stia bypassando la sicurezza, quindi avremmo ottenuto un'eccezione di sicurezza. Tutto sembra funzionare da un punto di vista della sicurezza. È semplicemente l'XML di risposta che viene eliminato. – 6006604

risposta

1

Alla fine, ho risolto questo problema forzando l'applicazione ad utilizzare i file JAR che erano in bundle con l'applicazione, piuttosto che quelli forniti da WebLogic. Usando lo Classloader Analysis Tool e alcuni tentativi ed errori, ho specificato tutti i JAR che erano in bundle con l'applicazione utilizzata nella costruzione dei messaggi SOAP, e conclusi con qualcosa di simile in weblogic-application.xml:

<wls:prefer-application-packages> 
     <wls:package-name>com.ctc.wstx.*</wls:package-name> 
     <wls:package-name>javax.mail.*</wls:package-name> 
     <wls:package-name>javax.mail.event.*</wls:package-name> 
     <wls:package-name>javax.mail.internet.*</wls:package-name> 
     <wls:package-name>javax.mail.search.*</wls:package-name> 
     <wls:package-name>javax.mail.util.*</wls:package-name> 
     <wls:package-name>javax.wsdl.*</wls:package-name> 
     <wls:package-name>javax.wsdl.extensions.*</wls:package-name> 
     <wls:package-name>javax.wsdl.factory.*</wls:package-name> 
     <wls:package-name>javax.wsdl.xml.*</wls:package-name> 
     <wls:package-name>org.apache.oro.*</wls:package-name> 
     <wls:package-name>org.apache.xerces.*</wls:package-name> 
     <wls:package-name>org.apache.axiom.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.asn1.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.crypto.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.i18n.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.jce.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.math.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.mozilla.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.ocsp.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.openssl.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.util.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.voms.*</wls:package-name> 
     <wls:package-name>org.bouncycastle.x509.*</wls:package-name> 
     <wls:package-name>org.codehaus.stax2.*</wls:package-name> 
     <wls:package-name>org.jaxen.*</wls:package-name> 
     <wls:package-name>org.jaxen.dom.*</wls:package-name> 
     <wls:package-name>org.jaxen.dom4j.*</wls:package-name> 
     <wls:package-name>org.jaxen.expr.*</wls:package-name> 
     <wls:package-name>org.jaxen.function.*</wls:package-name> 
     <wls:package-name>org.jaxen.javabean.*</wls:package-name> 
     <wls:package-name>org.jaxen.jdom.*</wls:package-name> 
     <wls:package-name>org.jaxen.pattern.*</wls:package-name> 
     <wls:package-name>org.jaxen.saxpath.*</wls:package-name> 
     <wls:package-name>org.jaxen.util.*</wls:package-name> 
     <wls:package-name>org.jaxen.xom.*</wls:package-name> 
     <wls:package-name>org.slf4j.*</wls:package-name> 
     <wls:package-name>org.slf4j.helpers.*</wls:package-name> 
     <wls:package-name>org.slf4j.impl.*</wls:package-name> 
     <wls:package-name>org.slf4j.spi.*</wls:package-name> 
     <wls:package-name>org.apache.axis2.*</wls:package-name> 
     <wls:package-name>org.opensaml.*</wls:package-name> 
     <wls:package-name>org.apache.neethi.*</wls:package-name> 
    </wls:prefer-application-packages> 

Il Classloader Analysis Tool ci ha aiutato anche a identificare ed eliminare i file JAR duplicati e ridondanti, che abbiamo rimosso dal file EAR.