Oracle Soa Ssl Mutual Auth With Third Party Via Curl

White Paper

Oracle Soa Ssl Mutual AuthWith Third Party Via Curl

©2022 Jade Global Inc. All rights reserved

TM

Introduction

Business Requirements

Challenge

Solution Approach

Design Architecture

Technical Details

1

3

4

5

6

7

Table of Contents

White Paper

Introduction

©2022 Jade Global Inc. All rights reserved1

Oracle Soa Ssl Mutual Auth With

Third Party Via Curl

Enabling security on any transaction between applications becomes imperative when the applications are remotely located. Oracle SOA as a middleware platform provides

these security control features including “Basic Authentication”, “Mutual Authentication” over SSL/TLS.

Example of E&O calculation:

Basic Authentication - requires the messages to carry username and password along with the actual business data.

Mutual Authentication over SSL/TLS - Authentication with a higher level of security logistics that includes Identity of the client, Trust, Certificate Authority.

It is only fair to say, trust needs to be established between any two entities before they start to exchange the information. This potential of mutual trust between two

applications remotely held is established via 1-way SSL or a 2-way SSL.

On Oracle SOA, this configuration usually includes importing the server’s certificates into its Keystore and to configure if SOA is making a 1-way SSL or a 2-way SSL.

White Paper




SSL Configuration Methods

1. 1-way SSL

Client application makes https protocol for SSL handshake with the server.

Server acknowledges the request and sends Public Certificate & Public Key

This Public Certificate should be the same as the one that’s stored in the keystore.

Client validates the above step and will send the session’s public key.

Server application decrypts this public key and starts the encrypted session.

Once the session begins, data will start to transfer between the applications.

2. 2-way SSL

Client application makes https protocol for SSL handshake with the server.

Server acknowledges the request and sends Public Certificate & Public Key

This Public Certificate should be the same as the one that’s stored in the keystore.

Client validates the above step and will send the session’s public key along with the CA certificates.

Server validates this Client Certificate from CA.

Once this handshake is completed, session begins, and transfer of data will start between both the

applications

White Paper

Business Requirements




Integrating data from a Staging table to a Cloud application that is REST enabled. This integration must be confined to defined mutual authentication and establishing

security logistics is a key feature of the requirement.

Applications Involved:

Client Application : Staging Table

Target Application : REST enabled Web Service

Integration Application : Oracle SOA

White Paper

Challenge




Target application not accepting the public/private certificates from Client when a handshake is being tried to establish.

White Paper

Solution Approach




Traditional Solution:This usually is an elementary process to invoke the REST webservice with JSON payload from SOA Integration Component, and the certificates of the Target application

imported into SOA-Infra’s keystore. 2-way SSL enabled configuration will allow mutual authentication and data should be flowing smoothly on a sunny day. As the SSL

session was not being established with the target application, below solution was implemented.

Proxy Solution:

Solution is designed wherein the integration component will take complete control on establishing handshake, opening an SSL session and transferring the data payload.

This will bypass the SOA-Infra SSL configuration and also attains the integration by not compromising on SSL Mutual Authentication standards.

This orchestration is achieved by embedding CURL into SOA integration. Through CURL, it is made evident to have control on all the required functionalities of -

FTP/SFTP, http/https and drive the integration as desired.

White Paper

Design Architecture




The below image provides a snapshot of all components involved in the integration:

White Paper

Technical Details




Pre-requisite – Place all the certificates needed for mutual authentication into a directory on the client’s side, ie in this case will be on a local server. These certificates will be persistent in

this directory.

SOA will poll the data from the Staging table and generate a file *.json format.

SOA will write this *.json file via FTP into the same directory in which mutual auth certificates are already present.

CURL will be executed within SOA Integration to aggregate the certificates: Client-Key, Client-Root, Client CA . CURL then invokes the target’s REST Service by using

POST along with the payload in the *.json file.

Both the client and target applications validate the mutual authentication and client starts to invoke the target’s REST method to transfer the data.

In response, the target application will send an acknowledgment with the success/failure of integration of data present in JSON payload.

SOA will capture this response and will do the proceedings accordingly.

About Jade Global

©2022 Jade Global Inc. All rights reserved

Jade Global is a Cloud-focused IT services partner specialized in enterprise business application implementations, integrations, software product engineering,

consulting, technology advisory, testing, and managed services. Jade is an Oracle Platinum Cloud Select Partner, Salesforce Silver Partner, Dell Boomi Select

Implementation Partner, and Service Now Silver Partner. Our additional global alliances with NetSuite, Microsoft and Zuora allow us to design robust solutions for

a variety of industries and needs. We are headquartered in San Jose, California with East Coast headquarters in Philadelphia. Jade has been recognized as one

of the fastest-growing companies in North America by Inc. 5000 for 9 consecutive years.

www.jadeglobal.com [email protected]

Documents

Oracle Soa Ssl Mutual Auth With Third Party Via Curl