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.

Note

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.

shows how the application, App Gateway, the identity domain, and the user browser interacts when a user tries to access any application resource but the user isn't signed in to an identity domains

The following steps explain the form-based authentication flow between the web browser, App Gateway, and an enterprise application:

Step Description
Callout 1 In a web browser, a user requests access to an application through a URL exposed by App Gateway.
Callout 2

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.

Callout 3 IAM presents the sign-in page or whichever sign-in mechanism has been configured for the domain.
Callout 4 The user signs in to IAM.
Callout 5 Upon successful authentication, IAM creates a session for the user and issues an access token to App Gateway.
Callout 6 App Gateway uses the token to identify the user. It then adds header variables to the request and forwards the request to the application.
Callout 7 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.

Set up App Gateway

Registering 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:
  • The mapping of the enterprise app you created
  • The App Gateway host
  • and the application origin server
The resource prefix can be /, 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.

Start and Stop App Gateway

Activate and Deactivate App Gateway

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.

App Gateway Load Balancer Diagram

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

Downloading and Extracting the App Gateway Binary File
The App Gateway binary file you download from the IAM Console is a compressed (.zip) file. This file contains an Open Virtual Appliance (.ova) file which you use to install the App Gateway server.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Settings and then Downloads.
  3. In the Downloads page, click Download for App Gateway for Identity Cloud Service.
  4. Save zip file to a local location, and extract the content of the zip file you downloaded to a location on your desktop. For example, c:\temp.
    The c:\temp\app-gateway-<version>.ova file is created .
Note

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.

Install App Gateway on OCI

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.

Uploading the App Gateway VM disk image file to an object storage bucket in OCI

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.

  1. To create the VMDK file:
    1. 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.
    2. Start the Oracle VM Virtual Box Manager software, and then select Import Appliance from the File menu.
    3. Locate the OVA file on the Windows server, and then click Next.
    4. In the Import Virtual Appliance window, update the Name field with the value App Gateway Server.
    5. To define a new MAC address to the App Gateway server network component, select Reinitialize the MAC address of all network cards.
    6. Click Import.
    7. Verify App Gateway server is listed in the Oracle VM Virtual Box Manager.
  2. To upload the VMDK file to OCI:
    1. Open the navigation menu and click Storage. Under Object Storage, click Buckets.
    2. Select the compartment where the bucket is to upload the image. Click Create Bucket, then click Create in the Create Bucket dialog.

      Contact your OCI administrator for more information about which compartment to create buckets.

    3. On the Bucket Detail page, click Upload Object in the Objects section.
    4. Click select files to browse and open the App Gateway's VMDK file, and then click Upload Objects.
    5. After the file uploads, click Close.
    6. Click the menu on the right for your object entry, and then record the URL Path (URI) value.
Creating a Custom Image in OCI Based on the App Gateway VM disk Image File

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.

Note

The components design must align with your OCI operational model. Contact your OCI administrator for more information.
  1. Open the navigation menu and click Compute. Under Compute, click Custom Images.
  2. Select the same compartment where you uploaded your VMDK file, and then click Import Image.
  3. In the Import Image dialog box, enter or select the following values, and then click Import Image.
    • CREATE IN COMPARTMENT: Select the compartment to import the image. The compartment must be the same where your compute instance is created.
    • NAME: App Gateway Custom Image
    • OPERATING SYSTEM: Select Linux.
    • OBJECT STORAGE URL: Enter the URL path you recorded after you uploaded the VMDK file.
    • IMAGE TYPE: Select VMDK.
    • LAUNCH MODE: Select EMULATED MODE.
    Wait until the custom image creation finishes.
