Implementing Data Security for IDCS-only users in Oracle Engagement Cloud - Part 1

August 9, 2019 | 4 minute read
Naveen Nahata
Cloud Solution Architect (A-Team)
Text Size 100%:

Problem Statement 

Implement data security in Engagement Cloud for users who do not exist in Engagement Cloud 

Introduction

Consider a use case where you want to create a VBCS portal for end users to submit loan applications or service requests which are stored in Engagement Cloud. You need to ensure data security such that the end users can create, update or view only their own data. 

Engagement Cloud offers strict data security at the user level. But you can potentially have millions of users whose applications or service requests you want to store in Oracle Engagement Cloud. Having such a large user base in Engagement Cloud may not make sense as it will affect the license cost. Since those end-users do not perform any engagement cloud core functionality, you would not want to pay for them.

So a solution is to use a service account with access to all the data and use that to make API calls from VBCS. However, this is not a secure solution because the end users can intercept REST API calls made from the client side app and get other user's data simply by modifying the payload.

This can be solved by a server-side proxy. Let us see how this solution will work.

Detailed Article

The high-level steps to build this solution are documented in this article along with a detailed explanation of how various flows should be implemented. Knowledge of Application Composer in Engagement Cloud, VBCS (or optionally another front end solution) and JavaScript (or another programming language to build a proxy) is required. A step-by-step guide to build this solution will be published in another article.

 

High Level Steps to build the solution

 

  • Create Consumer custom object in Engagement Cloud. This object will store the IDCS GUID of the end user or the loan applicants

  • Create LoanApplication custom object in Engagement Cloud. This object will contain a reference to the Consumer object.

  • Create a self service registration page which creates a user in IDCS and also creates a record in the consumer object pointing to IDCS GUID

  • Create a JavaScript proxy which will expose REST end points for /loanApplications (GET, POST and PUT) and /loanApplications/{id} (GET)

  • Add code to the proxy to verify and decode the IDCS access token. The proxy will extract the IDCS GUID from the token and make REST calls to Engagement Cloud custom object REST API with GUID as a filter

  • Create a VBCS app which consumes the REST endpoints exposed by the JS application. The VBCS app will act as end user portal and will pass the IDCS access token to the proxy

 

Engagement Cloud Data Model

 

The following image illustrates the data model in Engagement Cloud:

Data Model in Engagement Cloud

Consumer_c: This object stores the IDCS user, without a corresponding Engagement Cloud user. The IDCS_GUID links a consumer records with the corresponding IDCS user

LoanApplication_c: This object stores individual loan applications. It contains a reference to the Consumer record which also links to the IDCS User. Calls to REST API can use a query filter (q=IDCS_GUID='xxxx') to get records specific to an IDCS user.

 

User Self Registration Flow

 

The following image illustrates the User Registration Flow:

User Registration Flow

Explanation of the flow:

The end user access a custom self-registration page. 

The end user completes the required information and submits the form.

VBCS calls IDCS REST APIs to create a user. 

VBCS retrieves the GUID of the newly created user and creates a Consumer in Engagement Cloud

 

Create Application Flow

 

The following image illustrates the Create Application flow:

Create Application Flow

 

Explanation of the flow:

End user is authenticated to the VBCS application by IDCS.

When the end user submits the loan application, the VBCS app calls a POST on /loanApplications to the proxy, passing the access token in the Authorization header

The Proxy validates the token and extract the GUID of the end user from the token

The proxy finally calls Engagement Cloud rest api to create a loan application. The payload will include a reference to the consumer row in the Consumer custom object.

 

View Application Flow

 

The following image illustrates the View Application flow:

View Application FlowExplanation of the flow:

End user is authenticated to the VBCS application by IDCS.

The end user clicks on Account details. VBCS calls the proxy REST endpoint to get all loan applications (GET /loanApplications), passing the IDCS access token in the request header.

The proxy validates the token and extract the GUID of the end user from the token.

The proxy calls Engagement Cloud REST API to get all Loan Applications and uses a query parameter to filter loan applications related to the consumer which maps to the logged in user (q=IDCS_GUID='xxxx'). VBCS displays all loan applications related to the user.

The user clicks on a specific loan application to see details. VBCS calls the proxy REST endpoint to get a specific loan application (GET /loanApplications/{id})

The proxy validates the token and extract the GUID of the end user from the token.

The proxy calls Engagement Cloud REST API to get a single loan application and uses a query parameter to filter loan applications related to the consumer which maps to the logged in user (q=IDCS_GUID='xxxx'). VBCS displays all loan applications related to the user.

 

 


Previous Post

OCI Load Balancer Session Persistence Know-How

Manasi Vaishampayan | 4 min read

Next Post


Use Correlation to Implement Asynchronous Communication Between Oracle Integration Cloud Process and Integration

Siming Mu | 7 min read