Adding Web Service Trusted Certificates to a Wallet in Oracle Database Cloud Service

Introduction This post documents how to add trusted TLS/SSL certificates to an Oracle Database as a Service (DBaaS) wallet. It uses an example of an Oracle Business Intelligence Cloud Service (BICS) REST API call to Delete Cached Data as documented in REST APIs for Oracle BI Cloud Service. This call is issued from PL/SQL and […]

Loading Data from Oracle Field Service Cloud into Oracle BI Cloud Service using SOAP

Introduction This post details a method of extracting and loading data from Oracle Field Service Cloud (OFSC) into the Oracle Business Intelligence Cloud Service (BICS). A compelling reason to use such a method is when data is required that is not in the standard daily extract. Such data might be planning (future) data or data […]

Loading Data into Oracle BI Cloud Service using OTBI Analyses and SOAP

Introduction This post details a method of loading data that has been extracted from Oracle Transactional Business Intelligence (OTBI) using SOAP into the Oracle Business Intelligence Cloud Service (BICS). The OTBI instance may either be Cloud-Based or On-Premise. This method may also be used to load data from Oracle Business Intelligence Enterprise Edition (OBIEE). It […]

Loading Data into Oracle BI Cloud Service using BI Publisher Reports and REST Web Services

Introduction This post details a method of loading data that has been extracted from Oracle Business Intelligence Publisher (BIP) into the Oracle Business Intelligence Cloud Service (BICS). The BIP instance may either be Cloud-Based or On-Premise. It builds upon the A-Team post Extracting Data from Oracle Business Intelligence 12c Using the BI Publisher REST API. […]

Using Oracle Data Integrator (ODI) to Bulk Load Data into HCM-Cloud

Introduction With its capacity to handle complex transformations and large volumes of data, and its ability to orchestrate operations across heterogeneous systems, ODI is a great tool to prepare and upload bulk data into HCM Cloud. In this post, we are looking at the different steps required to perform this task. Overview of the integration […]

Using Oracle BI Answers to Extract Data from HCM via Web Services

Introduction Oracle BI Answers, also known as ‘Analyses’ or ‘Analysis Editor’, is a reporting tool that is part of the Oracle Transactional Business Intelligence (OTBI), and available within the Oracle Human Capital Management (HCM) product suite. This article will outline an approach in which a BI Answers report will be used to extract data from HCM via web services. […]

Tuning Asynchronous Web Services in Fusion Applications Part II

Introduction In a series of earlier blogs we have covered in detail several aspects of asynchronous web services in Fusion Applications including the general implementation, how to monitor, and also discussed tuning considerations and options. This article discusses an additional tuning option for how Fusion Applications consumes waiting messages in the underlying queues. Main Article In a […]

Oracle HCM Cloud – Bulk Integration Automation Using SOA Cloud Service

Introduction Oracle Human Capital Management (HCM) Cloud provides a comprehensive set of tools, templates, and pre-packaged integration to cover various scenarios using modern and efficient technologies. One of the patterns is the batch integration to load and extract data to and from the HCM cloud. HCM provides the following bulk integration interfaces and tools: HCM Data […]

Fusion HCM Cloud – Bulk Integration Automation Using Managed File Transfer (MFT) and Node.js

Introduction Fusion HCM Cloud provides a comprehensive set of tools, templates, and pre-packaged integration to cover various scenarios using modern and efficient technologies. One of the patterns is the bulk integration to load and extract data to/from the cloud. The inbound tool is the File Based data loader (FBL) evolving into HCM Data Loaders (HDL). […]

How to secure Web Services exposed by OAAM Server (oaam_server)

At the end it turned out very simple but I had spent long time in configuring security (authentication and authorization) for Web Services exposed by OAAM 11gR2, thought about writing a blog post on it. For native integration, OAAM Server (oaam_server) exposes Web Services. For the enterprise deployment, security of Web Services would be mandatory.  […]

Web Service Transactions Part 2: WS-AtomicTransaction with SOA Composite calling EJB-Web Service

In the first part we have looked at web service transactions between JAX-WS web services without any SOA composite/component.

The next scenario where we will look at is a SOA composite calling the web service WsatBankTransferService deployed in part 1. (click on each image to display in full quality):

image

Enable WS-AT on the SOA domain

The installation of the 11.1.1.3 Patch Set of Oracle SOA unfortunately does not update the file policy-accessor-config.xml in the created domain or WLS instance to the required WS-AT settings.

The definition of policy interceptors is however mandatory for WS-AT to work. If you did not configure anything in policy-accessor-config.xml yourself, this means that you will need to replace your version of the file with this version. (The original file can the found here for comparison).

Rename you file to .old and copy the downloaded file to the directory. Restart the Weblogic server.

