Oracle Enterprise Gateway: Integration with Oracle Service Bus and Oracle Web Services Manager

by William Markito Oliveira and Fabio Mazanatti

Providing a secure environment for your Web Services

Published March 2012


Summary

Oracle Enterprise Gateway (OEG) and Oracle Web Services Manager (OWSM) are two central points of a SOA initiative when security is paramount. This article describes how to integrate these products with Oracle Service Bus (OSB), providing a secure environment for your Web Services. Although these products can do a lot more, the focus of this article is on authentication, a pressing concern when securing exposed services.

Requirements


This article assumes the reader has knowledge in the following areas:

  • Java and Web Services
  • Basic Oracle Service Bus Knowledge
  • Basic Oracle WebLogic Server Administration

You will also need:

  • An Oracle Service Bus domain with OWSM Extension and Enterprise Manager up and running:

Figure 00

You may use Oracle SOA Suite's virtual machine (Pre-built Virtual Machine for SOA Suite and BPM Suite 11g) to save some time. In this case, you'll have to install Oracle Enterprise Gateway and Oracle Service Bus, creating a new Service Bus domain with the configuration mentioned above.

If you want to set up a brand new Oracle SOA Suite installation, follow the instructions in the Oracle SOA Suite Quick Start Guide document, then install OSB and configure a new domain as instructed. You can use the Oracle Service Bus for Developers option for this step (screenshot above) in order to save some memory and CPU (the Developer option creates only one server instead of an Admin plus a Managed server).

Oracle Enterprise Gateway


Introduction

Oracle Enterprise Gateway is designed to secure SOA deployments across domain boundaries and, more specifically, web services calls going over wide-area networks. It does this by providing an easy way to secure (authenticate, introspect, etc.) and accelerate XML and other types of data. Oracle Enterprise Gateway offers rich integration with many identity and access management platforms and, more specifically, Oracle Identity Management solutions.

Installation and Start-up

The procedure to install OEG is pretty straight-forward: create the folder on which you want the product to be installed and unzip the installation file there:


m@anakin:/oracle/$ mkdir oeg11.1.1.5
m@anakin:/oracle/$ cd oeg11.1.1.5
m@anakin:/oracle/oeg11.1.1.5$ unzip /tmp/ofm_oeg_linux_11.1.1.5.0_disk1_1of1.zip
Archive: ofm_oeg_linux_11.1.1.5.0_disk1_1of1.zip
creating: Linux/
creating: Linux/32bit/
inflating: Linux/32bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.i386.tar.gz
inflating: Linux/32bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.i386_Policy_Center.tar.gz
inflating: Linux/32bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.i386_Policy_Studio.tar.gz
inflating: Linux/32bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.i386_Service_Explorer.tar.gz
inflating: Linux/32bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.i386_Service_Monitor.tar.gz
inflating: Linux/32bit/quickstart.txt
inflating: Linux/32bit/readme.txt
creating: Linux/64bit/
inflating: Linux/64bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64.tar.gz
inflating: Linux/64bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64_Policy_Center.tar.gz
inflating: Linux/64bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64_Policy_Studio.tar.gz
inflating: Linux/64bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64_Service_Explorer.tar.gz
inflating: Linux/64bit/Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64_Service_Monitor.tar.gz
inflating: Linux/64bit/quickstart.txt
inflating: Linux/64bit/readme.txt

This article uses the Linux 64-bit flavor, so we're going to unpack the files related to it:


m@anakin:/oracle/oeg11.1.1.5$ cd ./Linux/64bit/
m@anakin:/oracle/oeg11.1.1.5/Linux/64bit$ ls -h
Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64_Policy_Center.tar.gz
Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64_Policy_Studio.tar.gz
Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64_Service_Explorer.tar.gz
Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64_Service_Monitor.tar.gz
Oracle_Enterprise_Gateway_11_1_1_5_0_Linux.x86_64.tar.gz
quickstart.txt
readme.txt
m@anakin:/oracle/oeg11.1.1.5/Linux/64bit$ for a in `ls -1 *.tar.gz`; do tar -zxvf $a; done

The last command unpacks all modules at the current folder, creating a subfolder for each module. To check the final result:


m@anakin:/oracle/oeg11.1.1.5/Linux/64bit$ find -maxdepth 1 -type d
.
./oegpolicystudio
./oegpolicycenter
./oegservicemonitor
./oegserviceexplorer
./enterprisegateway

