OSB 11g: Testing OWSM with UsernameToken Policy (oracle/wss_username_token_service_policy)

One of the quick tests I perform to make sure that I have things correctly configured is to create a test proxy that uses the basic UsernameToken as most Web Service stacks can readily generate and send this token.

OSB 11gR1 PS 7 (11.1.1.7) makes use of OWSM and one of the out of the box policies should enforce the use of UsernameToken, specifically the policy oracle/wss_username_token_service_policy. However there are a few additional steps that may need to be completed before this can be successfully tested. This article attempts to capture all of the steps.

Pre-requisites for OWSM

Firstly in order to use OWSM and its associated policies this must be enabled for the OSB domain. This is not the case by default and requires some additional configuration. Note also that the use of OWSM requires the use of a database.


1. Use the 11.1.1.7 Repository Creation Utility (RCU) to create a Database schema that the OSB domain will use. For OWSM the "Oracle AS Repository Components/AS Common Schemas/Metadata Services" schema is required however the Reporting Provider requires "Oracle AS Repository Components/SOA and BPM Infrastructure/SOA Infrastructure" schema and "Oracle AS Repository Components/SOA and BPM Infrastructure/User Messaging Service" schema

•   "Oracle AS Repository Components/AS Common Schemas/Metadata Services"

2. The domain must be created or extended with the following product options:

• Oracle Service Bus OWSM Extension
• Oracle Enterprise Manager
• Either Oracle Service Bus for developers, or
• Oracle Service Bus
• WebLogic Adavanced Web Services for JAX-RPC Extension (required by OSB)
• Oracle WSM Policy Manager (recommended by OSB OWSM)
• Oracle JRF (required by OSB)

3. During the domain creation the OWSM MDS Schema must be configured to use the Database schema that was created with the RCU.

Applying the OWSM Policy

Assuming that the per-requisites for using OWSM have been met then it should be possible to select OWSM policies from the "Security" tab of the Proxy service that should use the policy.

Clicking the "Browse" button will bring up a new window which will list all the policies that have been registered with OWSM. Select the one named "oracle/wss_username_token_service_policy".

Ensure that the Proxy Service has been saved.

Testing the Secured Proxy

Before the OSB test console can be used for the selected "oracle/wss_username_token_service_policy" policy a test credential (in this case a user name and password) must be configured in the Credential Store Framework (CSF). The OSB test console uses CSF to locate the username and password it should supply to the service.

Creating the Credential in CSF

To create the test user credential in the Credential Store Framework (CSF).

1. Open the Enterprise Manager Fusion Middleware Control (http://localhost:7001/em)

2. Navigate to the CSF page by performing the following:
a) Expand the WebLogic Domain.
b) Right Click on the domain and then select "Security/Credentials" from the resulting context menu.

3. Create the required credential.
a) Click the "Create Map" button and create a new map with the name "oracle.wsm.security". It has to be this name precisely and no other! If it already exists then this can be skipped.
b) Click the "Create Key" button and create a new key with the same name as your WebLogic administration user, typically "weblogic". Enter the following details and then click the "Ok" button:
Map = oracle.wsm.security
Type = Password
User Name =  weblogic
Password = ****** (whatever your WebLogic user's password is)

Using the CSF Credential in the Test Console

Now that a user credential has been created in the CSF we can refer to that from the OSB test console when making a call to the secured proxy.

1. Launch the OSB test console. Right-click on the proxy within OEPE and select "Run on Server". This should launch the test console within the IDE.

2. Enter whatever data you require as the payload of the request.

3. Under the "Security" section of the page specify the csf-key property of "weblogic" (or whatever you setup as the key in the CSF).

You should see the Proxy Service testing result page and in the request there should be a UsernameToken that looks something like the following:


            soap:mustUnderstand="1"
        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
       
                    wsu:Id="UsernameToken-8ApzkQ62AxhaZkMfKepvBw22"
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
           
            weblogic
                            Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">welcome1
               
       
   

OSB 11g Security - Predefined sign.xml Policy and SoapUI

I have been experimenting recently with security in Oracle Service Bus 11g. The aim of this experimentation has been to demonstrate how to apply and test various security policies - especially when OSB is an active intermediary. Whilst experimenting I have been trying to use Eviware's SoapUI as a client rather than relying on the OSB test console.

Whilst experimenting with security I decided to use the predefined WebLogic 9.2 policies to secure a service endpoint on the bus and ran into a bit of an issue when trying to configure SoapUI to adhere to the predefined "sign.xml" policy. If we look at the policy we can see that it requires that the Timestamp, Body and BinarySecurityToken (well actually system headers) to be signed:

<wsp:Policy WL5G3N0:Id="Sign.xml">
<wssp:Integrity>
 <wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
 <wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
 <wssp:Target>
  <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
  <wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
   wls:SystemHeaders()
  </wssp:MessageParts>
 </wssp:Target>
 <wssp:Target>
  <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
  <wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
   wls:SecurityHeader(wsu:Timestamp)
  </wssp:MessageParts>
 </wssp:Target>
 <wssp:Target>
  <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
  <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
 wsp:Body()
  </wssp:MessageParts>
 </wssp:Target>
 <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:TokenIssuer>CN=CACERT,OU=FOR TESTING ONLY...</wssp:TokenIssuer>
  </wssp:SecurityToken>
 </wssp:SupportedTokens>
</wssp:Integrity>
<wssp:MessageAge Age="60"/>
</wsp:Policy>

I am specifically not going to cover how to configure SoapUI for Web Service Security (WSS) profiles in this blog post as I want to focus on the issue I encountered and its solution, rather than making this post too verbose. I may add another post if there is demand and I have time but it is reasonably well covered in the SoapUI documentation.

The particular issue that I encountered was configuring SoapUI (I was using version 3.6.1) to sign all the items to match the predefined policy described above (specifically the BinarySecurityToken element).

Leaving the BinarySecurityToken unsigned gave the following SOAP fault error message:

"Could not validate signature using any of the supported token types"

However attempting to specify the Binary Security Token directly in the parts configuration resulted in SoapUI raising the following error and not performing any signing:

General security error (WSEncryptBody/WSSignEnvelope: Element to encrypt/sign not found: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd, BinarySecurityToken)], see error log for details


The solution was hinted at in this post on the OTN forums. Using Axis2 there is a "special"Token keyword which instructs the stack to encrypt the security token. This seems to be what is being used by SoapUI as if this is added as though it is an element to the configuration then this then works.

In the outgoing WSS configuration I needed the following WSS entries:

• Timestamp


• Signature
  
  
  
  • Keystore: <keystore.jks>
  
  
  • Alias: <alias>
  
  
  • Password: <password>
  
  
  • Key Identifier Type: Binary Security Token
  
  
  • Signature Algorithm: http://www.w3.org/2009/09/xmldsig#rsa-sha1
  
  
  • Signature Canonicalization: http://www.w3.org/2001/10/xml-exc-c14n#
  
  
  • Parts
    
    
    
    • Name: Body, Namespace: http://schemas.xmlsoap.org/soap/envelope/
    
    
    • Name: Timestamp, Namespace: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
    
    
    • Name: Token
    
    

Screenshot of SoapUI with the correct outbound WSS configuration applied.

I hope this helps anyone who has been fighting with using SoapUI with the predefined WLS 9.2 Sign policy in either Oracle Service Bus or straight WLS web services.