Design and Deploy the Composite

First start the Weblogic samples server and use a port different than the SOA instance. I use port 8001 for the examples WLS domain and port 7001 for the admin server where the soa domain is deployed.

Then start TcpMon – to be able to monitor the SOAP request lateron and tunnel all request from port 8081 to port 8001:

image

We will create a BPEL based SOA composite with the SOA designer.

Create a new SOA project and a new composite with a BPEL component. Choose a synchronous BPEL process type and name it like you want. 

After that, drop a web service from the resource palette into the right part of the composite editor to create a reference. Fill in the details of the WsatBankTransferService but use the port set with TcpMon. Paste the WSDL URL of the WsatBankTransferService into the form and select MANDATORY and DEFAULT for WS-AT transaction propagation and version

image

Next edit the bpel process to include a Invoke activity for “CreateAccount” using the newly created Partnerlink and pass the input parameter with an Assign activity to the invoke:

image

The result should look like:

image

Now you can deploy and test the composite, right?

No, because at this point, the BPEL component would not automatically start a transaction. To achieve this, edit the composite.xml and insert the bpel.config.transaction property like:

<component name=”WSATBPELClient”>
  <implementation.bpel src=”WSATBPELClient.bpel”/>
  <property name=”bpel.config.transaction”
       many=”false” type=”xs:string”>requiresNew</property>
</component>
<reference name=”BankAccountService”
           ui:wsdlLocation=”http://192.168.56.110:8081/WsatBankTransferService/WsatBankTransferService?WSDL”>
  <interface.wsdl interface=”http://tempuri.org/#wsdl.interface(WsatBankTransferService)”/>
  <binding.ws port=”http://tempuri.org/#wsdl.endpoint(WsatBankTransferService/WSHttpBindingIService)”
              location=”http://192.168.56.110:8081/WsatBankTransferService/WsatBankTransferService?WSDL”
              soapVersion=”1.1″>
    <property name=”weblogic.wsee.wsat.transaction.flowOption”
              type=”xs:string” many=”false”>MANDATORY</property>
    <property name=”weblogic.wsee.wsat.transaction.version” type=”xs:string”
              many=”false”>DEFAULT</property>
  </binding.ws>
</reference>

At this point it does not matter if you used “RequiresNew” or “Required”, any of the two will start a new transaction because we do not pass any to the inbound “client” partnerlink.

Now you can deploy the composite to the SOA domain.

Testing and Debugging WS-Atomic Transactions