Creating a Compute Instance using App Gateway's Custom Image
After you uploaded the App Gateway's 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.
  1. Open the navigation menu and click Compute. Under Compute, click Instances.
  2. Click Create Instance.
  3. In the Create Compute Instance page, enter My App Gateway Server in the Name your instance field, and then click Change Image.
  4. In the Select an Image dialog, select My Images, then select Custom Images. Select the appropriate compartment, select App Gateway Custom Image, and then click Select Image.
  5. In the Add SSH Key section, add a public SSH key, by either uploading a public key file or pasting the public key value in the SSH Key field.
    See Creating an SSH Key Pair Using PuTTY Key Generator section in Managing Key Pairs on Linux Instances.
  6. In the Configure networking section, select a compartment in Virtual cloud network compartment.

    If your compartment doesn't have virtual cloud network configured, then enter App Gateway VCN as Name in the New virtual cloud network section. If your compartment has virtual cloud network configured, then select the values for Virtual cloud network, Subnet compartment, and Subnet in which your compute instance will be created.

    Note

    The component design must align with your OCI operational model. Contact your OCI administrator for more information.
  7. Click Create, and wait until your compute instance is provisioned and running.
  8. Record the value of the Public IP Address assigned to this compute instance.

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.

Install App Gateway Using Oracle VM Virtual Box

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.

Importing the Open Virtual Appliance Image File in VM Software

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.

  1. 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.
  2. Start the Oracle VM Virtual Box Manager software, and then select Import Appliance from the File menu.
  3. Locate the OVA file on the Windows server, and then click Next.
  4. In the Import Virtual Appliance window, update the Name field with the value App Gateway Server.
  5. To define a new MAC address to the App Gateway server network component, select Reinitialize the MAC address of all network cards.
  6. Click Import.
  7. 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.

Configuring Port Forwarding Rules
Create a port forwarding rule to allow the requests received by the Windows server hosting the App Gateway virtual machine to be forwarded to the App Gateway server.
  1. In the Oracle VM Virtual Box Manager software, select the App Gateway server, and then click Settings.
  2. Select Network on the left menu, expand Advanced, and then click Port Forwarding.
  3. In the Port Forwarding Rules window, click Adds new port forwarding rule icon, configure a rule to forward the requests from the host port to the guest port, and then click OK.
    For example, if your App Gateway is configured to use port 4443, then enter 4443 in both Host Port and Guest Port columns.

    The port number must be the same as the port value that you provided during App Gateway registration.

  4. In the Port Forwarding Rules window, click Adds new port forwarding rule icon, configure a rule to forward the requests from the host port 22 to the guest port 22, and then click OK.
    This enables you to use a SSH client such as PuTTY to sign in to the App Gateway server later.
  5. In the Port Forwarding Rules dialog box, click OK.
  6. In the App Gateway Settings dialog box, click OK.
  7. Select the App Gateway server, and then click Start.
Deploy the Oracle App Gateway Docker Container

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

If the Docker image is in .tar.gz format, then you must use the following commands to extract the image before you can create the container.
  1. Load the .tar.gz file to the local Docker registry. Command: $ docker load -i <.tar.gz file>
  2. 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 is 127.0.0.1.

Run Docker

Use the following command to run Docker.
Note

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

The following is an example of Host Networking with no port mapping. This is only for port numbers greater than 1024.
Note

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

If the host is configured as HTTPS, the following extra steps are required to copy the certificates to the container.
  1. 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.
  2. 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 the STATUS 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.

Registering App Gateway

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.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Security and then App gateways.
  3. Click Add.
  4. In the Details pane, specify the name of your App Gateway, and then click Next (>).
  5. In the Hosts pane, click Add.
  6. In the Add Host dialog, provide a name in the Host Identifier field.
  7. Enter the Host and Port values that the App Gateway server will respond to HTTP requests.
    The port number you provide in this step is used by the App Gateway server to respond to HTTP requests.
  8. To have your App Gateway listen to HTTP requests in secure mode (HTTPS), select the SSL Enabled check box. Otherwise, clear this check box and your App Gateway will listen to non-secure HTTP requests only.
  9. If you select the SSL Enabled check box, then populate the Additional Properties text area with the following values to specify the certificate key pair the App Gateway server will use, protocols, and ciphers for SSL:
    ssl_certificate /usr/local/example.com.rsa.crt;
    ssl_certificate_key /usr/local/example.com.rsa.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;

    The /usr/local/example.com.rsa.crt is the full path of a certificate file in the App Gateway server. The /usr/local/example.com.rsa.key is the secret key of that certificate file. You must upload both files to the App Gateway server after you install the App Gateway binary file.

  10. In the Add Host dialog, click Save.
  11. In the Hosts pane, click Next >.
  12. If you have previously registered an enterprise application in Identity Domains, then in the Apps pane, click Add. See Registering App Gateway.
  13. Click Finish.
  14. In the App Gateway Details page, note the value of the Client ID.
  15. Click Show Secret and note the value of the Client Secret.

    The Client ID and Client Secret are equivalent to a credential (for example, an ID and password) that your App Gateway server uses to communicate with IAM. You need these values when you configure the App Gateway server.

  16. In the Navigation Drawer, click App Gateways.
  17. In the App Gateways page, select your App Gateway, click Activate, and then click OK in the Confirmation window to activate your App Gateway.