That's it, the installation is done.

Now, you'll need the following components of OEG running:

  • Enterprise Gateway
  • Policy Studio
  • Service Explorer

So, issue the respective commands from your terminal:


m@anakin:/oracle/oeg11.1.1.5/Linux/64bit$ ./enterprisegateway/posix/bin/enterprisegateway &
m@anakin:/oracle/oeg11.1.1.5/Linux/64bit$ ./oegpolicystudio/policystudio &
m@anakin:/oracle/oeg11.1.1.5/Linux/64bit$ ./oegserviceexplorer/serviceexplorer &

After issuing the commands, you can reach the Enterprise Gateway Administration interface accessing through a browser: http://localhost:8090/. You will be asked for username and password, which by default are admin/changeme respectively.


Figure 1
Figure 1 - Oracle Enterprise Gateway - Management Interface

Oracle Service Bus

Oracle Service Bus virtualizes services in integration architecture, transforming complex and brittle architectures into agile integration networks by connecting, mediating, and managing interactions between service consumers and back end applications.

Set-Up

As previously mentioned, we're going to use a Bus domain with OWSM Extension and Enterprise Manager enabled:


Figure 2
Figure 2 - Oracle Service Bus - Domain requirements

If you haven't done it yet, start your Service Bus domain and log in to Service Bus Console (/sbconsole) to import the base project.

  1. Download the jar file sbconfig-Customer-INIT.jar to a local folder.
  2. Navigate to System Administration on Service Bus console.
  3. Start a new change session by clicking on Create at the top left corner.
  4. Under Import Resources, choose the downloaded file and click Next>>. A list of resources will be presented. Click on Import, and a confirmation will show:

Figure 3
Figure 3 - Oracle Service Bus - Resource Import

  1. Activate the session.
  2. Browse to Project Explorer and under Projects, and expand the Customer project.
  3. Now let's execute a quick check to make sure our service is up and running by clicking on Launch Test Console:

Figure 4
Figure 4 - Oracle Service Bus - Execute a Proxy Service

  1. In the Payload field of Test Console, paste the following:

<cus:getCustomer xmlns:cus="http://customer.ws.examples.oracle.com/">
   <arg0>1</arg0>
</cus:getCustomer>

  1. Leave the other attributes with their default values. Click Execute. The expected result:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   </soap:Header>
   <soapenv:Body>
      <cus:getCustomerResponse xmlns:cus="http://customer.ws.examples.oracle.com/">
         <!--Optional:-->
         <return xmlns:cus="http://www.example.org/Customer">
            <cus:id>1</cus:id>
            <cus:firstname>Customer1</cus:firstname>
            <cus:lastname>Lastname1</cus:lastname>
            <cus:address>
               <cus:street>One Streeth</cus:street>
               <cus:country>One Country</cus:country>
               <cus:city>One City</cus:city>
            </cus:address>
         </return>
      </cus:getCustomerResponse>
   </soapenv:Body>
</soapenv:Envelope>

Business Scenario

In this scenario, a company has an ongoing SOA approach, with several services already deployed and being used in production, with access restricted to internal consumers only, and there are no security requirements implemented.

The Weblogic instance on which OSB is running uses its default internal security provider (an embedded LDAP), since only basic administration console authentication/authorization is needed.

The Customer service we created above is one of the interfaces exposed by Oracle Service Bus. So, the basic access diagram is as follows:


[FILENAME]
Figure 5 - Business Scenario

But now a new requirement has come up: some of these services must be exposed to our partners, using a standard Internet link. To be allowed to do so, the Security Officer requested that all external interfaces must implement some kind of access enforcement. And, since we're on the subject, there is also a demand that even internal interfaces must authenticate users. So our internal clients will have to change their calls accordingly. Since we're talking about system-to-system access inside an intranet, just ensuring that the caller is a "known system" is good enough for now. This characterizes a common scenario, usually called "system-to-system authentication," in which each system has security principles.

One last detail: upon receiving a request from a partner, authentication must carry out at the network perimeter in the DMZ, filtering out invalid requests. The user store we're going to query is segregated from the corporate store, in order to show how credential replacement is done. In real-world scenarios, usually the user store is unified.

To accomplish this, we're going to use Oracle Service Bus tight integration with OWSM (the default security solution for Oracle Fusion Middleware), with OEG acting as an external proxy for partner requests:


Figure 6
Figure 6 - Solution Architecture

We will implement the business scenario via the following actions:

  1. Expose the current Customer service from Oracle Enterprise Gateway, as is (no security)
  2. Attach an OWSM policy to the Service Bus endpoint
  3. Create a custom policy at Oracle Enterprise Gateway to cope with OWSM's policy
  4. Add user authentication to OEG's exposed interface

OEG can do a lot more than just authenticate a request, including filtering requests for known threats (e.g. Denial of Service, SQL injection, scan attachments for virus) and advanced routing. However, those features are beyond the scope of this article.

Registering a Web Service on Oracle Enterprise Gateway

With this step we will register the OSB service on OEG, ensuring that the connectivity between OSB and OEG is working and exposing the service through OEG as well. We're not going to attach any security policies yet.

This section describes the basic steps to register a Web Service on OEG. For more information, please check the official documentation.

Assuming that both Service Bus and OEG are up and running as previously instructed, complete the following steps:

  1. Go to the Policy Studio application
  2. Click on Enterprise Gateway - localhost
  3. In the Open Connection window, click OK
  4. The OEG Dashboard will be displayed. Click the Edit Active Configuration, then click OK, leaving the Passphrase field empty. The configuration view for the selected OEG instance is presented:

Figure 7
Figure 7 - Enterprise Gateway Instance Configuration

The left panel contains several items that represent the functionalities of OEG. At this point we only need to register a new Service in the Web Service Repository.

  1. Click the Policies item at the left panel
  2. Expand Web Service Repository:

Figure 8
Figure 8 - Web Service Repository

  1. Left click Web Services and select Register a Web Service. An Import WSDL window will display
  2. Select WSDL URL and paste in the following URL: http://localhost:7001/Customer/CustomerService?WSDL (change the port number to reflect your installation)
  3. Click Next and select operation getCustomer. Click Next, then Next again.
  4. Select Default Services to set the location where our Web Service will be exposed:

Figure 9
Figure 9 - Enterprise Gateway - Service Deployment

  1. Click Finish, then click OK in the next screen. (We're not setting security for this service right now, so OEG will only act as a proxy to our Service Bus endpoint)
  2. A Summary screen will display. Make sure that the WSDL Access Option is checked (as shown in Figure 10) showed by the screenshot below), otherwise OEG will not expose the WSDL of the service to clients (this strategy can be used for enhanced service security, as part of a governance effort):

Figure 10
Figure 10 - Enterprise Gateway - Service Deployment Summary

In the Services option in the left panel you should see the newly created CustomerService interface, under Default Services. Before testing it, we need to deploy the changes to the Enterprise Gateway server. This can be done by clicking the Deploy icon at the top right corner or by hitting F6 on your keyboard:


Figure 11
Figure 11 - Enterprise Gateway - Deployment icon

When the deploy process ends, access http://localhost:8080/Customer/CustomerService?WSDL from a web browser and confirm that the same WSDL we have on OSB is now exposed under OEG.

Calling the Web Service Using Service Explorer

Now, let's test service we just exposed from OEG. To do so, we're going to use OEG's Service Explorer.

Service Explorer is a Web Services test client, which is used to generate test messages that are sent to the Enterprise Gateway and back to Service Explorer. Service Explorer supports both SOAP-based and REST-based invocations, includes support for multiple security scenarios (transport or message level), and is capable of generating stress tests and executing test cases scenarios.

To call the service, complete the following steps in Service Explorer:

  1. Click the pointer at the right of the green arrow (execute) button and select Request Settings...:

Figure 12
Figure 12 - Service Explorer

  1. In the request settings window, click the Add Request button and paste in the URL of the service registered on OEG (http://localhost:8080/Customer/CustomerService). Uncheck Request name matches URL, enter CustomerService as the Request Name, and then click OK.
  2. Copy and paste the following text at the Body Content box:
<?xml version="1.0"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
 <env:Header />
  <env:Body>
   <cus:getCustomer xmlns:cus="http://customer.ws.examples.oracle.com/">
    <arg0>1</arg0>
   </cus:getCustomer>
  </env:Body>
</env:Envelope>

  1. Optionally, enter the service's WSDL location: http://localhost:8080/Customer/CustomerService?WSDL
  2. Here's the final configuration of your request:

Figure 13
Figure 13 - Service Explorer - Request Settings

  1. Click Run. The window will close. The response from the Oracle Service Bus Test Client will display in the Response field of the main window (Figure 14).

Figure 14
Figure 14 - Service Explorer - Calling a Web Service without Security

At this point we have a simple web service published in OSB and exposed through OEG with no security attached. The next steps will add it to both interfaces of the service – first the internal endpoint, exposed by Service Bus, then the public one, published by OEG.

Note: As an alternative, you can let Service Explorer create Request settings based on the WSDL. The process is described in the following steps:

  1. With Service Explorer running, click on File and select Import WSDL

Figure 15Figure 15 - Service Explorer - Import WSDL

  1. Select the WSDL URL option and paste in the end-point URL, as illustrated below:

Figure 16
Figure 16 - Service Explorer - Load WSDL location

  1. Click Next and mark the appropriate checkbox to select the operation that should generate the request.

Figure 17
Figure 17 - Service Explorer - Select WSDL Operations

  1. Click Finish to generate the request.

Adding Security to Oracle Service Bus with Oracle Web Services Manager

Oracle Web Services Manager allows the definition and storage of declarative policies to be applied to web services, enabling enforcement and monitoring of security, management and audit policies through configurable agents.

Web Services security has multiple facets (Authentication, Authorization, Confidentiality, Integrity), each with its own standards, which can be defined as service policies, or just plain policies. For this business scenario we will use a simple WS-Security Username/Token policy to enforce that only a user known by our system will be able to execute the service endpoint. In order to do that, we will use the default user from the Weblogic domain.

For more details about using different Realms or setting up LDAP or other Authentication Providers, please check the references at the end of this article.

In order to apply an OWSM policy to our CustomerService, execute the following steps in the OSB console:

  1. On the left ribbon, select Project Explorer and click the Customer project
  2. Click on the CustomerService proxy name and load the Policies tab
  3. Create a new change session by clicking Create in the Change Center box (top left corner)
  4. Select From OWSM Policy Store and click Add
  5. On the Select OWSM Policy window, search for oracle/wss_username_token_service_policy (usually found at page 2) and select it:

Figure 18
Figure 18 - Service Bus - Policy Explorer

  1. Click "Update". Don't forget this step, otherwise Service Bus will not apply the policy
  2. Activate your session in Change Center
  3. Now try to execute the service using Service Bus Test client with the payload below. It's the same payload from previous steps with added WS-Security headers. Remember to change the username and password fields to reflect the credentials of your domain's admin user:

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Header>
      <wsse:Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd"
 xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-
1.0.xsd">
         <wsse:UsernameToken>
            <Username>weblogic</Username>
            <Password>welcome1</Password>
         </wsse:UsernameToken>
      </wsse:Security>
  </env:Header>
  <env:Body>
   <cus:getCustomer xmlns:cus="http://customer.ws.examples.oracle.com/">
    <arg0>1</arg0>
   </cus:getCustomer>
  </env:Body>
</env:Envelope>

  1. If you get the following error message...

    [OSB Security - OWSM:387253]Failed to initialize Owsm Credential Manager. Please validate the Keystore Configuration.
    ...keep reading this section to setup an OWSM keystore.

    However, if you received the correct response, please jump ahead to the next section.

The error message shown above indicates that you didn't set up the keystore for this OWSM/Weblogic domain. You can do this through the Java keytool command-line application, but we'd like to show you a very nice alternative, using OEG's Service Explorer to create a new keystore and a certificate. From this GUI you can open an existing keystore to check, add and change its entries.

Using Service Explorer, follow these steps:

  1. At the top menu, select Security → View Certificates
  2. In the popup window, click the Create/Import button. Here you can create your certificate, sign it, and import or export key pairs:

Figure 19
Figure 19 - Enterprise Gateway - Configure Certificates and Keys

  1. First, we're going to edit the subject field. Click Edit..., fill the information as illustrated in Figure 20, below. Then click OK.

Figure 20
Figure 20 - Edit Certificate Information

  1. In the Alias Name field, type test
  2. Click on Sign Certificate.... Click Yes in the self-sign confirmation and Yes to generate a key-pair. Then click OK to close the Configure Certificate window. The new certificate is the last entry in the list
  3. Now click on Keystore and then on New keystore. This will prompt for the location in which you want to save it. Choose a folder to which Weblogic Server has access, and write down this path – you'll need this information later. For the file name, type test.jks
  4. The keystore password window will open. Type in any password you want for the keystore. (For the purposes of this article we will use oracle.)
  5. Now let's add your key-pair to your brand new keystore. Click Add to keystore, select the key you just created, then click OK.
  6. Enter a password for this alias. We will use oracle again. You should see your alias listed under the keystore, as illustrate in Figure 21.

Figure 21
Figure 21 - Enterprise Gateway - Keystore View

  1. Close the Keystore and Select Certificate windows, but leave Service Explorer running.

Now we have a properly configured keystore, but we still have to set it up in Weblogic or, more precisely, in Web Services Manager's Security Provider. This keystore is used to store public and private keys for SOAP messages within the Weblogic domain.

  1. Open the Enterprise Manager console (http://localhost:7001/em)
  2. Under the navigator pane, expand Weblogic Domain, right-click on your domain name, select Security and then Security Provider Configuration (see Figure 22).

Figure 22
Figure 22 - Enterprise Manager - Security Provider Configuration

  1. Expand the Keystore section of the page by clicking the "+" sign, then click the Configure button
  2. On the Keystore Configuration page, fill the following fields as indicated below:
    1. Keystore path: /location/of/your/test.jks [the path/filename you chose in step 6, above]
    2. Password: oracle [or the password you chose in step 7]
    3. Confirm Password: oracle
    4. Key Alias: test [or the alias you entered in step 4]
    5. Signature Password: oracle [or the password you chose in step 9]
    6. Confirm Password: oracle
    7. Crypt Alias: test [or any other name you like]
    8. Crypt Password: oracle [or another password you like]
    9. Confirm Password: repeat the value
  3. Click OK to confirm your changes
  4. Restart your Weblogic domain.

After the server startup procedure ends, we have to create the credential to be used by the Service Bus Test Console to validate our configuration:

  1. Open Enterprise Manager console (http://localhost:7001/em)
  2. Under the navigator pane, expand Weblogic Domain, right-click your domain name, select Security, then Credentials
  3. Click the Create Key and enter the following:
    1. Key: basic.credentials
    2. User Name: weblogic (change it to reflect your environment - must be a valid user)
    3. Password: welcome1 (change it to reflect your environment)
    4. Confirm Password: same as above (see Figure 23)

[FILENAME]
Figure 23 - Enterprise Manager - Key Configuration

  1. Click OK.

Now that we have configured our keystore and credentials, login to sbconsole and test the CustomerService again with Service Bus Test Console. The payload is the same as before:


<?xml version="1.0"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Header />
  <env:Body>
   <cus:getCustomer xmlns:cus="http://customer.ws.examples.oracle.com/">
    <arg0>1</arg0>
   </cus:getCustomer>
  </env:Body>
</env:Envelope>

Since we have already created the basic.credentials key, we don't need to pass any security information when using the Test Console – this is done automatically. As shown in Figure 24, the Security section references the key we just created by default.


Figure 24
Figure 24 - Service Bus - Test Console and Security Settings

The response will now display the expected business data.

Change Service Explorer to Call OSB with a Security Token

Now we need to call our protected service on OSB from Service Explorer. Let's explore the tool and see how easy it is to add security tokens to service calls.

  1. We have to change the previously created service request, so go to Service Explorer's window and click the pointer at the right of the green arrow (execute) button, then select Request Settings...
  2. Select the CustomerService entry in the left panel. Modify the URL of this entry by replacing the URL field value to contact Service Bus directly, rather than OEG:
    1. Replace: http://localhost:8080/Customer/CustomerService
    2. With: http://localhost:7001/Customer/CustomerService
  3. If you entered the WSDL earlier, adjust it accordingly. The configuration should match the information in Figure 25.

[igure 25
Figure 25 - Service Explorer - Adjust Request Settings

  1. Click Close
  2. In the main menu, select Security, then Insert WS-Security Username Token, and change the following fields:
    1. User name: weblogic
    2. Include Nonce: uncheck
    3. Include Password: check
    4. Password: welcome1 (must select the Password option, not Wildcard)
    5. Cleartext: check
    6. Click Finish.

Figure 26
Figure 26 - Service Explorer - Insert WS-Security Username and Token

Now we're ready to go. Press the green arrow (execute) button and you will see the request output, authorized by Service Bus/OWSM, running on Weblogic.

Note: We're using the weblogic user for the sake of simplicity. In real world scenarios, please consider using an LDAP repository, a database, or Oracle Access Manager or a similar Identity Management product.

In the next section we will set up OEG to automatically add these authentication credentials to a service request using a Custom Policy. This strategy will allow OEG to call an OSB-protected endpoint.

Create an OEG Custom Policy for Systemic Authentication

The policy we created at OEG does not know that the WSDL exposed by Service Bus now requires a WS-Security token. Figure 27a, below, illustrates the WSDL exposed by Oracle Enterprise Gateway, while Figure 27b illustrates the WSDL exposed by Oracle Service Bus, and highlights the new WS-Security Policy.


Figure 27a
Figure 27a - Oracle Enterprise Gateway WSDL

Figure 27b
Figure 27b - Oracle Service Bus WSDL

So, we now need to update the service policy in order to send a user/password header on every request. This way, the calls going through OEG will work as expected.

  1. Open Policy Studio
  2. Click the Policies item in the left panel. Expand Generated Circuits, then expand Web Services.CustomerService, then expand /Customer/CustomerService, and click Service Handler for 'CustomerService':

[Figure 28
Figure 28 - Policy Studio - Service Handler for CustomerService

  1. Now you have the policy editor open, with several filters at your right, grouped by category. Enter token in the filter field (at the top of the filters list), then click the Authentication group and select the Insert WS-Security Username Token action:

Figure 29
Figure 29 - Policy Editor and Filters

  1. Now, drag-n-drop the "Insert WS-Security Username Token" action into the blue area of the editor.
  2. A configuration window will pop up. Fill the fields with the following information (same information as used in step 4 of the previous section):
    1. User name: weblogic
    2. Include Nonce: uncheck
    3. Include Password: check
    4. Password: welcome1 (must select the Password option, not Wildcard)
    5. Cleartext: check
    6. Click Finish.
  3. Right-click the Insert WS-Security Username Token node created in the canvas and select Set as Start.
  4. Click Success Path (the green arrow) in the action palette and connect the Insert WS-Security Username Token node with Service Handler for 'CustomerService' (click once on each node):

Figure 30
Figure 30 - Policy Studio - CustomerService with Username and Token policy

  1. You can now deploy the changes. Click the Deploy icon (top right corner) or hit the F6 key on your keyboard.

Bring your Service Explorer up again, but this time try to execute without the security header - just remove the whole Header tag from the payload. Remember to modify the request endpoint to http://localhost:8080/Customer/CustomerService, since we changed it to call Service Bus directly in the previous section.

The service call will go through OEG and the policy will insert the user/password credentials required by Service Bus. Successfully authenticated to proceed, the service will execute the request.

Add User Authentication on OEG

So, at this point the service we have exposed on OWSM and OSB is checking for credentials, and OEG is passing a fixed, systemic user. The last thing we have to do to fully implement the business scenario is to command OEG to ask for credentials, check them against an isolated user store, and if the validation goes right, remove the received credentials and follow the course we already coded (insert the internal credentials and call the service provider).

As previously mentioned, we adopted an OEG internal store to keep the scope of this article as simple as possible. In a real-world architecture, OEG can be integrated with different credential providers, such as Oracle Access Manager or an LDAP server, in order to provide a better solution which will provide authentication or authorization outside of your network in a secure perimeter (DMZ).

First, we're going to add a new user to OEG's local store:

  1. In Policy Studio, click the Users item in the left panel
  2. In the tree view (top left), click Users (inside User Store) to display a list of existing users
  3. Click Add, to the right of the users list and fill in the information for your new user:
    1. User: JakobsPetStore
    2. Password: oracle

Figure 31
Figure 31 - Policy Studio - User Management

Now, we have to update the OEG policy to perform the authentication against its internal user store:

  1. Click the Policies item in the left panel, then expand Generated Circuits, then expand Web Services.CustomerService, then expand /Customer/CustomerService and then click on Service Handler for 'CustomerService'
  2. In the Filters list (right side) expand Authentication and drag-and-drop WS-Security Username Token into the editor
  3. In the filter configuration window, do the following:
    1. Change Name to Authenticate User
    2. Set Drift to 5 secs
    3. Set Validity Period to 5 mins
    4. Uncheck Nonce Required
    5. Select Verify username and password
    6. Select Clear password required
    7. At Repository Name, select Local User Store
    8. Under Advanced section, check Remove enclosing WS-Security element on successful validation (otherwise you will send the wrong security credentials to Service Bus):

      Figure 32
      Figure 32 - Policy Studio - WS-Security Username and Token policy settings
    9. Click Finish
  4. Set Authenticate User as the starting filter of the policy by right-clicking and selecting Set as Start
  5. Create a success path (green arrow) connecting Authenticate User to Insert WS-Security Username Token:

    Figure 33
    Figure 33 - Policy Studio - CustomerService complete Custom Policy
  6. Deploy the new policy (click the deploy icon or hit F6).

Back in Service Explorer, if you try to execute the service as it is (pointing to OEG and without any security information), you should receive a fault:MessageBlocked error, as OEG now demands you to pass a valid credential set:


<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
    <env:Header />
    <env:Body>
        <env:Fault>
            <env:Code>
                <env:Value>env:Receiver</env:Value>
                <env:Subcode>
                    <env:Value xmlns:fault="http://www.vordel.com/soapfaults">
                        fault:MessageBlocked
                    </env:Value>
                </env:Subcode>
            </env:Code>
            <env:Reason />
            <env:Detail xmlns:fault="http://www.vordel.com/soapfaults"
                fault:type="faultDetails" />
        </env:Fault>
    </env:Body>
</env:Envelope>

Now, insert a new user token by clicking on Security Tokens, selecting WS-Security Username and filling the fields as indicated below (the password is oracle):


Figure 34
Figure 34 - Service Explorer - Insert WS-Security Username and Token

Execute the request, and you will get the expected business response.

Note: The security header generated by Service Explorer contains a Created tag with a timestamp. This info is checked by OEG to ensure that the request is being made inside the period determined by the Validity Period we set (5 minutes). If you remove this tag or execute a request with an interval between the creation of the token and the actual call greater than 5 minutes, you will receive a fault:MessageBlocked SOAP fault, blocking a possible Replay Attack. For more details please check the references.

If you want to avoid the capture-replay threat (check the references section for details), you must combine the Nonce (Number Once) and SHA1 Digest features - this way, if someone sniffs your request and try to tamper it, OEG will not acknowledge the bogus request, protecting your environment.

With this, we complete the implementation of the proposed scenario.

Note: Oracle Enterprise Gateway has two main monitoring components, Traffic Monitor and Real Time monitoring, which can be accessed through the product's management interface (http://localhost:8090). Traffic Monitor provides a web-based message log of the HTTP and HTTPS traffic processed by OEG, very useful for troubleshooting. Real Time monitoring shows usage statistics and displays graphic information about request status, SLA breach messages, Remote hosts access, and more.


Figure 35
Figure 35 - Oracle Enterprise Gateway - Traffic Monitor


Figure 36
Figure 36 - Oracle Enterprise Gateway - Real Time Monitoring

Conclusion

Oracle Service Bus and Oracle Web Services Manager are great solutions for Web Services security, but Oracle Enterprise Gateway takes it to the next level, offering unique functionalities and a more advanced approach to Web Services Policies development. Also, having Oracle Enterprise Gateway in a DMZ is a strategic decision that will block unauthorized access to your internal network (intranet) and get less traffic on Oracle Service Bus or any other back end service. In this article we explored simple solutions for security, but Enterprise Gateway also offers throttling, caching, SSL termination, SAML token replication, XML threat protection (SQL injection, virus checking), faster XML/XLST parsing, and more.

Together, Oracle Enterprise Gateway, Oracle Service Bus and Oracle Web Services Manager offer a complete suite for Web Services security, providing performance, scalability and interoperability with open standards.

References

About the Authors

William Markito Oliveira LinkedIn is a Senior Technologist with the Oracle Platform Technology Solutions team in Brazil where he focuses in Middleware, SOA, and Java technologies. He also contributed to the official Java EE Tutorial, providing write-ups and code examples covering CDI, EJB 3.1 and JAX-RS. William has more than 10 years experience in Software Development, Consulting and Architecture.

Fabio Mazanatti LinkedIn is a Principal Consultant with Oracle Consulting Brazil, where he supports large-scale companies in their quest for SOA adoption. He has worked as consultant for over 20 years, covering a wide variety of technologies.