Execute the composite in the EM Test page (http://host:7001/em)

You should see a successfully completed instance and several SOAP or https calls in TcpMon. The latest should be the SOAP request to create the account – with the same WS-Coordination Context as seen in part 1:

<env:Envelope xmlns:env=”http://schemas.xmlsoap.org/soap/envelope/”
              xmlns:wsa=”http://www.w3.org/2005/08/addressing”>
  <env:Header>
    <wsa:To>http://127.0.0.1:8081/WsatBankTransferService/WsatBankTransferService</wsa:To>
    <wsa:Action>http://tempuri.org/WsatBankTransferService/createAccountRequest</wsa:Action>
    <wsa:MessageID>urn:73432EF0A5E911DFBFAC43B9B866DC33</wsa:MessageID>
    <wsa:RelatesTo>urn:73432EF0A5E911DFBFAC43B9B866DC33</wsa:RelatesTo>
    <wsa:ReplyTo>
      <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
      <wsa:ReferenceParameters>
        <instra:tracking.ecid xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>0000Id_N1rj3n3WjLxZR8A1COuk800001X</instra:tracking.ecid>
        <instra:tracking.conversationId xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>urn:73432EF0A5E911DFBFAC43B9B866DC33</instra:tracking.conversationId>
        <instra:tracking.parentComponentInstanceId xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>reference:50001</instra:tracking.parentComponentInstanceId>
      </wsa:ReferenceParameters>
    </wsa:ReplyTo>
    <ns3:CoordinationContext xmlns:ns3=”http://schemas.xmlsoap.org/ws/2004/10/wscoor”
                             xmlns:ns4=”http://schemas.xmlsoap.org/ws/2004/08/addressing”
                             env:mustUnderstand=”1″>
      <ns3:Identifier>urn:uuid:BEA1-02783739A26FB5C280E1</ns3:Identifier>
      <ns3:Expires>298000</ns3:Expires>
      <ns3:CoordinationType>http://schemas.xmlsoap.org/ws/2004/10/wsat</ns3:CoordinationType>
      <ns3:RegistrationService>
        <ns4:Address>http://192.168.56.110:7001/wls-wsat/RegistrationPortTypeRPC</ns4:Address>
        <ns4:ReferenceParameters>
          <wls-wsat:txId xmlns:wls-wsat=”http://weblogic.wsee.wstx.wsat/ws/2008/10/wsat”>BEA1-02783739A26FB5C280E1</wls-wsat:txId>
          <wls-wsat:routing xmlns:wls-wsat=”http://weblogic.wsee.wstx.wsat/ws/2008/10/wsat”>AdminServer</wls-wsat:routing>
        </ns4:ReferenceParameters>
      </ns3:RegistrationService>
    </ns3:CoordinationContext>
  </env:Header>
  <env:Body>
    <createAccount xmlns=”http://tempuri.org/”>wwewe</createAccount>
  </env:Body>
</env:Envelope>

Debugging of all WS-AT related actions on server-side can be switched on with the java command line flag

-Dweblogic.debug.DebugWSAT=true

You will see a lot of 2PC handshake requests like for example:

<WseeWsat> <BEA-224575> <WS-AT transaction id is BEA1-45D0D4EFBBE0B5C280E1 and time to live is 299,000 for transaction Name=…

<WseeWsat> <BEA-224504> <registerOperation entered with …

<WseeWsat> <BEA-224503> <Registering Durable2PC Participant

<WseeWsat> <BEA-224538> <Durable2PC WS-AT Participant created for Address

<WseeWsat> <BEA-224539> <Prepare called for Address

<WseeWsat> <BEA-224603> <Successfully created participant port

<WseeWsat> <BEA-224602> <Durable participant port placed in cache for

 

<WseeWsat> <BEA-224510> <preparedOperation Xid:

<WseeWsat> <BEA-224511> <preparedOperation exited with Notification

<WseeWsat> <BEA-224546> <Commit called for Address

<WseeWsat> <BEA-224590> <About to send commit for durable participant with Xid

<WseeWsat> <BEA-224518> <committedOperation entered with Notification

<WseeWsat> <BEA-224591> <Commit sent for durable participant with Xid

<WseeWsat> <BEA-224547> <Commit call received reply COMMITTED before wait was entered for Address

<WseeWsat> <BEA-224583> <Durable participant port removed from cache

<WseeWsat> <BEA-224584> <Durable participant XAResource removed from cache

Monitoring and Management

In the SOA Control web administration frontend, you can set or change the WS-AT settings for all endpoints. Right-click on the SOA composite and select “Service/Reference Properties”:

image

In our case, we only see the client-side composite endpoint because we do not have a SOA on the callee side.

Under “Properties” you have access to the Transaction Flow and WS-AT Version settings.

image

For the JAX-WS Webservice published on the Samples Server you can see the settings in the WLS console:

image

Navigate to the webservicesWsatSimpleEar deployment, expand the WsatBankTransferService web service and click on it. You will see the WS-AT setting under “Configuration”, “Ports”:

image

Click on any operation or the whole web service to modify this:

image

You can also verify the WS-AT setting in the WSDL on the web service:

If you look at the WSDL then you see for every binding the attached WS-AT policy:

<operation name=”createAccount”>
   <wsp:PolicyReference URI=”#WSAT10″/>

This scenario was a single operation “CreateAccount”. In the next part we will create a sample using 2 SOA composites being called by another composite in one atomic transactions. Both callees use DBAdapter, so we can play around with rollbacks easily.

Stay tuned!

Troubleshooting

If you receive the following exception when testing the composite, then you did not copy the new policy-accessor-config.xml

Caused by: javax.xml.ws.soap.SOAPFaultException: transaction context is required to be inflowed at oracle.j2ee.ws.client.jaxws.DispatchImpl.throwJAXWSSoapFaultException(DispatchImpl.java:955) at oracle.j2ee.ws.client.jaxws.DispatchImpl.invoke(DispatchImpl.java:750) at oracle.j2ee.ws.client.jaxws.OracleDispatchImpl.synchronousInvocationWithRetry(OracleDispatchImpl.java:234) at …

Do I Need to Secure My Service?

I sometimes get asked by customers whether they need any security at all for their “internal services”. I wanted to take a post to examine this subject.

Let’s take the simplest case possible from a security vantage point: a synchronous web service being called from a limited number of trusted internal clients (let’s say web applications). Because the web service is synchronous we don’t have to worry about the request sitting in a queue unprotected. Likewise, because the web service is being called from a limited number of internal clients we might be inclined to care less, if at all, about ensuring that users/clients are authorized to call the service. Finally, we will assume that there is no requirement to authenticate a “user” of the client invoking the service.

At the same time we will assume that the service is a “high value” service such that exposing it to the “outside” without security would be a mistake.

So, does such a service need security?

I think to answer this question we have to look at all the possible security concerns for such a service and how they can be addressed with or without explicit security. Usually, when a customer implies that their service doesn’t mean security what they are really saying is that the boundaries of their physical network providing all the security they need. So, let’s look and see to what extent that may be true.

The security concerns for an internal, synchronous service are as follows:

1) Client trust: ensuring that only authorized users/clients are invoking the service.