Configuring the App Gateway Server
Before you start the App Gateway server for the first time, you need to configure the server to connect with IAM.
  1. Use an SSH client such as PuTTY and the following credentials to sign in to the App Gateway server.
    • Localhost login: oracle
    • Password: cloudgateR0X!

      You are required to change the provisioned password on the first login.

  2. Run the sudo yum updateinfo list security all command and provide sudo password.
    This command lists the security errata for your App Gateway Oracle Linux server. To update all packages for which security-related errata are available to the latest versions of the packages enter sudo yum --security update.
  3. Run the telnet <identity-domain-tenant>.identity.oraclecloud.com command to confirm that the App Gateway server can reach the IAM instance.
  4. Restart the App Gateway server after applying the updates.
  5. Navigate to the /scratch/oracle/cloudgate/ova/bin/setup folder, and then edit the cloudgate-env file present in this folder (vi cloudgate-env).
  6. Enter values for the following parameters, and then save the file:
    • IDCS_INSTANCE_URL: The URL of your Identity Domains instance.

      For example, https://idcs-123456789.identity.oraclecloud.com

    • CG_APP_TENANT: The tenant name of the Identity Domains instance.

      For example, idcs-123456789

    • CG_APP_NAME: The client ID value you made note during the App Gateway registration in the IAM Console.

    • CG_APP_SECRET: The client secret value you made note during the App Gateway registration in the IAM Console.

    • CG_CALLBACK_PREFIX: If App Gateway is configured in SSL mode (HTTPs), then set the value to https://%hostid%. Otherwise, use http://%hostid% as the value for this parameter.

  7. Confirm that the resolver entry in /usr/local/nginx/conf/nginx-cg-sub.conf has the right DNS server IP address.

    Run the nslookup <your_identity_cloud_service_domain> command, and verify the Server IP Address is the same one of the resolver entries in the /usr/local/nginx/conf/nginx-cg-sub.conf file. If not, then update this file accordingly.

  8. In the /scratch/oracle/cloudgate/ova/bin/setup folder, run ./setup-cloudgate command.
    When prompted, enter y to proceed with the configuration.
