Access Flow
This document does not explain the full access flow of the Merchandising Cloud Service, but instead focuses on the high level aspects of this data flow that relate to security.

Merchandising Cloud Service Suite is deployed on a Kubernetes cluster. Each application resides in an appropriate tier and each tier resides in its own subnet. Communication between tiers within the Merchandising Cloud Service is limited by subnet ingress security lists.
To reduce attack surface, access to the Merchandising Cloud Service from the open internet is very limited.
-
Business Users (via web browser) and external web service endpoints access application over https/443 (1, 1A). Firewall and load balancer in the DMZ route to the customer tenancy via reverse proxy forward to WTSS (3). WTSS forwards (4) unauthenticated requests to the customer's IDCS or OCI IAM tenancy via NAT Gateway (4A). IDCS or OCI IAM sends authentication HTML content to the end user (IDCS or OCI IAM Logon page) (5). On successful AuthN, WTSS sends a call to the reverse proxy ingress controller, which routes to the appropriate application component (6).
-
Pre Authenticated Request (PAR) service calls can drop/collect files from Object Storage (2).
Access to the underlying DBaaS is only available via the application M-Tier (67). The M-Tier is able to get and place files into object storage (8), which in turn allows the exchange of files with the Retailer (2). Both outbound web service traffic (811) and replication of data (912) are routed through the outbound proxy in the DMZ.
A subset of Oracle Retail AMS has very limited access to the underlying M-Tier (15). This access is limited to a small subset of Oracle employees as described in Oracle's Cloud Hosting and Delivery policy.
https://www.oracle.com/assets/ocloud-hosting-delivery-policies-3089853.pdf