In this case we need to publish messages from the OSB 10.3.1 to Siebel 8.1.1.2 where Siebel supports different options for authentication of incoming HTTP webservice requests.
- passing the user name and password in the URL (basic authentication)
- A sort of custom Siebel Soap Header token like:
<soap:Header> <UsernameToken xmlns="http://siebel.com/webservices">user</UsernameToken> <PasswordText xmlns="http://siebel.com/webservices">hello123</PasswordText> <SessionType xmlns="http://siebel.com/webservices">None</SessionType> </soap:Header>
- And last but not least; Siebel claims to support the WS-Security UserName Token mechanism. However Siebel only supports the PasswordText option so the password will still be send in clear text.
We concluded that the URL or the custom header option was not acceptable due to the customers security requirements. The only acceptable solution for them would be the WS-security UsernameToken. Within the OSB this can be arranged by using a WS-policy and a Service Account and connect them to the outgoing business service. Since the password will still be in cleartext, we will use SSL to protect the password on it’s journey over the dark trenches of our WAN.
So here we start off:
1st the Siebel configuration for inbound services. Make sure the authentication type is set to username/password clear text.
2nd the WS-policy used (very basic):
<wsp:Policy wsu:Id="WS-Policy-Siebel" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wssp:Identity xmlns:wssp="http://www.bea.com/wls90/security/policy"> <wssp:SupportedTokens> <wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken"> <wssp:UsePassword Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"/> </wssp:SecurityToken> </wssp:SupportedTokens> </wssp:Identity> </wsp:Policy>
With tcpmon we catch the SOAP-header and it looks like:
<soapenv:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1"> <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="unt_hzo9Xh2IiCqSYGaH"> <wsse:Username>SADMIN</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">SADMIN</wsse:Password> </wsse:UsernameToken> </wsse:Security> </soapenv:Header>
The error response from Siebel:
<Body> <Fault> <faultcode>SOAP-ENV:MustUnderstand</faultcode> <faultstring>Unable to process SOAP Header child element 'wsse:Security' with 'mustUnderstand="1"'((SBL-EAI-08000)</faultstring> <detail> <siebelf:siebdetail xmlns:siebelf="http://www.siebel.com/ws/fault"> <siebelf:logfilename>EAIObjMgr_nld_0014_14680077.log</siebelf:logfilename> <siebelf:errorstack> <siebelf:error> <siebelf:errorcode>SBL-EAI-08000</siebelf:errorcode> <siebelf:errorsymbol/> <siebelf:errormsg>Unable to process SOAP Header child element 'wsse:Security' with 'mustUnderstand="1"'((SBL-EAI-08000)</siebelf:errormsg> </siebelf:error> </siebelf:errorstack> </siebelf:siebdetail> </detail> </Fault> </Body>
After this my conclusion is that Siebel apparently expects another wsse namespace then the OSB is generating.
Siebel requires the old wsse IBM/Microsoft/VeriSign definition of “http://schemas.xmlsoap.org/ws/2002/04/secext” while the OSB uses the newer namespace “http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd” which was changed to match the OASIS specifications after their approval of WS-security as a standard in 2004.
After contact with Oracle Support I received confirmation from the Siebel Team that this is a limitation from Siebel, as it is not accepting the latest WS-Security definition. The option they give you is that for now it’s the caller’s responsibility to change the header to conform to the namespace Siebel is expecting.
So a new challenge for the OSB. The project looks something like this:
The solution for it is the fn-bea:lookupBasicCredentials function. We use an Assign Action to get the expression
fn-bea:lookupBasicCredentials(‘myRubixProject/security/SA.Siebel.MyRubixProject’)
result in a variable named $varBasicCredentials with the following content:
<con:UsernamePasswordCredential xmlns:con="http://www.bea.com/wli/sb/services/security/config"> <con:username>SADMIN</con:username> <con:password>SADMIN</con:password> </con:UsernamePasswordCredential></pre> We edit the Replace action to use the username and password elements. <pre class="brush: xml"><soapenv:Header xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" soapenv:mustUnderstand="1"> <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsse:Username>{$varBasicCredentials/con:username/text()}</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{$varBasicCredentials/con:password/text()}</wsse:Password> </wsse:UsernameToken> </wsse:Security> </soapenv:Header>
Don’t forget to add the con namespace to the Replace action.
Finally, succes at last !!! :)
Off course this is just a workaround to make sure that Siebel and OSB speak te same “namespace language”. Let’s hope that Siebel 11g fixes this. After all, when it runs on Weblogic it must be good ;-)
Special thanks to Anuj Dwivedi for pointing me out the posibilities of the fn-bea:lookupBasicCredentials function