Cloud Application Gateway

The Cloud Application Gateway (CAG) solution provides a secure and reliable bridge connecting the Omada Identity Cloud with systems hosted on-premises or in external cloud environments. It is designed to operate using outbound-only secure connections, simplifying deployment by removing the need to modify inbound firewall rules.

CAG enables key platform operations such as data import, provisioning, schema discovery, and live connection testing. Communication between CAG and Omada Identity Cloud is protected through mutual authentication, ensuring both endpoints verify each other before exchanging data.

The CAG supports automatic over-the-air (OTA) updates, allowing the service and its connectivity components to stay up to date with minimal manual intervention. It is currently supported on Windows-based environments.

This setup helps extend Omada Identity Cloud capabilities into hybrid IT landscapes while maintaining secure and controlled integration.

Core capabilities

The Cloud Application Gateway provides the following capabilities:​

• Performing import from source and target systems
• Performing provisioning jobs and tasks​
• Handling provisioning claims
• Support for all connectors
• Thresholds handling​
• Testing connection for a given system within system onboarding​
• Performing a schema discovery for connectors/collectors providing that capability​
• Previewing queries and mappings within system onboarding
• Connecting to the customers' infrastructure without the IPSec tunnel
• Connecting to the customers' infrastructure without the Omada Identity Cloud components directly connecting to the CAG through network connection
• Easy onboarding of the CAG to the customers' Omada Identity Cloud instances
• Automated OTA (over-the-air) upgrades of the CAG and Connectivity Packages
• Asymmetric authentication between the CAG and Omada Identity Cloud

Comparison between the CAG and IPSEC solution

This section provides a comparison between the Cloud Application Gateway and the IPSec Site-to-Site tunnel approach for connecting your systems to Omada Identity Cloud. The table below highlights key differences in connectivity capabilities, deployment flexibility, and security features, helping you determine which option best fits your organization's requirements. Use this as a quick reference when planning your system integration strategy.

Capability	CAG solution	IPSEC solution
Cloud systems	✅	✅
Direct on-premises systems	✅	❌
On-premises systems via IPSec S2S tunnel	❌	✅
Zero Knowledge Encryption with User-Controlled Keys	✅	❌
Customer infrastructure deployment model	✅	❌
Custom-developed connectivity	✅	❌
Support for PowerShell scripts	✅	✅

Architecture overview

This diagram illustrates the end-to-end architecture of the Cloud Application Gateway, enabling secure and scalable import and provisioning of identities between the Omada Identity Cloud and customer-managed target systems.

Omada Cloud (Top Section)

The cloud layer includes the core multi-tenant services responsible for orchestrating identity processing, provisioning, and communication:

• ES (Enterprise Server) and ROPE (Role and Policy Engine): Handle orchestration logic and business rules.
• Provisioning Service: Executes provisioning logic and communicates with target systems via CAG.
• OPS Database: Stores provisioning-related data.
• Import Service API and Provisioning Service API: Provide interfaces for CAG components to connect securely to the cloud.
• Processing Component: Manages identity processing jobs centrally in a multi-tenant environment.

Customer Infrastructure (Bottom Section)

This section shows how CAG components are deployed on-premises within the customer’s infrastructure to enable secure, outbound-only communication with the Omada Identity Cloud.

Import CAG

• Import Worker Service: Manages the scheduling and orchestration of import processes.
• Import Worker Processes: Execute data import tasks from target systems (e.g., Active Directory, HR systems).
• Communication: Data is retrieved from Target Systems (read-only access) and sent via HTTP/WebSocket to the cloud's Import Service API.

Provisioning CAG

• Provisioning Worker Service: Launches and manages the execution of provisioning jobs.
• Provisioning Worker Processes: Perform write operations to target systems based on identity lifecycle events (e.g., account creation, access removal).
• Communication: Writes are executed locally, while updates and status are pushed to the cloud's Provisioning Service API.

Secure Communication

All communication between the on-premises CAG components and the cloud services occurs via HTTPS or WebSocket, ensuring secure, encrypted data flow without the need for inbound firewall rules or VPN tunnels.

Provisioning jobs

The CAG solution utilizes the Provisioning API, which is a stand-alone, multi-tenant web application serving the provisioning workers. The Provisioning API reads and writes directly to the OPS database. Authentication can utilize the managed identity or the OAuth token, and all calls require ProvisioningWorker authorization.

With the shift to a decentralized architecture, components are divided to work between Omada Identity and customer infrastructure, such as the Worker Service and Worker Process.

Worker Service

The Worker Service is a core .NET process responsible for starting and restarting the Worker Process. It coordinates and oversees worker processes that are initiated for each of the configured target systems.

A list of the configured systems is received from the Provisioning API at the startup of the Worker Service, allowing it to initiate worker processes for those systems. The Worker Service monitors, at scheduled intervals, whether any changes have been introduced to the system configuration. Detecting new configurations results in the Worker Process restarting to account for the changes. The same behavior is applied when the Worker Process stops for any reason.

The ongoing processes are overseen using the heartbeat mechanism. Each call for work forwarded to the API is recorded, with the API providing endpoint allowing to measure the heartbeat. This metric allows the Worker Service to determine if the heartbeat exceeds the configured threshold and the process requires a restart.

