Advertisements
RSS

Category Archives: WS-Security

Using UserName information in the Oracle Service Bus

I was debugging a OSB 11.1.1.5 proxy service which had a OWSM UserName token policy attached to it (read this blogpost how to configure your OSB). When I noticed the $inbound variable had some interesting information which I never noticed before.

The $inbound variable holds a big data-set regarding transport and usually a small data-set regarding security. In a “normal” unsecured proxy services this would result in something like this:

<inbound>
 <con:endpoint name="mySomething" xmlns:con="http://www.bea.com/wli/sb/context">
 <con:service>
 <con:operation>getEmployeeDetails</con:operation>
 </con:service>
<con:transport>
........
</con:transport>
 <con:security>
 <con:transportClient>
 <con:username>anonymous></con:username>
 </con:transportClient>
 </con:security>
 </con:endpoint>
</inbound>

So there is just a transportClient reference which normally just contains the value “anonymous”. Not really interesting.

However in the situation where the proxy service uses the OWSM policy it contains a new messageLevelClient element:

<inbound>
 <con:endpoint name="mySomething" xmlns:con="http://www.bea.com/wli/sb/context">
 <con:service>
 <con:operation>getEmployeeDetails</con:operation>
 </con:service>
<con:transport>
........
</con:transport>
 <con:security>
 <con:transportClient>
 <con:username>anonymous></con:username>
 </con:transportClient>
 <con:messageLevelClient>
 <con:username>weblogic</con:username>
 <con:principals>
 <con:group>AdminChannelUsers</con:group>
 <con:group>Administrators</con:group>
 <con:group>IntegrationAdministrators</con:group>
 </con:principals>
 </con:messageLevelClient>
 </con:security>
 </con:endpoint>
</inbound>

Pretty good information for tracing/logging your service calls.

Advertisements
 
1 Comment

Posted by on 13-01-2012 in OSB, Security, WS-Security

 

Tags: , , ,

Using OWSM UsernameToken for authentication and authorisation of OSB services

With the use of Oracle Web Service Manager (OWSM) we can easily configure Oracle Service Bus (OSB) services with different message security polices. This configuration can be done from Eclipse (OEPE), OSB SBConsole or the Enterprise Manager. One of the most common WS-Security mechanismes and therefor also OWSM policies is the UsernameToken where a username and password are send along with the message.

In this blog we will:

  • part I: how to enable authentication of users against the list of all known users
  • part II: how to enable authorisation of only a specific subset of users to access a service

First we configure a proxy service in OEPE with the OWSM UsernameToken policy oracle/wss_username_token_service_policy:


And make sure we process the WS-Security header:


After deployment we call the service with a request that is missing the WS-Security to test the result.


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <GreetingRequestMessage>
         <in>I say hello ...</in>
      <GreetingRequestMessage>
   </soapenv:Body>
</soapenv:Envelope>

As expected the result is an error because the OWSM policy requires a WS-Security segment in the SOAP-header which contains a username and password:


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>soapenv:Server</faultcode>
         <faultstring>BEA-386200: General web service security error</faultstring>
         <detail>
            <con:fault xmlns:con="http://www.bea.com/wli/sb/context">
               <con:errorCode>BEA-386200</con:errorCode>
               <con:reason>General web service security error</con:reason>
               <con:location>
                  <con:path>request-pipeline</con:path>
               </con:location>
            </con:fault>
         </detail>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

So to make sure we can send a UsernameToken we add 2 users to the Weblogic security realm called userA and userB.

The request to the proxy service containing the WS-Security UsernameToken for userA


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-4" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>userA</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">welcomeA1</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <GreetingRequestMessage>
         <in>I say hello ...</in>
      </GreetingRequestMessage>
   </soapenv:Body>
</soapenv:Envelope>

This results in a successfull response from the proxy service:


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <GreetingResponseMessage>
         <out>HelloWorld</out>
      </GreetingResponseMessage>
   </soapenv:Body>
</soapenv:Envelope>

So part 1 is complete, we succesfully implemented a proxy service that requires a WS-Security UsernameToken and authenticates these users against the Weblogic security realm. But in our case we have a tight security requirement and need to make sure the user is not only authenticated, but also authorized to access this specific service.

The result from part 1 means this is not the case, both userA and userB would be able to access this service. So let’s start part 2 where we will limit the access to the proxy service to only userB. For this we have to login to the sbconsole, since the OEPE does not allow you to make Message (or Transport) Access Control settings.

  • Login the sbconsole
  • Select Project Explorer
  • Select the the proxy service
  • Go to the Security Tab

  • Click on Message Access Control option (either for the whole service or just a single operation).
  • Click on Add Condition
  • Select User from predicate list
  • Type userB at the User Argument Name
  • Click on Add and Finish
  • Click on Save and Activate to finish the OSB session
Next thing we can call the service again and this time with userB and we still receive a succesfull result.
However if we call the service again with a UsernameToken containing userA we get the following SoapFault:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>soapenv:Server</faultcode>
         <faultstring>BEA-386102: Message-level authorization denied</faultstring>
         <detail>
            <con:fault xmlns:con="http://www.bea.com/wli/sb/context">
               <con:errorCode>BEA-386102</con:errorCode>
               <con:reason>Message-level authorization denied</con:reason>
               <con:location>
                  <con:path>request-pipeline</con:path>
               </con:location>
            </con:fault>
         </detail>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

Part 2 is completed and we finished with a proxy service that has both Authentication and Authorization enabled.

Remarks:

  • You can also use groups and roles (rather than users) to authorize access to services.
  • If you implement and configure an external LDAP (like Oracle Internet Directory) in Weblogic you can control ACL with groups central in your company LDAP instead of in each Weblogic security realm.
  • The SOAP fault for Message Level Authorization denied (BEA-386102) contains a faultcode value of “Server” which is not correct if you look at the w3c definition. This should be the value “Client” because: “….. the message could lack the proper authentication or payment information. It is generally an indication that the message should not be resent without change”

Update 2011-08-10:
Added 3rd remark regarding the SOAP Fault code

Update 2012-01-13:
Using the OWSM username token policies you get some additional information on runtime in you $inbound variable. See this blogpost for more details.
References:


 
26 Comments

Posted by on 09-08-2011 in OSB, WS-Security

 

Tags: , , ,

Oracle Service Bus and Siebel UserNameToken

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

 
Leave a comment

Posted by on 01-04-2010 in Oracle, OSB, Siebel, WS-Security, XQuery

 

Tags: , , ,