App Gateway service and agent service will start after the configuration finishes.
Assigning an Enterprise Application to App Gateway
Update the App Gateway registration in the IAM Console and assign an enterprise application.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Security and then App gateways.
  3. Click Add.
  4. In the Assign an App to gate window, map App Gateway to an enterprise application using the values below, and then click Save.
    • Application: Select the enterprise application you want to protect using this App Gateway.

      Note

      The enterprise application must be in activated status.
    • Select a Host: Select the host identifier to which the App Gateway will proxy the enterprise application.

    • Resource Prefix: Enter the URL prefix used by App Gateway to proxy the enterprise application.

      For example, use / to represent that every request since root path is forwarded to the enterprise application you select.

    • Origin Server: This is the actual base URL where the application is hosted. If the application is not directly accessible, but accessible through a web proxy, then enter the URL of the web proxy. See example diagram below.

    • Additional Properties: This field is used to provide more configuration for the application. The values specified into the field are NGINX directives or statements which are part of location block in nginx.conf. Examples when you would do this are:

      1. If protected applications need to do further redirects or to access resources after successful authentication with App Gateway, you can use this field to populate the host header with correct value and pass it to the application.

        For example, if a user accesses the application using https://myappgateway.example.com:4443/home, the browser passes the host header to App Gateway with the value set to Host: myappgateway.example.com:4443. This value is passed by App Gateway to the downstream application, and you can achieve this by setting either of the values below in more Properties:

        proxy_set_header host "myappgateway.example.com:4443";

        or

        proxy_set_header host $http_host;

        $http_host is a variable and its value is populated with the host header App Gateway receives from the browser or from any client.

        Note

        If the there are load balancers sitting behind App Gateway, then it is the job of the load balancers to forward the actual host header to app gateway so that $http_host is populated with the correct value and App Gateway can forward it to the application.
      2. If the application is accessible through a web proxy, then enter the values below:

        proxy_set_header host "myapp.internal.example.com";

        The "myapp.internal.example.com" domain is the domain name where the application is hosted, also known as origin server.

        In this case, App Gateway can't pass the host header received from browser or other client and applications cannot do further redirects via App Gateway.

    The following figure provides examples of the mappings that you configure between App Gateway and your enterprise application:

    example values used to configure an enterprise application, and an App Gateway in the IAM console

    Note

    You can assign multiple enterprise applications to the same App Gateway, and so the same App Gateway server will protect these applications.

    Ensure for each application, the value of Resource Prefix differs. For example, if you have http://myapp.internal.example.com:3266/myapp1/page.jsp and http://myapp.internal.example.com:6355/myapp2/page.jsp, both accessible through http://myappgateway.example.com:4443/ App Gateway URL, then enter /myapp1 as Resource Prefix when you register application 1, and /myapp2 as Resource Prefix when you register application 2.

After you assign the application to your App Gateway, you might need to restart the App Gateway server for the changes to be effective immediately.
Start and Stop App Gateway

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.

Using a Script to Start and Stop App Gateway

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:

  1. To start App Gateway server.
    /scratch/oracle/cloudgate/home/bin/cg-start
  2. To start App Gateway agent.
    /scratch/oracle/cloudgate/home/bin/agent-start
  3. To stop App Gateway server.
    /scratch/oracle/cloudgate/home/bin/cg-stop
  4. To stop App Gateway agent.
    /scratch/oracle/cloudgate/home/bin/agent-stop

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

Using the Service to Start and Stop App Gateway
You can start and stop the App Gateway server and agent as services running on the server. Sign in to the App Gateway server and then run the following command:
  1. To start App Gateway server.
    service cloudgate-nginx start
  2. To start App Gateway agent.
    service cloudgate-agent start
  3. To stop App Gateway server.
    service cloudgate-nginx stop
  4. To stop App Gateway agent.
    service cloudgate-agent stop

To check the running status of the App Gateway server, run the following command: /scratch/oracle/cloudgate/home/bin/cg-status

Activate and Deactivate App Gateway

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.

Note

A green check mark Activated App Gateway indicates an activated App Gateway. A red circle with a white line through the circle Deactivated App Gateway indicates a deactivated App Gateway.
Activating App Gateway
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Security and then App gateways.
  3. Click the name of your App Gateway.
  4. Click Activate.
  5. In the Confirmation window, click OK. The status of each App Gateway changes from deactivated Deactivated App Gateway to activated Activated App Gateway.
Deactivating App Gateway
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Security and then App gateways.
  3. Click the name of your App Gateway.
  4. Click Deactivate.
  5. In the Confirmation window, click OK. The status of each app gateway changes from activated Activated App Gateway to deactivated Deactivated App Gateway.
Enable Session Persistence with Sticky Cookies

Enable persistent sessions using cookies in App Gateway. The sticky cookie is forwarded to the same backend server.

