Calling a Fusion Applications web service from SOA Suite 11g

More and more customers are moving to Fusion Applications and as with all ERP systems, the need to integrate Fusion Applications with other (on-premise) applications is key is the customer's architecture. Although a lot of blogs on invoking a Fusion Applications web services have been written bij the A-Team and Fusion Applications Developer Relations and others, I still felt that the blogs missed some elements on getting started with this type of integration.
In this blog I will explain on how to invoke a web service of Fusion Application using SOA Suite 11g. For this blog I will be using a pre-build SOA Suite 11g PS6 virtual machine, that you can download from the Oracle site.

Keystore

First thing you need to know is that Fusion Applications web service need to be accessed over SSL. In order to achieve a valid SSL handshake between SOA Suite and Fusion Applications, you need to export the certificate of Fusion Applications and import it in the trust keystore of SOA Suite. You can find the trust keystore that is used by SOA Suite through the Weblogic Console.

After copying the certificate to the SOA Suite server, running the following command will import the Fusion Applications certificate in the SOA Suite keystore:
/oracle/javahome/jdk1.6.0_45/bin/keytool -import -v -file /oracle/javahome/jdk1.6.0_45/jre/lib/security/fatst.cer -keypass DemoTrustKeyStorePassPhrase -keystore /oracle/fmwhome/wlserver_10.3/server/lib/DemoTrust.jks -alias fatst

After bouncing the SOA Server, you will be able to achieve a valid SSL handshake.

Policies

Next thing you need to know is that the Fusion Applications web services that are exposed to external client invoke, are protected with OWSM WS policies for authentication. To find the policies that are enforces by Fusion Applications you need to check the WSDL of the web service you want to invoke.

For this example I will be invoking the WorkerService.

When you have a look at the WorkerService WSDL, you will find that the web service is protected with the wss11_saml_or_username_token_with_message_protection_service_policy policy.  But what does this mean?

Looking at the Fusion Middleware Security and Administrator's Guide for Web Services, you can read the following:

This policy enforces message protection (integrity and confidentiality) and one of the following authentication policies, based on whether the client uses a SAML, username, or HTTP token, respectively:

• SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard.
• Username token authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard.
• SAML-based authentication using credentials provided in SAML tokens with confirmation method 'Bearer' in the WS-Security SOAP header. Verifies that the transport protocol provides SSL message protection.
• Username token authentication using the credentials in the UsernameToken WS-Security SOAP header to authenticate users against the configured identity store. Verifies that the transport protocol provides SSL message protection.
• HTTP authentication using credentials extracted from the HTTP header to authenticate users against the configured identity store. Verifies that the transport protocol is HTTPS.
• JWT token authentication using the username extracted from the JWT token in the HTTP header. Verifies that the transport protocol is HTTPS.

If you read closely, you may have noticed that the description says 'one of the following policies, based on whether the client ...'.
So that means it is up to you, as the one building a client to invoke a Fusion Applications web service to determine which security you want to apply eg SAML, Username token, HTTP or JWT token.
Going back to the documentation of policies, you will find the predefined client policies that you can use with this service policy

For this example I will be demonstrating the use of the security policy with the smallest footprint for a client being HTTP authentication.

Again looking at the documentation you will see that currently HTTP basic authentication is supported, so I will be using

I will demonstrate how to incorporate this policy in:

• Design time
• Runtime
• Set authentication dynamically in BPEL

Before actually starting to build a client in SOA Suite, it is useful to test connectivity and correct payload using SoapUI.

Note that filling the Authentication tab with a valid Fusion Applications user and password is sufficient to invoke the FindWorker operation of the WorkerService. Since we are already invoking the endpoint through SSL, we meet all the requirements voor the HTTP authorization policy.

Design time   

In SOA Suite start of by creating a Composite with a BPEL component. Drag a web service as reference to the right side of the Composite pane and provide the WSDL of the Fusion Applications web service and wire the BPEL component to the web service.

  Right click on the web service and select Configure WS policies. 

In the Security section click on the plus icon to add the oracle/http_basic_auth_over_ssl_client_policy.

In the Properties Inspector add the following two properties in the Bindings Property section and provide values for the username and password.  

• oracle.webservices.auth.username
• oracle.webservices.auth.password

Construct your BPEL to assign values to the request message of the web service.

Deploy your SCA and test it!

Runtime

Instead of setting credentials hardcoded at design time, you might want to have more flexibility and be able to change the credentials overtime, without having to redeploy your SCA. In that case it would be more wise to attach the policy and credentials using Enterprise Manger.

Now that we have attached the policy on design time, we can create a key that will host the credentials to be used in the HTTP authentication.

In Enterprise Manager on the Weblogic Domain select Security > Credentials and create a new key with the credentials you want to use for invoking the web service.

Back at the Reference Properties, supply the key created in previous step to the csf-key property

Test your client and you will see that it will be able to pass the security policies of Fusion Applications and return a result.

With this approach will be able to attach and detach policies as required and change credentials as required without having to modify and redeploy your SCA.

  

Dynamically assign credentials in BPEL

Until now we have seen that we call any Fusion Applications web service that is exposed externally. However, setting security this way is still pretty static. In one of my projects I was facing the challenge to call multiple Fusion Applications environments which all have a different endpoint and of course different credentials. So I needed to be able to set the endpoint and credentials dynamically in BPEL. 

When trying to override the properties oracle.webservices.auth.username and oracle.webservices.auth.password in BPEL using bpelx:toProperty, this will be ignored. As always, looking for solutions, you stumble upon a blog someone else has written with the same issue. That is why all the credit goes to T.A. Nguyen for providing this solution. 

The solution is to use the java WS properties javax.xml.ws.security.auth.username and javax.xml.ws.security.auth.password, instead of the Oracle provided WS policies and properties.    

Start off by modifying the request xsd of the client to incorporate credentials and endpoint to be passed dynamically to the web service.

On the composite add the java WS properties to the web service bindings.

On the invoke activity assign the credentials and endpoint to the bindings properties.

Deploy your SCA and test it.