Worker Process

The worker process is part of the solution that is hosted on the customer infrastructure and is responsible for the actual provisioning. There is one Worker Process running for each of the configured target systems. In a two-way communication between Worker Process and Provisioning API, provisioning jobs are pulled from the Provisioning API, performed and afterwards the status is sent back.

Disclaimer

For customers not using the CAG solution, the Worker Process runs on the L2 data link layer.

The provisioning configuration for the target system is received from the Provisioning API during the Worker Process startup.

Thresholds

The Provisioning API utilizes the provisioning service to implement provisioning thresholds. After a complete task status is received, the Provisioning API invokes the threshold service.

When the Worker Process checks for queued provisioning jobs, the Provisioning API verifies with the threshold service if the threshold was violated. Exceeded thresholds prevent returning jobs to the worker, except for high-priority ones, and this is reflected in the OPS database.

Provisioning claims

Legacy solution

In the legacy solution, provisioning jobs are actively monitored to ensure their status is up-to-date. When a job's status changes, a provisioning claim is sent to the Enterprise Server (ES) to reflect the update. Additionally, if the system detects that a notification for a specific job is missing, a provisioning claim is automatically triggered to address the discrepancy and maintain synchronization between the systems.

The CAG solution inherits the monitoring of the missing notifications part of the legacy solution. The purpose is to prevent the communication between the Provisioning API and the ES.

Schema discovery

Legacy solution

In the legacy solution the schema discovery functionality is only supported for a couple of connectors:

• SOAP
• SQL

In the centralized solution it is a part of the gateway service responsible for test connection.

With the CAG solution, schema discovery capabilities are moved to the Task Service component, providing a generic way of performing extraordinary jobs, for example testing connection.

Over-the-air update process

The Cloud Application Gateway consists of the following components:

• Omada Identity Import Worker Service

• Omada Identity Provisioning Worker Service

• Connectivity Packages

The CAG performs regular, scheduled checks for components' new versions. Whenever they are available, the update process is conducted automatically on any local CAG instance.

The update process is not initiated until all active jobs are completed. After the process has concluded, the Worker Service is restarted.

For more information on the OTA process, go to the Configuring over-the-air upgrade section.

Heartbeat mechanism

The CAG includes a built-in heartbeat mechanism that regularly verifies the operational status of its components to ensure continuous availability and appropriate failure detection.

The heartbeat checks are performed at configurable intervals and allow to identify:

• Service unavailability
• Unexpected shutdowns
• Performance degradation signals

System heartbeats

In the Operations dashboard you can find the status of systems, workers, and import services.

The widget displays the current status. By selecting an entry from the list, you can access detailed information, for example, the last date the system status was recorded as alive.

For more information on how to set up the heartbeat mechanism, go to the Configuring heartbeat mechanism section.

Security

The import and provisioning operations in the CAG (Cloud Application Gateway) solution require authentication with an OAuth token obtained in process based on an asymmetric encryption.

The authentication uses an OAuth token obtained by the workers from the COPS API.

The principle is that a pair of keys, public and private, is registered. They can be either generated by workers or come from a provided PFX certificate.

In the initial run of the worker one-time password is used to generate the public key and private key. With the successful registration of the public key in the COPS API, the private key is then stored in the configured location.

Generating OAuth token

Once the public key is registered, the following process takes place to generate an OAuth token.

1. The worker requests an epoch token from the COPS API.
2. COPS API returns the epoch token.
3. Workers send the client ID and the epoch token signed with the private key and requests an OAuth token.
4. COPS API validates signatures with the registered public key and returns the OAuth token.

note

For security reasons, end users cannot unregister the public key from the COPS API. If necessary, create a support ticket requesting a public key change.

For information on setting up security, go to the Configuring security section.

Deployment recommendations

As best practice, deploy the Cloud Application Gateway in its own VLAN. Allow it to access only the necessary services and ports that are managed by Omada Identity Cloud. CAG operates in an inside-out manner, it initiates all connections.

The mandatory CAG ports and endpoints are tcp/443 to the following endpoints:

• https://dz-XXXX-YYY-wa-ci.omada.cloud
• https://dz-XXXX-YYY-wa-is.omada.cloud
• wss://dz-XXXX-YYY-wa-is.omada.cloud

where:
XXXX = Delivery Zone Identifier (that is, 0501)
YYY = Delivery Region Identifier (that is, ceu)

Migration steps from IPSec to Cloud Application Gateway

If you are an existing Cloud customer and would like to replace the current IPSEC connection with the Cloud Application Gateway, we recommend trying it out first in a non-productive environment, please see below for the steps involved.

To begin with, you need to contact Omada Support by submitting a ticket to express your interest in migrating to the Cloud Application Gateway. Make sure to specify for which environment you are requesting this migration. Once your request is received, our team will get in touch to agree on a suitable maintenance window.

Upon the completion of the migration, you will notice that the tabs Onprem Connection and DNS Forwarders will no longer be available in the Cloud Management Portal. Instead, a download link will be provided for you. At this point, you can proceed with the installation and configuration steps as mentioned earlier.