Quantcast
Channel: Security – J@n van Zoggel
Viewing all articles
Browse latest Browse all 19

Oracle Service Bus and Siebel UserNameToken

$
0
0

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>

Attach the policy to the OSB business service together with the service account and go !!! 
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>

Bummer, we get our 1st error. Well let’s say that good things always take some extra effort.
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>

The error might let you think that Siebel simply fails on the mustUnderstand attribute which would force it to understand the SOAP header. However this is not the whole case.

After some debugging and using the Assign action in the OSB to manually build the SOAP-header with the WS-security definition it was possible to send out a UserName token Siebel accepted.

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&#8221; while the OSB uses the newer namespace http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&#8221; 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


Viewing all articles
Browse latest Browse all 19