Setting up an Oracle Cloud Service (Trial Version)

Oracle is currently offering a 30 day free trial on their SOA Cloud service, which is a very good way of introducing yourself to the joys of PaaS. I would suggest giving it a whirl, if only to understand just how Oracle is positioning its cloud based offerings. This blog describes the required steps to provision a trial version of the Oracle SOA Cloud service, which whilst relatively easy to do, does have some gotcha’s that you should be aware of!

Oracle SOA cloud provides access to 12.1.3 of SOA Suite in a fully managed environment. By subscribing to a managed cloud environment, developers get rapid access to SOA Suite without the need to wait for lengthy environment provisioning by the I.T department, as was traditionally the case. This means of course, that you can start developing innovative applications far more quickly, without worrying about all the nuances associated with a complete produce install! Please note however, that Oracle currently does not have a fully ported version of SOA on the cloud: B2B, Managed File Transfer, Enterprise Scheduling, Event Processing, and BAM are not currently available.

Oracle offers two models of subscription for its SOA Cloud Service: A non-metered version (there are several pricing and service levels to suit the needs and budget of your organization) or a metered version. The latter can be ordered via a purchase order or by pre-paid subscription or pay as you go.

It is worth mentioning that before you can create a SOA Cloud instance, you need to subscribe to Oracle Database Cloud Service (the full one and not Database Schema!) and also to Oracle Storage Cloud - the latter is used for database backups.

So how to start…..

First off subscribe to the Oracle Public Cloud Service:

As part of the subscribing process, you will need to request a verification code (see the  "Request Code" button in the above screen shot). This is sent as a SMS message to your mobile. You need to enter the code sent prior to selecting the “sign up” button.

Once your subscription has been accepted, Oracle will send you an email detailing how you can access the various consoles required to complete the installation.

Setting up access to Cloud Storage....

Firstly, you must subscribe to the Cloud Storage. This is not quite as easy as it might seem as you need to access this service via a REST API (you can also access through an official java library). Oracle recommend that you use a tool called Curl to do this. Installing Curl is straight forward enough. Details of how to do this can be found at the following URL: http://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/objectstorage/creating_containers_REST_API/files/installing_curl_command_line_tool_on_windows.html

Oracle Storage Cloud Service requires authentication for any operation against the service instance. Authentication is performed by using an authentication token, which expires every 30 minutes. You must include your current authentication token with every request to Oracle Storage Cloud Service. To request an authentication token, run the following command (substituting your details for the tokens below):

curl -k -v -s -X GET -H "X-Storage-User: Storage-<<your domain>>>:<<your email>>>" -H "X-Storage-Pass: <<your password>>" https://<<your domain>>.storage.oraclecloud.com/auth/v1.0

NOTE: You must first have logged onto the MyServices console to set a replication policy for the Cloud Storage instance – do this by logging on and selecting “Set Replication Policy”. Otherwise, you cannot access the Cloud Storage instance (so beware!).

Executing this command will give you an authentication code that you can use to create a container. The container is created using the following command:

curl -k -v -s -X PUT -H "X-Auth-Token: AUTH_tkb7364f9f8b937c96c8e2a8e716 914092" https://storage.us2.oraclecloud.com/v1/Storage-<<your domain>> /myFirstContainer

NOTE: Clearly, you will use the security token generated using the above step. I have included a token as an example only here.

To verify that this is set up correctly, issue the following command:

curl -k -v -s -X GET -H "X-Auth-Token: AUTH_tkb7364f9f8b937c96c8e2a8e716914092" https://storage.us2.oraclecloud.com/v1/Storage-<<your domain>>/myFirstContainer

You will use the above storage container when defining your DBaaS instance (see below).

Generating a SSH Key Pair…..

When you define your Oracle DBaaS database instance (see below), you will need to provide a secure shell (SSH) public key to establish secure connections.  I used the PUTTY Key Generator on windows to do this. This is fairly straight forward and there are plenty of details on the web, so I will not go into details here.

Creating a Database Instance…..

Oracle SOA Cloud Service employs the Oracle Database Cloud Service to host the Oracle Fusion Middleware component schemas that are required by the Oracle Java Required Files (JRF).

So before we can get access to SOA Cloud we must create a database service instance. You will do this from the My Services console. From the console, select the Oracle Database Cloud Service and go to the Dashboard view. Then select the “Create Instance” button (see below):

This will invoke the Create Database Cloud wizard. Here you will select your subscription type (I chose Oracle Database Cloud Service) and your desired billing frequency. Also, the database version and edition.

Next you will be asked to configure the database instance. Here, you will need to specify your cloud storage container and upload the public key that was generated in the above step:

Once you have entered your details, hit “Next” and you will be presented with a summary for your requested Database Cloud instance. You can create the instance and await email confirmation. This takes about an hour! Amazing really! Remember the joys of having to commission a new server to hold your database, get "operations" to install the database and patch it and then agree a back up schedule!!! No more need for all this time consuming bureaucracy!!

Finally, you need to create your SOA Cloud instance once the database is created.

Creating a SOA Cloud Service

