Understanding App Gateway
App Gateway is a software appliance that enables you to integrate applications hosted either on a compute instance, in a cloud infrastructure, or in an on-premises server with IAM for authentication purposes.
App Gateway acts as a reverse proxy protecting web applications by restricting unauthorized network access to them. App Gateway intercepts any HTTP request to these applications and ensures that the users are authenticated with IAM before forwarding the request to these applications. App Gateway propagates the authenticated user's identity to the applications.
If the user isn't authenticated with IAM, then App Gateway redirects the user to the sign-in page for credential validation.
If you are using Cloud Gate, it is important that a user's name only contains the characters shown in Creating a User because the display name is sent as an HTTP header. If non-printable ASCII characters are used, Cloud Gate considers the request invalid and returns a 400 error.
Uses for App Gateway
Use App Gateway to:
-
Integrate enterprise applications hosted either on-premises or in a cloud infrastructure with IAM for authentication purposes.
For example, if you have a web application hosted on-premises or in a cloud infrastructure, you can integrate this application with any other cloud-based applications for single sign-on. Use App Gateway to integrate your web application with IAM, and then ensure that the other cloud-based applications use IAM as their authentication mechanism. All these applications make use of the single sign-on provided by IAM.
-
Expose intranet web applications to internet access.
If your web application is hosted and accessed over your intranet and you want to expose access to this application over the internet, use App Gateway to proxy any internet request and to require users to authenticate with IAM before accessing your intranet web application. In this case, you deploy App Gateway in your network DMZ while your application remains in the intranet zone.
-
Integrate with applications that lack a native authentication mechanism and don't support SAML federation, OAuth, or OpenID Connect integration methods.
If your application doesn't support the standards for authentication that IAM supports (SAML, OAuth, and OpenID Connect), and you can't use IAM's SDKs in your application, then you can use App Gateway to integrate your web application with IAM.
-
Integrate with applications that support the HTTP Header-based authentication.
For web applications that support HTTP Header-based authentication, the App Gateway integration method requires no change to the web application's source code. You must configure the application's authentication policies in IAM to add header variables in the request before App Gateway forwards the request to the application. By doing so, the application can identify the user authenticated with IAM.
How does App Gateway work?
The App Gateway is deployed within a customer’s infrastructure, regardless of whether the infrastructure is in the cloud, on-premises, or a hybrid one. It works as a reverse proxy, intercepting all requests from the client to the application. The App Gateway then verifies if a user is already logged in to IAM. If the user has logged in, then App Gateway adds header variables to the request so that the application being protected can access the header variable. The application trusts App Gateway has identified the signed in user in identity domain values and create the user session.
Ensure that the communication between App Gateway and application is secure to avoid changes in the header variable values before the request is sent to the application.
The following steps explain the form-based authentication flow between the web browser, App Gateway, and an enterprise application:
Step | Description |
---|---|
![]() |
In a web browser, a user requests access to an application through a URL exposed by App Gateway. |
![]() |
App Gateway intercepts the request, verifies that the user doesn't have a session with IAM, and then redirects the user's browser to the sign-in page. In step 2, if the user has a session with IAM, it means that the user has already signed in. If so, then an access token is sent to App Gateway, and then the remaining steps are skipped. |
![]() |
IAM presents the sign-in page or whichever sign-in mechanism has been configured for the domain. |
![]() |
The user signs in to IAM. |
![]() |
Upon successful authentication, IAM creates a session for the user and issues an access token to App Gateway. |
![]() |
App Gateway uses the token to identify the user. It then adds header variables to the request and forwards the request to the application. |
![]() |
The application receives the header information, validates the user's identity, and starts the user session. |
App Gateway intercepts any subsequent request to the application's protected resources. App Gateway identifies the user, adds header variables to the request, and forwards the request to the application.
To sign out, the user calls an application's logout URL. The App Gateway identifies the logout URL and redirects the user to the identity domain's OAuth log out endpoint (/oauth2/v1/userlogout
). After IAM signs the user out, IAM can redirect the user's browser to a URL of the application which can then remove the application's user session.
Workflow for Managing App Gateways
Use this list to help you work through the steps of creating and managing App Gateways.
Task | Additional information |
---|---|
From your knowledge of the application, what are the resources you want to protect with App Gateway. |
Uses for App Gateway |
For each application to be protected, create an enterprise app. Note: You must create an enterprise app for each application type, not for each application instance. |
Enterprise Applications |
Define the resources and the policies for the identified resources to be protected in enterprise app. |
Getting Started with Policies |
Register the App Gateway. | |
Define the host and port for the App Gateway. Note: This host and port is used to access the application when it is protected by App Gateway. The application's host:port become the origin server for the App Gateway. Update the application URL in the enterprise app to use the App Gateway host:port and the application URI. |
Configuring the App Gateway Server |
Define the App Gateway application where:
/ , if all the application resources are served from same origin. |
Assigning an Enterprise Application to App Gateway |
Use the registered App Gateway to set up and run the App Gateway instance. |
Set Up High Availability
Use a load balancer to achieve high availability for multiple instances of App Gateway.
If high-availability is a requirement to access your web application, you can have multiple App Gateways, configure each of them to integrate with IAM, and use a load balancer to balance the request among the App Gateway instances.
This architecture diagram shows the components required for high availability.
This architecture requires that you install and configure more than one instance of App Gateway. Each App Gateway instance is configured to link to the same IAM URL, and to use the same Client ID and client cecret from the App Gateway registration in IAM Console.
Use a load balancer to distribute request between the App Gateway instances.
Also, the load balancer must perform health checks by way of HTTP with HTTP keepalives
enabled for a duration that exceeds the health check interval. This prevents the load balancer from redirecting browser requests to an offline App Gateway instance.
The health check endpoint of App Gateway is /cloudgate/v1/about
.
Set up App Gateway
Download the App Gateway binary file, install the App Gateway server, register the App Gateway using the Console, configure the App Gateway server, assign an enterprise application, start the App Gateway server, and test the access to the application through App Gateway.
Any version of Windows server above 2012 R2 is supported. The recommendation is to use Windows Server 2016.
Using the Console
The App Gateway for Identity Cloud Service doesn't replace the App Gate for Identity Cloud Service. The App Gateway for Identity Cloud Service software is based on NGINX web server and is used to protect access of enterprise applications. The App Gate for Identity Cloud Service software is an OEM product that has similar but not the same features.
To install App Gateway on OCI, you need to upload the App Gateway virtual disk image file to a Bucket in Oracle Cloud Infrastructure, create a Custom Image using the App Gateway virtual disk image file, and then create a Compute instance based on this custom image.
Before creating a compute instance on OCI to run App Gateway, you need create a Virtual Machine Disk Image
(VMDK
) file using the App Gateway Open Virtual Appliance
(OVA
) file, and then upload this VMDK
file to OCI.
-
To create the
VMDK
file:-
Log in to the Windows server, and upload the App Gateway
OVA
file from your desktop to a working folder in the server. For example,c:\temp
. - Start the Oracle VM Virtual Box Manager software, and then select Import Appliance from the File menu.
-
Locate the
OVA
file on the Windows server, and then click Next. -
In the Import Virtual Appliance window, update the Name field with the value
App Gateway Server
. - To define a new MAC address to the App Gateway server network component, select Reinitialize the MAC address of all network cards.
- Click Import.
-
Verify
App Gateway server
is listed in the Oracle VM Virtual Box Manager.
-
Log in to the Windows server, and upload the App Gateway
-
To upload the
VMDK
file to OCI:
To create a compute instance on OCI to run App Gateway, you need to create a custom image from the App Gateway's Virtual Machine Disk Image
(VMDK
) file you uploaded to a bucket on OCI.
Ensure your OCI account has compartments, a virtual cloud network, and subnets previously set up.
Ensure you have selected a compartment in the IAM Console, before proceeding.
The components design must align with your OCI operational model. Contact your OCI administrator for more information.
Virtual Machine Disk Image
(VMDK
) file to a bucket in OCI and created a custom image using this VMDK
file, you can create a compute instance to run App Gateway.Ensure that you have a Security List configured so that you can connect to the My App Gateway Server
compute instance using a SSH client software such as PuTTY
. Contact your OCI administrator for more information.
To install App Gateway using Oracle VM Virtual Box, import the App Gateway Open Virtual Appliance
(OVA
) file in an Oracle VM Virtual Box, and then configure the App Gateway virtual machine to receive HTTP request.
To run App Gateway in a virtual machine, import the App Gateway Open Virtual Appliance
(OVA
) image file in virtual machine software such as Oracle VM Virtual Box.
The following procedure requires access to a Windows server as administrator. This server must have Oracle VM Virtual Box software installed.
-
Log in to the Windows server, and upload the App Gateway
OVA
file from your desktop to a working folder in the server. For example,c:\temp
. - Start the Oracle VM Virtual Box Manager software, and then select Import Appliance from the File menu.
-
Locate the
OVA
file on the Windows server, and then click Next. -
In the Import Virtual Appliance window, update the
Name field with the value
App Gateway Server
. - To define a new MAC address to the App Gateway server network component, select Reinitialize the MAC address of all network cards.
- Click Import.
-
Verify
App Gateway server
is listed in the Oracle VM Virtual Box Manager.
After you import App Gateway, a virtual disk image file (VMDK
) will
be created in the Windows server.
To locate this file, select App Gateway Server
in Oracle
VM Virtual Box Manager, click Settings, click
Storage, and then click the name that appears under
Controller: SATA in the Storage
Devices section. The location of the VMDK
file
appears in the Location field under
Information.
App Gateway can be deployed by using OVA or using Docker. Learn how to deploy the Oracle App Gateway Docker container.
Prerequisites
- Download the App Gateway docker image. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Settings and then Downloads.
- Create a wallet file containing the Client ID and Client Secret of the App Gateway that was created in the Admin Console. Name the wallet file cwallet.sso and copy it to the local folder so that the container can uptake the file. Note: The wallet tool can be downloaded from the IAM Console. In the IAM Console, expand the Navigation Drawer, click Settings, and then click Downloads.
- Install Docker (Command:
$ yum install docker-engine
). - Add the current user to the Docker group (Command:
$ sudo usermod -a -G docker $USER
).
Extract the Docker Image
.tar.gz
format, then you must use the following commands to extract the image before you can create the container. - Load the
.tar.gz
file to the local Docker registry. Command:$ docker load -i <.tar.gz file>
- Verify that you see the image in the local Docker registry. Command:
$ docker images
Create the App Gateway Container
Set the App Gateway Environment Variables
To run the App Gateway Docker container, the following environment variables must be set in the appgateway-env
file. Important: No validation is performed on these values. If you configure invalid values, App Gateway Docker container creation fails.
-
CG_APP_TENANT=<tenant name>
IDCS_INSTANCE_URL=<idcs instance url>
. The URL required to access the IAM instance.NGINX_DNS_RESOLVER=<resolver ip>
. Configure the nameserver found in the file/etc/resolv.conf
. The default value is127.0.0.1
.
Run Docker
The local folder is mounted as volume and is accessible within the Docker container.
The wallet file (which contains the Client ID and Client Secret) you created as a prerequisite (cwallet.sso
) must be copied to the local folder, so that the container can reference the file.
$ docker run -it -d
--name <container name>
--env-file <path to env file>
--env HOST_MACHINE=`hostname -f`
--volume <local folder>/cwallet.sso:/usr/local/nginx/conf/cwallet.sso
--net=host/<User-defined bridge name> <image name>
Example Container with Host Networking with No Port Mapping
If the port number configured for the App Gateway host is less than 1024, then you must use Bridge Networking for the Docker, along with the port mapping. See the Bridge Networking with Port Mapping command example below to run the Docker container.
$ docker run -it -d
--name appgateway
--env-file appgateway-env
--env HOST_MACHINE=`hostname -f`
--volume /opt/appgateway/cwallet.sso:/usr/local/nginx/conf/cwallet.sso
--net=host opc-delivery.docker.acme.com/idcs/appgateway:RELEASE-BUILDNUMBER
Example Bridge Networking with Port Mapping
The following is an example of Bridge Networking with port mapping (ports 80 to 65535).
Prerequisite: Before you use the Bridge Network configuration,
add/update iptables
to true
, in the file
/etc/docker/daemon.json
. This allows the Docker
daemon to edit the iptables filter rules required for port mapping.
$ docker run -it -p 80:9000 -d
--name appgateway
--env-file /home/<username>/dev/appgateway_pool/appgateway_env --env HOST_MACHINE=`hostname -f`
--volume /opt/appgateway/cwallet.sso:/usr/local/nginx/conf/cwallet.sso
--net=bridge-net idcs.docker.acme.com/idcs/appgateway: RELEASE-BUILDNUMBER
Note: Docker internally updates the iptables/firewalld with the routes for the port, when the above command is run.
Post-Requisite Container Step
- Configured SSL certificates must be copied to the location that is specified in Additional Properties. Go to Security, App Gateways, <Gateway>, Hosts, Additional Properties and note the location.
- Run commands like the following. Note: The location of the certificate depends on the location you specified in the App Gateways Host.
$ docker cp deploy/docker/nginx/build/test-config/certs/my-appgateway.cert appgateway:/scratch/docker/cloudgate/certs/my-appgateway.cert
$ docker cp deploy/docker/nginx/build/test-config/certs/my-appgateway.key appgateway:/scratch/docker/cloudgate/certs/my-appgateway.key
Find Out More
-
How do I know if my container was created successfully?
Run the command:
$ docker ps -a
and ensure that theSTATUS
is Up in the list corresponding to your container name. -
If the container STATUS shows exited, how do I check the logs to determine why the container was terminated?
Run the command:
$ docker logs <container name>
. This command prints the log messages, which contain the log messages printed by App Gateway. -
How to do edit the cloudgate.config file inside the container?
Run the command:
$ docker exec -it <container name> bash
.Run this command to access the container if the container is running with a Bash shell. Once inside the container, you can edit the files using Nano editor.
-
Can we print the access logs in JSON format?
Yes, you can print the access logs in JSON format. Add the lines below to the file/usr/local/nginx/conf/nginx.conf
, inside an HTTP block and then restart App Gateway.log_format jsonf escape=json '{"remote_addr": "$remote_addr", "remote_user": "$remote_user", "time": [$time_local], "request": "$request", "status": $status, "body_bytes_sent": $body_bytes_sent, "http_referer": "$http_referer", "user_agent": "$http_user_agent", "x_forwarded_for": "$http_x_forwarded_for"}'; access_log /usr/local/nginx/logs/access.log jsonf;
Note: You can edit the JSON fields that you’re interested in by removing or adding the NGINX variable.
Before installing the binary file for App Gateway that appears on the Downloads page, you must register your App Gateway using Console.
To register an App Gateway, you must add hosts and associate each host to an enterprise application your App Gateway will protect:
- In the Hosts pane, you define host identifiers. Each host identifier represents a domain name and port number App Gateway uses to proxy an enterprise application.
- In the Apps pane, you associate an enterprise application with a host identifier.
To register an App Gateway, you must be assigned to either the Identity Domain Administrator role or the Security Administrator role.
To start and stop App Gateway server and App Gateway agent, you can use scripts or the services installed in the server where your App Gateway runs.
start and stop the App Gateway server and agent using scripts provided in the server. Sign in to the App Gateway server and then run the following command:
When you start the App Gateway server, App Gateway contacts IAM to retrieve the port number you configured during the App Gateway registration in the IAM Console. The App Gateway server starts using this port number.
The App Gateway agent is responsible for synchronizing the App Gateway configuration (hosts and applications) from IAM to the App Gateway server.
To check the running status of the App Gateway server, run the following command:
/scratch/oracle/cloudgate/home/bin/cg-status
To check the running status of the App Gateway server, run the following command:
/scratch/oracle/cloudgate/home/bin/cg-status
You can use IAM to activate and deactivate app gateways.
-
Deactivating an App Gateway prevents IAM from working with the App Gateway software.
-
Activating an App Gateway enable IAM working with the App Gateway software.
A green check mark