You only need to use sticky support when you have multiple origins, and you do this by creating a NGINX upstream block .

  1. Enable the sticky module in App Gateway by editing the file /usr/local/nginx/conf/nginx.conf.
    • Below the line load_module /scratch/oracle/cloudgate/home/lib/idcs_cloudgate_ngx.so;, add
      load_module /scratch/oracle/cloudgate/home/lib/ngx_http_sticky_module.so;
    • Below the line include /usr/local/nginx/conf/agent_conf/*.conf;, add
      include /usr/local/nginx/conf/origin_conf/*.conf;
  2. Create a NGINX upstream block using
    $ vi /usr/local/nginx/conf/origin_conf/myupstream.conf
    
    Add below entry to myupstream.conf
    upstream weblogic {
        sticky;
        server 100.111.190.221:7003;
        server 100.111.190.220:7003;
    }
  3. Change the origin server.
    1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
    2. Select the identity domain you want to work in and click Security and then App gateways.
    3. Under Resources click Apps, and click the App gateway.
    4. In the App details, modify the Origin server to point to the upstream.

Sticky Parameters

upstream {
  sticky;  
  server 127.0.0.1:9001;
  server 127.0.0.1:9002;
}

  sticky [hash=index|md5|sha1] [no_fallback]
       [name=route] [domain=.example.com] [path=/] [expires=1h] [secure] [httponly];
   or
  sticky [hmac=md5|sha1 hmac_key=<foobar_key>] [no_fallback]
       [name=route] [domain=.example.com] [path=/] [expires=1h] [secure] [httponly];
   or
  sticky [text=raw] [no_fallback]
       [name=route] [domain=.example.com] [path=/] [expires=1h] [secure] [httponly];

Server Selection Algorithm

Algorithm Description
hash

The hash mechanism used to encode upstream server. It can't be used with hmac or text.

  • md5|sha1. Standard cryptographic hash functions to encode the information.
  • index. The information is not hashed and instead an in-memory index is used. This is quicker and the overhead is shorter, but the matching against upstream servers list is inconsistent and if the upstream server has changed index values might not correspond to the same server. Only use index if you are certain you want to use it despite this.

The default is md5.

hmac The HMAC hash mechanism used to encode upstream server It's like the hash mechanism but it uses hmac_key to secure the hashing. It can't be used with hash or text.
hmac_key The cryptographic key to use with hmac. Set a hmac_key if you use hmac.
no_fallback Set this flag so that if a request comes with a cookie and the corresponding backend is unavailable, a 502 (Bad Gateway or Proxy Error) is returned. You can set it to the upstream block, or set sticky_no_fallback in a server or location block.

Cookie Settings

Setting Description
name The name of the cookie used to track the persistent upstream server. The default is route.
domain The domain in which the cookie is valid. The default is none when the browser handles the domain.
path The path in which the cookie is valid. The default is /.
expires

The validity duration of the cookie. The default is nothing which means that it's a session cookie and deleted when the client shuts down.

Enter a value to have the cookie expire after the specified time. The value is set relative to the client, and it must be for a period greater than one second.

secure Enable secure cookies (transferred only using https).
httponly Tells the browser that the cookie can only be accessed by the server.
Testing Access to your Application Using App Gateway

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.

an example of an HTTP request to the web application through App Gateway
  1. Open a new web browser and access your application using the App Gateway URL.

    In this example, the URL is: https://myappgateway.example.com:4443/myapp/private/home

    The actual application https://myapp.internal.example.com:3266/myapp/private/home isn't accessible by the user browser.
  2. App Gateway intercepts the request and communicates with IAM to verify if the URL corresponds to an enterprise application.
    In this example, My Enteprise Application is registered, and the authentication policy for this enterprise application is Form or Access Token.
  3. App Gateway verifies that the request contains a valid IAM's access token in the Authorization Bearer header or IAM's session cookie, indicating the user has already signed in to IAM.
  4. If the user hasn't signed in to IAM, then App Gateway redirects the user browser to the IAM Sign In page.
  5. If the user has signed in, then App Gateway adds header variables and a cookie to the request, and then forwards the request to the application.
The application receives the request, uses the header variables to identify the user and to present the content of the /myapp/private/home page.
Viewing Details about App Gateway
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Security and then App gateways.
  3. Click the name of your App Gateway.
    You can modify the App Gateway configurations.
Modifying App Gateway

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

To modify an App Gateway:
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Security and then App gateways.
  3. Click the name of your App Gateway.
    The App Gateway page opens and displays three options: Hosts, and Apps.
  4. After you modify any App Gateway configuration, click Save to save the modification.
Removing App Gateway
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Security and then App gateways.
  3. In the App Gateways page, select the check box for each App Gateway that you want to remove.
  4. Click Remove.
  5. 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.

This endpoint supports two parameters appended to the URL:
  • 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.

Note

To run your App Gateway server in Secure Sockets Layer (SSL) mode, you need to have a valid certificate.

Using the Console

Configuring App Gateway in the IAM Console
Update your App Gateway configuration to enable the server to listen on port number 443 and in Secure Sockets Layer (SSL) mode.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Select the identity domain you want to work in and click Security and then App gateways.
  3. Click the name of the App gateway you want.
  4. In Hosts click the name of the host you created.
  5. in the Edit Hosts window, update the following parameters as in the example below:
    Parameter Value
    Port 443
    SSL Enabled Selected.
    Additional Properties
    ssl_certificate /scratch/myappgateway.example.com.cert;
    ssl_certificate_key /scratch/myappgateway.example.com.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;
    Note

    Generate a valid certificate to be used as the SSL certificate. The certificate file (myappgateway.example.com.cert) and the certificate key file (myappgateway.example.com.key ) are referenced as an example.
  6. Click Save.
Configuring the App Gateway Server

Enable your App Gateway server to run on port 443 in SSL mode.

Note

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.
  1. Use an SSH client such as PuTTY to sign in to the App Gateway server.
  2. Run the following commands to update a privileged user.
    sed -i "s/touch \$source_log/touch \$source_log \&\& chown \$NGINX_USER:\$NGINX_USER \$source_log/g" /scratch/oracle/cloudgate/ova/bin/jobs/manage-logs.sh 
    sudo sed -i "s/ oracle / root /g" /etc/cron.d/cloudgate-jobs 
    sudo sed -i "s/sudo -u oracle//g" /etc/init.d/cloudgate-nginx 
    sudo sed -i "s/sudo -u oracle//g" /etc/init.d/cloudgate-agent
  3. Run the following commands to change permission of the folders.
    sudo chmod -R 755 /scratch/
    sudo chown root:root /scratch/oracle/cloudgate/home/bin/nginx
    cd /usr/local/nginx/sbin/
    rm nginx
    sudo ln -sf /scratch/oracle/cloudgate/home/bin/nginx
  4. Copy the certificate file (for example, myappgateway.example.com.cert) and the certificate key file (for example, myappgateway.example.com.key) from your desktop to the /scratch/ folder.
  5. Add user oracle to the nginx.conf file by running the following command.
    sudo sed -i "/working_directory.*/a user oracle;" /usr/local/nginx/conf/nginx.conf
  6. Edit the /scratch/oracle/cloudgate/ova/bin/setup/cloudgate-env file. You can use the following command or any other text editor of your choice: vi /scratch/oracle/cloudgate/ova/bin/setup/cloudgate-env
  7. Replace the value of the CG_CALLBACK_PREFIX parameter with the following https://%hostid%
  8. Save the /scratch/oracle/cloudgate/ova/bin/setup/cloudgate-env file.
  9. Run the following sed commands to enable running the server with sudo command:
    sed -i s/verify_running_as_user/#verify_running_as_user/g /scratch/oracle/cloudgate/ova/bin/setup/setup-cloudgate
    sudo sed -i "/create_wallet || .*/a chmod -R 755 /scratch/oracle/cloudgate/wallet/" /scratch/oracle/cloudgate/ova/bin/setup/setup-cloudgate
  10. Confirm the setup-cloudgate file is configured with the values of your IAM tenant, and the values of the Client ID and Client Secret of the App Gateway you registered in the IAM Console.
  11. Run the following command to reconfigure App Gateway according to the parameters registered in the IAM Console (in this case, port number 443 and SSL Enabled.
    sudo -E /scratch/oracle/cloudgate/ova/bin/setup/setup-cloudgate
After the 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
Starting and Stopping App Gateway Server Using sudo
Because you set up your App Gateway server to run on port 443, you need to start and stop App Gateway server and agent using sudo command.
  1. To stop the App Gateway server and agent use the following command:
    sudo -E /scratch/oracle/cloudgate/home/bin/cg-stop
    sudo -E /scratch/oracle/cloudgate/home/bin/agent-stop
    
  2. To start the App Gateway server and agent use the following command:
    sudo -E /scratch/oracle/cloudgate/home/bin/cg-start
    sudo -E /scratch/oracle/cloudgate/home/bin/agent-start
    

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.

Configure App Gateway Logs

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.

The following are default values for App Gateway:
"general":{
      "disableAuthorize":false,
      "logLevel":"warn",
      "logFolder":"",
      "policyMode":"gateway",
      "policyRefreshTime":300,
      "policyStaleTime":3600,
      "policyExpiryTime":604800
    }
Note

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:

For example, to change the log level to 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.

View App Gateway Logs

App Gateway is based on a NGINX Server. The following NGIX native log files are in the /usr/local/nginx/logs/ directory:

NGINX Native Log Files
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:

App Gateway Log Files
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.

  1. Use an SSH client such as PuTTY to sign in to the App Gateway server.
  2. Run cd /scratch/oracle/cloudgate, and verify two information in this folder:
    • In the command prompt, run the following command cat /scratch/oracle/cloudgate/INSTALLED_VERSION to verify the version of the App Gateway.

      The following example shows that the version of the App Gateway is 19.3.3-1.0.0:
      $ cd /scratch/oracle/cloudgate
      $ cat INSTALLED_VERSION
      OVA Base Version: 19.3.3-1.0.0
      OVA Patch Version:
      Cloud Gate Version: 19.3.3-1910012252
    • Run the following command ls -la and verify that the home folder links to the folder named the App Gateway version:

      The following example shows that the home folder is linked to the 19.3.3.-1.0.0 folder:
      $ cd /scratch/oracle/cloudgate
      $ ls -la
      total 16
      drwx------. 6 oracle oracle 4096 Oct  2 00:23 19.3.3-1.0.0
      lrwxrwxrwx. 1 oracle oracle   38 Oct  2 01:38 home -> /scratch/oracle/cloudgate/19.3.3-1.0.0
      -rw-------. 1 oracle oracle   89 Oct  2 01:38 INSTALLED_VERSION
      drwx------. 3 oracle oracle 4096 Oct  2 01:38 ova
      drwxr-x---. 2 oracle oracle 4096 Oct  7 09:45 wallet
  3. Run cd /scratch/oracle/cloudgate/home/bin, and then ./cg-upgrade to start the upgrade process.
    During the upgrade process, App Gateway contacts IAM to verify if a patch for your App Gateway is available. If so, then the process downloads the patch and applies the patch to your App Gateway server.
  4. After the upgrade process finishes, Run the commands described in step 2 and verify whether their return refers to the App Gateway patch or the upgraded version.
  5. (Optional) Configure App Gateway in SSL mode. If you ran the cg-upgrade script, and App Gateway was configured in non-SSL mode, then after running the cg-upgrade script, complete the following steps. Note: If App Gateway was already configured in SSL mode, then don't complete the following steps.
    1. Get the SSL certificates.
    2. Log in to App Gateway and copy the certificates, for example, to /scratch/certificates/.
    3. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
    4. Select the identity domain you want to work in and click Security and then App gateways.
    5. Navigate to Hosts, and then open the required host. Navigate to Additional Properties and then add the path of the certificates and other information, such as ssl_protocols and ssl_ciphers.
      ssl_certificate /scratch/certificates/myappgateway.example.com.cert;
      ssl_certificate_key /scratch/certificates/myappgateway.example.com.key;
      ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5;
      
    6. Open /usr/local/nginx/conf/cloudgate.config, search for callbackPrefix and change its value from HTTP to HTTPS.
    7. Run the following commands so that you can see all changes reflected in App Gateway:
      1. cg-stop
      2. cg-start
      3. agent-stop
      4. agent-start
    Now the application can be accessed only through the HTTPS protocol and not the HTTP protocol.
During this procedure, App Gateway restarts. Access to your application through this App Gateway server might be affected.

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.

Note

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.

Note

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,
...
    },
...
}