To create the SOA Cloud instance, go to the dash board and select the SOA Cloud icon. This will take you to the SOA Cloud Service Console (see below). From here you will select the “Create Instance” button and this will invoke the SOA instance creation wizard.

From here, click ‘Create Instance’. Next, you will select the type of weblogic domain that you want to be configured and the billing frequency. I choose a SOA and OSB cluster:

Next, you are presented with a summary of the software selected. Just hit “Next” to continue once you are happy. This will take you to the main configuration page for your weblogic domain. Here, you need to specify the instance name, provide details of your cloud storage and database instance and create a weblogic administrator user and password as shown below:

NOTE: The public key is the same used for the DbaaS creation above. Also, the database admin user should be set to sys and the schema password entered as per the Database cloud service creation.

Finally, you will be presented with a summary of the SOA Cloud instance that will be created:

And, that’s it. Now just click Create and someone will do all the heavy lifting for you! Amazing!

Validating the New SOA Cloud Instance…..

Once the instance is created (after approx. 1 hour) you will have access to the service instance from the SOA Cloud Service Console as shown below:

And there you go! As simple as that! The only thing that remains to do is to open up the weblogic console and validate access.

Enjoy!!!

Oracle Integration Cloud Service

Many companies today are looking to remove costs from the bottom line by moving non-mission critical applications into the cloud. There are many advantages to doing this but the main being to lower the TCO (total cost of ownership). However, there still remains the problem of integrating these applications with other enterprise applications and with on premise systems. These new SaaS applications cannot function in splendid isolation!

I have spent some time recently investigating Oracle’s Cloud Integration Service (ICS). ICS is designed to simplify the task of integrating data between SaaS applications. It can also be used for SaaS to on premise integration using either Rest or Web service calls (currently).

Oracle has done a good job of abstracting the complexity of connecting to SaaS applications by introducing Application Connectors: all the user needs to do is to configure the endpoint and provide credentials. Once connected, the user can use the web based mapping tool to map data between the applications.

Oracle has been keen to boost the community aspects of the tool by providing recommended mappings based on what most users currently use. This can make the job of mapping much simpler and open up the possibility that integrations can be done by functional rather than technical experts. Nevertheless, Oracle also provides more advanced mapping functions where straight forward field mapping is not obvious or achievable.

Oracle is really pushing this area and they are providing many pre built application connectors to SaaS applications such as its own SaaS offerings (e.g Service Cloud) but also third parties such as SAP, Netsuite and Linkedin. The pace of development is very rapid in this area and new connectors are being provided almost monthly by Oracle. There are somewhere in the region of 2500 SaaS applications available in the market today and Oracle cannot possibly hope to provide connectors for all of them. So, Oracle are supporting third party developers to create their own Application Connectors using the shipped SDK.  Since ICS is based on the tried and tested Oracle Service Bus for its implementation, the same application connectors can be used on premise or in the cloud. Perfect for saving time and effort!

Security protocols are supported too. Web Service calls can be secured with basic authentication, WS-Security username/token, or other mechanisms, along with transport level security using SSL/TLS. Future releases will support the uploading of certificates. Integration Cloud Service runs on Oracle’s secure cloud infrastructure with each tenant getting their own dedicated environment.

The beauty of ICS lies in the fact that integration between SaaS applications can be packaged up and sold (or even given away!) on the Oracle Marketplace. This will help companies moving to the cloud to rapidly set up integrations that previously would have taken weeks or months via the more traditional software development lifecycles.

Oracle has made several announcements regarding the roadmap for ICS and they are quite exciting! These include the introduction of basic orchestration features in future versions to allow for enrichment of data prior to mapping. Also, to help with security issues, Oracle will provide agents that will execute on premise and talk back to ICS. These agents communicate via Rest so there is no need for complex firewall rules.

Oracle offers four main approaches to integration with ICS:

Cloud adapters, Technical adapters (for database, FTP, SOAP connections), on premise agents (to be introduced shortly) and finally the SDK/market place.

Further adapters will become available over the next few months to open ICS up to SFTP, databases and many other back-end systems.

Most importantly, Oracle also provides rich web based monitoring tools to provide visibility onto the performance and reliability of the integrations.

So one question I had was where does SOA Suite fit in now that more orchestration features are being built into ICS? I think that the answer lies in what you are trying to integrate. In much the same way as Oracle Service Bus can be used to provide orchestration (of sorts using pipelines), I would never recommend doing this. SOA Suite has many features that make this more suitable such as dehydration. In the same way, just because ICS can do something, doesn’t mean that it should be used if it is not best tool for the job. So, in summary, for more complex integrations, especially long running processes, SOA Suite is still the best choice – whether on premise or in the cloud. ICS however, is an excellent tool that provides an elevated user experience (meaning that it can be used by non-core techies) for SaaS to Saas and SaaS to on premise integrations.

Finally, I would not recommend using the tool for batch integrations either, as there are better alternatives, such as Oracle Data Integrator (ODI).

How To: Enable WSS UsernameToken Profile in SOA Suite 12c

