Setting up the Nginx Ingress Controller

This page describes what all you need to do if you are using Nginx Ingress Controller as a front-end for Webapp Gateway.

Installing the Nginx Ingress Controller

You can set up Nginx Ingress Controller as a front-end for Webapp Gateway to add an extra layer of security while establishing communication between external users and the application.

Follow the steps given below to set up the Nginx Ingress Controller.

Run the following command to add the Nginx Ingress Controller repository.
```
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
```
Run the following command to create a namespace
```
kubectl create namespace <ingress>
```
Where,
ingress is the name of the namespace.
Run the command as shown in the example below to install the Nginx Ingress Controller helm
```
helm install <my-ingress-nginx> <ingress-nginx/ingress-nginx> -n <namespace>
```
Where,
my-ingress-nginx is the name of the Nginx Ingress release.
ingress-nginx/ingress-nginx is the repository path.

Configuring SSL in Ingress

An important prerequisites for a secure communication between the web browser (end user) and the web server is to use Secure Sockets Layer (SSL) certificate. Adeptia Connect microservices also adheres to this requirement. To achieve this, after you've deployed Adeptia Connect, you need to configure SSL in the Kubernetes Ingress Controller. If you're using any Kubernetes ingress controller as a front-end for communication, you need to configure SSL through Kubernetes ingress object.

You can secure an Ingress by specifying a Secret that contains a TLS private key and certificate. The Ingress resource only supports a single TLS port, 443, and assumes TLS termination at the ingress point (traffic to the Service and its Pods is in plaintext). If the TLS configuration section in an Ingress specifies different hosts, they are multiplexed on the same port according to the hostname specified through the SNI TLS extension (provided the Ingress controller supports SNI).

You can generate TLS/SSL certificates by using any tool.

The TLS secret must contain keys named tls.crt and tls.key that contain the certificate and private key to use for TLS. For example:

Referencing this secret in an Ingress tells the Ingress controller to secure the channel from the client to the load balancer using TLS. You need to make sure the TLS secret you created came from a certificate that contains a Common Name (CN), also known as a Fully Qualified Domain Name (FQDN), for example, dummy.adeptia.com.

Note: There is a gap between TLS features supported by various Ingress controllers. Please refer to documentation on nginx, GCE, or any other platform specific Ingress controller to understand how TLS works in your environment.

For more details, refer the Kubernetes official documentation.

After you've configured ingress, you've to follow the steps below in the same sequence.

Exporting the public key
Importing the certificate

Exporting the public key of Ingress controller

The steps for exporting the public key of the Ingress controller external URL (external FQDN, for example, dummy.adeptia.com) vary from browser to browser. It is recommended that you export the key using DER encoded binary format X.509 (.CER). Following are the steps to export the public key in Google Chrome browser.

Enter the Adeptia Connect application URL (client-specific according to client domain) in the browser.
The login page opens.
Click > More tools > Developer tools.
Click Security tab.
Click View Certificate.
On the Certificate window, on the Details tab, click Copy to File.
Click Next to start exporting the certificate.
Choose DER encoded binary X.509 (.CER) and click Next.
Specify the location to save the exported file and click Next.
Click Finish to export.
Click OK to exit from the wizard.

Importing the Ingress controller certificate

This section helps you to import SSL certificate in the microservices Truststore.

Following the steps given below, you'd be able to import the SSL certificate in the Webapp Gateway microservice Truststore with an alias name adeptia.

Run the following Kubectl command to copy the certificate to the PVC or shared storage volume for the Webapp Gateway pod.

Kubectl --namespace <namepace_name> cp <local_path_for_SSL_certificate> <pod_name>:shared/truststore/<SSL_certificate_name>

Navigate to the Microservice pod (Eg. Webrunner) by running the following command.
```
Kubectl --namespace <namespace_name> exec -it <pod_name> -- sh 
```
Run the following Keytool command to import the certificate.
```
keytool -import -trustcacerts -file <Path_of_SSL_Certificate> -alias <alias_name> -keystore <Path of cacerts file>
```
Where,
<Path_of_SSL_Certificate> is the path of SSL certificate.
<Path of cacerts file> is the path of Truststore.
For example,
```
keytool -import -trustcacerts -file shared/truststore/ssl-certs.cer -alias adeptia -keystore shared/truststore/cacerts
```
You'll be prompted to enter a password. Enter the default password changeit.
Run the exit command to exit from the pod shell.
Restart all the Microservices to bring the changes into effect.

Handling HTTP headers containing underscores ( _ )

To ensure that connection between Adeptia Connect and a business application establishes successfully even if the header contains underscores ( _ ), set the value for the property enable-underscores-in-headers to true in the ConfigMap of Nginx Ingress Controller.

To achieve this, follow the steps given below:

Open the ConfigMap of Nginx Ingress Controller in edit mode using the following command.

Kubectl edit configmap <name of the Nginx Ingress Controller ConfigMap> -n <namespace in which Nginx Ingress Controller is deployed>

Add the property, enable-underscores-in-headers, with its value as true, in the data section of the ConfigMap as shown in the example below.
Save the ConfigMap, and restart the Nginx Ingress Controller deployment.

Handling large sized SAML response

When you use SAML for login, two cookies, "Access Token" and "SAML User Attributes", are created as a part of the SAML response. These cookies, if larger in size, can result in larger response (more than 8KB) which eventually may cause 502 Bad gateway error. To manage the size of the SAML response, follow the steps given below:

Run the following command to open the ingress resource in edit mode.

kubectl edit ingress <name of the ingress resource> -n <namespace where the ingress is deployed>

In the ingress resource, add the annotation nginx.ingress.kubernetes.io/proxy-buffer-size and provide a required value for it as highlighted in the image below.
Save the file.

Adeptia Connect Help v4.2