- Open the navigation menu and click Identity & Security. Under Identity, click Domains.
- Select the identity domain you want to work in and click Security and then App gateways.
- Click the name of your App Gateway.
- Click Activate.
-
In the Confirmation window, click
OK. The status of each App Gateway changes from
deactivated
to activated
.
- Open the navigation menu and click Identity & Security. Under Identity, click Domains.
- Select the identity domain you want to work in and click Security and then App gateways.
- Click the name of your App Gateway.
- Click Deactivate.
-
In the Confirmation window, click OK. The status of each app gateway changes from activated
to deactivated
.
After you configure the App Gateway server to communicate with your IAM instance, and start the server, test access to your enterprise application.
The following diagram provides an example of how App Gateway and IAM interact when the user browser sends an HTTP request to an application resource through App Gateway.
Because App Gateway proxies your web application, use the App Gateway base URL to access the application instead of the application actual URL.
/myapp/private/home
page.Modifying an App Gateway in IAM includes:
-
Changing the name or description of the App Gateway
-
Show or regenerate the client secret
-
Add or remove hosts
-
Add or remove enterprise applications
- Open the navigation menu and click Identity & Security. Under Identity, click Domains.
- Select the identity domain you want to work in and click Security and then App gateways.
- In the App Gateways page, select the check box for each App Gateway that you want to remove.
- Click Remove.
- In the Confirmation window, click OK.
How App Gateway Logout Works
Users can log out from the applications protected by App Gateway using two different mechanisms: App Gateway Log out URL or by calling a resource protected by a logout authentication method.
Use App Gateway logout URL
App Gateway provides a central logout URL which can be used to log the user out from the single sign-on provided by IAM. Any call to this endpoint triggers the logout process. After the user is logged out, then any subsequent access to a protected application resource will require the user to sign in to IAM again.
- postlogouturl: The URL of a post-logout landing page. This value must be URL-encoded. If the parameter isn't specified, then App Gateway redirects the user browser to the Logout URL specified in the Console's Session Settings.
- state: This is an optional parameter to be used by the enterprise application, after the logout process finishes.
Syntax
http(s)://<appgateway_host>:<appgateway_port>/cloudgate/logout.html?postlogouturl=<url_encoded>&state=<state_value>
Log out Endpoint With Parameters
If the App Gateway base URL is https://myappgateway.example.com:4443
, then use the following URL to log the user out from the single sign-on: https://myappgateway.example.com:4443/cloudgate/logout.html?postlogouturl=http%3A%2F%2Fwww.oracle.com&state=123
Use Resource Protected by Logout authentication method
You can create a resource in your enterprise application and configure an authentication policy for this resource using Forms+Logout authentication method. When the user accesses this resource, App Gateway invokes the log out process and logs the user out from the single sign-on provided by Identity Domains.
Syntax
http(s)://<appgateway_host>:<appgateway_port>/<logout_resource>
Resource Protected by Logout authentication method
If you created /myapp/logout
resource in your enterprise application, and assigned Forms+Logout as Authentication Method for this resource in Authentication Policy section, then when users access the URL https://myappgateway.example.com:4443/myapp/logout
, they are logged out from the single sign-on provided by IAM.
Run App Gateway in SSL mode on port 1024
or lower
You can configure App Gateway to run in SSL mode on port number 1024
or lower.
To run your App Gateway server in Secure Sockets Layer (SSL) mode, you need to have a valid certificate.
Using the Console
Enable your App Gateway server to run on port 443 in SSL mode.
Generate a valid certificate to your App Gateway to run on SSL mode, and copy the certificate file and the certificate key file to your desktop.
setup-cloudgate
script finishes, the App Gateway server
starts automatically. You can access any application protected by your App Gateway using
HTTPs, App Gateway domain, and port number 443
(default HTTPs port).
For example, https://myappgateway.example.com/myapp/index
443
, you need to start and stop App Gateway server and agent using sudo
command.How to Enable and Access App Gateway Logs
App Gateway provides log files to help you monitor App Gateway's behavior. Learn how to configure and access these log files.
Logs are enabled by default. To disable logs or change the log levels of the App Gateway server, sign in to the server, edit the /usr/local/nginx/conf/cloudgate.config
file, and then under the general
section, change the value of the logLevel
attribute, and then save the file.
"general":{
"disableAuthorize":false,
"logLevel":"warn",
"logFolder":"",
"policyMode":"gateway",
"policyRefreshTime":300,
"policyStaleTime":3600,
"policyExpiryTime":604800
}
Values for the
logLevel
attribute are: off | crit | security | config | fail | warn | info | trace1 | trace2
| trace3
.By Default, the log files are in the /usr/local/nginx/logs
folder. If you want to change the default log folder, then update the value of the logFolder
attribute under the general
section of the /usr/local/nginx/conf/cloudgate.config
file.
To change the log level for the agent service of the App Gateway, modify the
/usr/local/nginx/conf/cloudgate.config
file, and set the
logLevel
and logFolder
attributes under the
agentConfig
section as follows:
trace3
and the log folder to
/tmp
, update the /usr/local/nginx/conf/cloudgate.config
file with the following values, and then save the
file."agentConfig":{
"pollIntervalSecs":60,
"daemon":true,
"logFolder":"/tmp",
"logLevel":"trace3"
}
The log level and log folder changes take effect next time you start App Gateway.
App Gateway is based on a NGINX
Server. The following NGIX
native log files are in the /usr/local/nginx/logs/
directory:
Log File | Description |
---|---|
access.log
|
NGINX Native access log contains
information about all HTTP requests received by
NGINX , and by App Gateway. |
error.log
|
NGINX Native debug log. |
nginx.pid
|
Contains the NGINX Server process
ID number. |
The following App Gateway specific log files are in the /usr/local/nginx/logs/
directory:
Log File | Description |
---|---|
cg-trace-main.log
|
App Gateway main log file. |
cg-trace-policy.log
|
Logs information about a policy refresh, when App Gateway contacts IAM. |
cg-trace-session.log
|
Logs information about the sessions created and handled by App Gateway. |
cg-trace-token.log
|
Logs information about the access tokens received by App Gateway. |
cg-trace-agent.log
|
Agent logging file. |
cg-trace-init.log
|
Contains information about the initialization process. |
Upgrading and Patching App Gateway
If you are performing a patch upgrade, the App Gateway patch is installed when you run the upgrade script. As patches become available they are listed on the Downloads page, which is available from the Settings page for an identity domain.
App Gateway Installed as VM
App Gateway versioning uses the following convention: <release
version>-<major version>.<minor version>.<build
number>
. For example, App Gateway version
19.3.3-1.0.1
, means release 19.3.3
, major
version 1
, minor version 0
, and patch version
1
.
If you have multiple App Gateway instances, then repeat the following procedure for each App Gateway server.
App Gateway Installed as Docker Container
To upgrade to a new App Gateway version, delete the existing container and re-create the container with a new version of the image. The wallet files are automatically used by the container, provided the files are not deleted in the local folder, and the same local folder is used for the volume mount.
Upgrade Path for High Availability Deployments Using App Gateway Docker Image
Cloud Gate has updated its Block Cipher mode of operation which changes how data is encrypted. The change is being rolled out over three patch releases, R1, R2, and R3 so that you can upgrade without service interruptions.
This upgrade path only applies when you have enabled high availability and are using multi-node deployments.
If you are using high-availability with multiple App Gateways and using a load balancer, you must follow a specific upgrade path. If you perform the upgrades in the wrong order, or miss an upgrade, then you might have problems, such as:
- Unexpected redirects to IAM login, because of Cloud Gate failing to decrypt its session cookie.
- Failures after login, because of Cloud Gate being unable to decrypt its state cookie or the data returned by IAM.
- Incomplete logouts, because of Cloud Gate being unable to decrypt the data sent by IAM.
R1 Patch Release
The R1 patch release encrypts using the old Block Cipher mode of operation, but it adds fail over logic to Cloud Gate's decryption operation. If Cloud Gate fails to decrypt using the current Block Cipher mode of operation, it tries again using the new Block Cipher mode of operation. This fail over allows Cloud Gate to maintain backward compatibility with session data created by older Cloud Gate clients, and support decrypting new session data created by Cloud Gate clients running the R2 or R3 patch release of this upgrade path.
R2 Patch Release
The R2 patch release encrypts and decrypts using the new Block Cipher mode of operation. Decryption supports failing over using the old Block Cipher mode of operation. The R2 patch release is not backward compatible with Cloud Gate clients from before the R1 patch release. These older Cloud Gate clients cannot decrypt the new session data created by R2 release Cloud Gate clients.
R3 Patch Release
The R3 patch release removes all support for the old Block Cipher mode of operation. An existing deployment must upgrade from the R2 patch release to avoid decryption issues.
Patch Release Downloads
The table shows how the patch release relates to the Cloud Gate release, and to the App Gateway Docker image. Open a support ticket and ask to have the appropriate patch made available to you. See Open a Support Ticket.
Only the patch release downloads for R1 and R2 are currently available. When R3 is available, this page will be updated.
Patch Release | Cloud Gate Release | Cloud Gate Build | App Gateway Docker |
---|---|---|---|
R1 | 22.1.49 | 22.1.49-2201171005 | 22.1.49-2201040708 |
R2 | 22.2.63 | 22.2.63-2203141550 | 22.2.57-2202180045 |
R3 | To be announced | To be announced | To be announced |
Configuration Override
You can disable the encryption change in Cloud Gate using the configuration setting:encryptWithGcm
. This is a boolean setting that is set to false
to disable the encryption change.
After making the change, restart the NGINX server. For example, in a WTSS deployment, use
/u01/data/idcs-cloudgate/bin/cg-reload.
Example of a cloudgate.config file
{
"cloudgateConfig" : {
"version" : "2.9",
"comment" : "Sample Cloud Gate Configuration (HTTPS)",
"enabled" : true,
...
"general" : {
"encryptWithGcm": false,
...
},
...
}