Connecting MySQL Workbench and other Native Client Applications to Application Servers using Luminate

Products

Secure Access Cloud

Issue/Introduction

Resolution

Luminate Security cloud can be used to connect native applications running on Windows, Mac OS X, iOS, Android and other operating systems to their application servers residing in the corporate data centers.

In order to make sure that the connection is secure (including authentication, authorization and communications security), Luminate will use an ad-hoc SSH tunnel to connect the application at the endpoint device to the relevant application server.

This method is useful for creating Zero Trust connectivity to services, such as:

Databases (PostgreSQL, MySQL, ...) via a dedicate client, such as pgAdmin, MySqlWorkbench, etc...
Windows Remote Desktop servers, using Microsoft Remote Desktop Client
...

Below diagram depicts the communication schematically:

In order to authenticate to the system, the user needs to log in to Luminate Security portal, using the organizational policy (including authorization, multi-factor authentication, etc...).

From this point, in order to access the desired application server via an SSH tunnel, the user needs to connect to a defined "SSH Application". For more information on defining an SSH application in the Luminate Administration Portal, please refer to this article.

Once the SSH application is defined, the following steps need to be taken to allow the connection via a native application:

1. If the application supports SSH tunneling, then an application server needs to be defined accordingly.

Please see the below example for MySQLBench application configuration that supports SSH tunneling.

In the above screenshot, following parts of the configuration are relevant:

1 - Address of the SSH application, as defined in the Luminate Administration Portal

2 - User name for login (as taken from the Luminate User Portal)

3 - Internal IP Address of the real Application Server (needs to be accessible from the SSH Server)

4 - Application Server Port

When launching such a configuration, the relevant application (MySQLWorkbench in this case) automatically creates an SSH Tunnel to the target server. Please note that the password is not provided on purpose.

If the authentication method chosen by the user in the Luminate Portal was an Access Token, the application will prompt for the Luminate Token to be used. Alternatively, the private key downloaded from the portal should be provided in the SSH Key File field (in the sample screen above).

Fore more details on the authentication, please refer to the article explaining the basics of SSH Access via Luminate.

2. If the application does not support SSH tunneling, an external SSH client (such as openssh, putty or any other client) should be used to create an SSH tunnel via Luminate to the application server.

Below you can find a screenshot of a sample configuration using an SSH Tunneling client for Mac OS X:

The configuration elements in this screenshot are:

1 - User name for login (as taken from the Luminate User Portal)

2 - Address of the SSH application, as defined in the Luminate Administration Portal

3 - Internal IP Address of the real Application Server (needs to be accessible from the SSH Server) and application server port

4 - Application Server Port, mapped on the local host. This is where the client application needs to connect to.

Same effect can be achieved by using openssh CLI interface using the following arguments:

-L <LOCAL PORT>:<REMOTE SERVER ADDRESS>:<REMOTE SERVER PORT>

Combining these arguments with the openssl CLI format to connect to an SSH server via Luminate will result in the following:

ssh <Unix User>@<SSH Application Name>@<SSH Application Name>.<Luminate Tenant Name>.luminatesec.com  -L <LOCAL PORT>:<REMOTE SERVER ADDRESS>:<REMOTE SERVER PORT>