I've been asked to investigate a problem with secured web services on OSB. These services were working fine until OSB was upgraded to 126.96.36.199.0 (from 188.8.131.52.0). All the services use custom WLS 9 policies requiring X.509 authentication. Now, I've already spent some time on this and have been able to reduce the problem to the following situation:
1) take any service (the simplest service you can make in OSB, eg. a simple echo service or something like that)
2) create the following custom policy and apply it to the service you made in 1 (add it as a Request Policy on an operation for example):
<?xml version="1.0" encoding="UTF-8"?> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wssp="http://www.bea.com/wls90/security/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="X509TokenIdentificationWOTokenSignature-2.00"> <wssp:Identity> <wssp:SupportedTokens> <wssp:SecurityToken IncludeInMessage="true" TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" /> </wssp:SupportedTokens> </wssp:Identity> </wsp:Policy>
3) Assuming you have setup WLS correctly as far as keystores and such is concerned, create a Service Provider so that you can use it to call the service from the OSB console
4) Unfortunately, I get the following response in my console:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <env:Fault> <faultcode>env:Server</faultcode> <faultstring>Unknown exception, internal system processing error.</faultstring> </env:Fault> </env:Body> </env:Envelope>
And in my console I find the following:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header/><env:Body><env:Fault><faultcode>env:Server</faultcode><faultstring>Unknown exception, internal system processing error.</faultstring></env:Fault></env:Body></env:Envelope> weblogic.xml.crypto.wss.WSSecurityException: Unknown exception, internal system processing error. at weblogic.wsee.security.WssHandler.handleRequest(WssHandler.java:95) at com.bea.wli.sb.security.wss.wls.Wls92InboundHandler.processRequest(Wls92InboundHandler.java:164) at com.bea.wli.sb.security.wss.WssHandlerImpl.doInboundRequest(WssHandlerImpl.java:228) at com.bea.wli.sb.context.BindingLayerImpl.addRequest(BindingLayerImpl.java:291) at com.bea.wli.sb.pipeline.MessageProcessor.processRequest(MessageProcessor.java:92) Truncated. see log file for complete stacktrace >
Any ideas what could be going on? I already experimented a bit myself and have succesfully enabled X.509 using the standard Auth and Sign policies and it also works without any problem using OWSM policies (and, yeah, there are plans to migrate to OWSM policies in the near future but in the meantime we need to make do with these custom WLS 9 policies).
After research by Oracle Support it actually turns out that this problem was a combination of factors:
1) some clients were effectively using an invalid certificate so it is corrrect they got an error and everything worked fine when they started using the right certificate
2) it does, however, turn out that, in the case of an error the error handling has been obfuscated in WLS 10.3.6 as compared to WLS 10.3.4 which gives a more descriptive error stating the nature of the problem (missing certificate, invalid certificate, unknown user, ...). Apparently this was deemed a security issue and has thus been replaced by a generic "internal server error". It is however possible to re-activate this older behaviour using a couple of JAVA_OPTS that you pass during server startup:
The above reintroduced the behaviour we had in WLS 10.3.4 and thus solves our problem!