There are two types of potentially unauthorized clients to worry about, internal clients and external clients.

To protect against external client access physical network boundaries may be sufficient.
However, in my experience an increasing number of customers are not comfortable relying on their physical network.

Without additional security, the only protection against unauthorized internal access to your services is the trust and good will of the users that have access internally.

Two-way SSL is a straight forward, easy to deploy security solution that you can add to your web service that provides strong protection against all types of unauthorized client access. Note though, that one-way SSL does nothing to help with this case.

2) Service trust: ensuring that the service being invoked by consumers of the service is authentic; that it is not a Trojan horse service.

The physical network does provide some level of protection here in that a malicious Trojan service would have to be accompanied by IP address spoofing or DNS hacking to do damage. The greater danger might be the standing up and advertising of an unauthorized service for a SOA phishing attack.

Here SSL (technically just one-way) can help ensure that only authorized services are being called by clients.

3) Message integrity: ensuring the message has not been tampered with.

The physical network can limit the potential for capture, alter, and replay attacks to internal users but SSL can be added to eliminate all risk associated with capturing messages over the wire.

4) Message confidentiality: ensuring that the information in the message cannot be intercepted and read.

The physical network can limit the potential for message capture to internal users but SSL can be used to eliminate all risk of capture over the wire.

5) Tracking and reporting: ensuring that the ability exists to track specific requests/transactions to a specific user/client.

Without additional steps the only tracking mechanism provided by the physical network is the IP address of the client which may or may not be of use.

When you add 2-way SSL with each client getting a unique client certificate, you now have definitive record of which client made which request.

6) Identity propagation
If there is a requirement to propagate the identity of the user of a web application onto the web service then there is potentially additional security required.

Given the assumptions made at the beginning that the consumers of our service are trusted internal clients, we will assume that we can trust them to propagate whatever identity they want. Still, the propagation has to be done in some fashion.

Here we have 3 options:
1) The identity could be added through a custom HTTP header. This is easy on the client and secure if we trust the client and are using 2-way SSL at the transport (the header can be encrypted with symmetric cryptography for added security). On the downside it is very non-standard and will most likely require some custom work on the service side to accept an identity from a custom header.

2) The use of a real WSS Security header such as a SAML assertion. Using SAML with the bearer confirmation method (http://fusionsecurity.blogspot.com/2009/09/bearer-confirmation-method-huh-what-is.html) provides a more standard way of propagating a user identity. With bearer, no messy signing or encryption is required and given our assumptions the security of bearer is probably sufficient if 2-way SSL is being used. The only gotcha is you have to have client and server side stacks that can both “speak” SAML bearer.

3) Many customers ask/talk about just putting the user identity in the body of the message. In many ways this is the easiest thing to do. I also think it makes sense if the business logic of the service will actually make use of the user identity information; as would be the case for a “process insurance selection” or “purchase ticket” service. The only thing to understand is that putting user identity information in the message body means including it in the schema and explicitly coding how to retrieve it in the service. If you rely on WSS security for user propagation then the user identity can be left out of the schema and the service can be coded just to get the identity from the container.

When identity propagation comes up in these conversations, the discussion usually centers on using SAML vs. just putting the user info in the message body. The key deciding factors here are whether the user info will be used by the business logic of the service, whether you want to include the user info in the schema or not, and whether you are comfortable with the code of the service itself retrieving the user identity from the message or whether you’d rather rely on getting the user identity from the container.

Summary
On a very restrictive physical network where trust in the users that have access to the network is very high, it may be OK to deploy a high value web service without additional security. However, most of the time it is a good idea to utilize 2-way SSL to provide strong transport level security.
If identity propagation is required a judgment call needs to be made on how to propagate the identity and whether or not to do so through transport security, WSS message level security, or just in the body of the message.

Exposing E-Business Suite services using the Integrated SOA Gateway

Oracle E-Business Suite Release 12 introduced a new “Integrated SOA Gateway” that makes it very easy to expose functionality from E-Business Suite as web services.  This allows much easier integration to and from E-Business Suite. In this post, we look … Continue reading

Service enabling WebCenter Interaction

Today, I needed to create a web service to expose some functionality from WebCenter Interaction.  In this case, I needed to be able to have an external process move a document from one folder to another in the knowledge repository. … Continue reading

Calling BPEL web services from Application Express

Just a quick post, on an issue that seems to come up a lot – how to call a BPEL web service from Application Express.  This used to be quite challenging, but now, with APEX 3.1.2, APEX can understand a … Continue reading