The Enable TLS on Weblogic 12c blog gave a simple set of steps to enable private and confidential communications between a client and Weblogic server.  However, while TLS (server authentication) does provide an encrypted channel between the client and server, it does not provide access control to services that may be deployed and running.

As a solution to this problem, this blog will detail how access control can be enabled for an SCA composite web service deployed on SOA Suite 12c.  We will be using the WSS UsernameToken Profile policy available in Oracle Web Services Manager (OWSM), and in addition, we will also see how a secured web service can be tested in soapUI.

NOTE: It is of paramount importance that the UsernameToken Profile is used over an encrypted channel such as TLS.  The reason for this is that the username and password (or digest) are sent in plaintext and are susceptible to man-in-the-middle attacks.  

Attaching the UsernameToken Profile Policy

Attaching OWSM policies is a simple activity, performed in the Enterprise Manager Fusion Middleware Control application.  The following steps detail how a policy is attached to (an obligatory) Hello World web service.

1. Log into the Enterprise Manager at http://{host}:{port}/em and navigate to the SCA composite home page

2. In the 'Service and References' section, click on the exposed web service link to go to the service dashboard

3. In the web service dashboard, click the 'Policies' tab

4. In the 'Directly Attached Policies' section, click the 'Attach/Detach' button

5. In the 'Available Policies' section, select the oracle/wss_username_token_over_ssl_service_policy, click 'Attach' and 'OK'

Testing a Secured Web Service in soapUI

To confirm that the policy configuration above has been applied successfully, we can use a testing tool such as soapUI.  SoapUI is a testing suite capable of running tests against SOAP or REST endpoints, it has been around a good number of years now and has become a crucial tool in the utility belt of both web service developers and system testers alike.

Verifying the Policy Attachment

To verify the policy attachment, we only need to load the SOAP project in soapUI and send a test message.  If the policy has been applied correctly, then a HTTP 500 Internal Server Error and invalid security message should be received as we have not provided any credentials yet:

Adding the UsernameToken

To call the web service successfully, we need to add a UsernameToken to the SOAP header.  This can be done as follows:

1. In the 'Request Properties' box of soapUI, enter the username and password for the service

2. Right click in the request window and select 'Add WSS Username Token'

3. Right click in the request window again, and select 'Add WS-Timestamp'

Re-send the message.  This time the response should contain a HTTP 200 and the SOAP response:

This completes the UsernameToken Profile configuration and testing.  Hopefully you can see just how simple OWSM makes security configuration.

How To: Enable TLS on Weblogic 12c

Transport Layer Security is one of the most important data security protocols in use today and many organisations, including banks and e-commerce sites use it to provide private and confidential communications.  Thankfully, enabling TLS (server authentication) on Weblogic is a relatively straight-forward process, requiring only a security certificate and minimal server configuration.

Generating a Public-Private Key Pair (and X.509 Certificate)

Before we can enable TLS in Weblogic, we require a security certificate that includes our public key and domain information.  This certificate will be sent to a client by the server so it can verify that the server is legitimate.

One option is to acquire a certificate from an established Certificate Authority (CA) such as Thawte or Symantec (formerly Verisign).  While this is the recommended approach for production, public facing systems, it can be expensive for academic and internal applications.  Given that this is an academic blog, we can use another option which is to 'self-sign' our own certificate, free of charge.

To generate our own, self-signed certificate, we use can use the keytool utility that comes with the Java Development Kit (JDK) and the following command:

keytool -genkeypair -keyalg RSA -alias mydomain -keystore identitystore.jks -storepass password -validity 365 -keysize 2048

Configuring a Keystore in Weblogic and Enabling TLS

The next step is to configure the keystore created above (which contains the certificate) in Weblogic.

In summary, the steps required are:

A. Add the keystore created above to the Weblogic configuration
B. Provide credentials to Weblogic for the keystore and private key
C. Enable the SSL listen port
D. Modify the server start-up parameters to enforce the TLSv1 protocol (due to the POODLE attack in 2014, SSLv3 is no longer recommended)

In detail, the steps required are:

1. Log in to the Weblogic console at http://{host}:{port}/console
2. Navigate to the server 'Keystores' configuration screen and click the 'Change' button

3. Choose 'Custom Identity and Java Standard Trust' and click 'Save'

4. Provide the custom identity store location, keystore type, passphrase and click 'Save'

5. Navigate to the server 'SSL' configuration screen and provide the private key alias, passphrase and click 'Save'

6. Navigate to the server general configuration screen, enable the SSL listen port and click 'Save'

7. Navigate to the 'Server Start' configuration screen, add the following argument and click 'Save'.  This argument could also be provided in a server startup script such as setDomainEnv.sh.

8. Restart the server for the new protocol version to take effect.

This completes the TLS setup.

Verifying the Configuration

To confirm that the configuration has been applied correctly, open a web browser and navigate to the Weblogic console on the SSL listen port (7002 in the example above).  If your browser is configured appropriately and the Weblogic configuration is correct, then a warning should be displayed indicating that the server cannot be verified.  This is an expected result, confirming that the Weblogic configuration is correct.