Luminate Secure Access Cloud (TM) can provide Zero Trust Access to corporate Web Applications and Services for authorized parties without requiring network-level access to the corporate datacenter locations hosting the actual IT resources and infrastructure (either self-hosted, or co-located / IaaS). 

In certain scenarios, when providing access to such resources via Luminate, the Domain Names of the resources being accessed will be different from its "previous" state, where the resources were open via a network access (either inside the corporate network, or via VPN solutions). 

Most frequent reasons for this situation are:

  • Use of Luminate subdomain as a DNS for the resources (i.e., application1.company.luminatesec.com), instead of its internal domain name (application1.myinternaldomain.com)
  • Asymmetric access to corporate resource (i.e., internal entities inside the network accessing via an internal domain, while remote entities accessing using a different domain name)
  • Web application having either a configuration specifying its expected domain name or hard-coded domain names in its HTML, JavaScript and other resources

While it is usually best to use custom domains with web applications in order to ensure their proper functioning in all cases, situations where this would not be possible still exist, requiring translation of domain names to be performed "in transit" by Luminate Secure Access Cloud (TM).

Below diagram describes the environment architecture:

Luminate Secure Access Cloud (TM) strives to making all translations, when required, completely transparent. For edge cases, we also provide a manual link translation capability (that is not open to all administrators by default and requires explicit enabling by Luminate Support).

 

Automatic Internal-External Addresses Translation

Automatic translation of all occurrences of an internal address (as defined in the Web Application object in the Luminate Admin Portal) to an external address is performed on most prominent content types and relevant headers.

It is important, therefore, when defining an internal address, to use the internal domain name (if exists), as configured for the web server/application, rather than an IP address.

 

Automatic Addresses Translation for Linked Applications

In some cases, internal Web Applications will contain resources that reference different internal web applications/resources by their internal domain name. Naturally, when providing Zero Trust Access to such resources, everything that needs to be accessed should be configured with Luminate Secure Access Cloud (TM). Linked Applications feature provides automatic address translation for such cases.

In order for this type of automatic address translation rules to work, the administrator needs to define "Linked Applications" in the Luminate Administration Portal (signalling that resources from Application 1 could contain references to Application 2 and visa versa). Naturally, access permissions to both applications need to be aligned, in order to ensure smooth usage.

The "Linked Applications" can be configured in the Application view under Advanced Settings:

Advanced Manual Translation Rules

Please note that this advanced functionality is not available by default in the Luminate Administration Portal. If required, please reach out to Luminate Support to enable it for your tenant environment.

Once the functionality is enabled for your tenant, the following button will appear in the Application screen under Advanced Settings:

 Clicking on it will bring the following UI:

Using this UI it is possible to manage Header Link-Translation Rules (i.e., ones that modify the contents of HTTP headers, either in requests sent to the web servers or in responses returned by the web servers) or Body Link-Translation Rules (i.e., ones that modify the content of the body of HTTP Requests or Responses).

Each Source URL and Destination URL entry can contain any content in the form of Java Regular Expressions. When using groups in regular expressions, one group is supported. This does not impose any limitation on transformations that need to be performed, as multiple rules can be executed on the same content. In cases where multiple groups need to be used, the transformation should be broken down to multiple rules.

Additionally, following variables can be used inside these fields: 

 

Here is a sample combination of two Body Link-Translation Rules that look for Web Socket URLs in the responses and translate them to the external address, while enforcing wss (TLS) communication scheme: 

Content-Type

Message-Type

URI

Source URL (Pattern)

Destination URL (Rewrite-Value)

text/html

HttpResponse

(empty)

(ws|wss)[:\/\\]*[INTERNAL_ADDRESS_WITHOUT_SCHEMA]

wss

text/html

HttpResponse

(empty)

(?:wss|ws)[:\/\\]*([INTERNAL_ADDRESS_WITHOUT_SCHEMA])

[EXTERNAL_ADDRESS_WITHOUT_SCHEMA]

The first rule enforces the wss communication scheme, while the second one translates the address. When running in combination on the same content, these translation rules perform the task described above.

 

Modifying Cookies' Scope with Address Translation Rules

A possible usage of the Address and Link Translation mechanism is modifying the scope of cookies set by Web Applications/Services accessed through Luminate Secure Access Cloud (TM). For example, in order to share such internal cookie between multiple applications, the scope should be set to the tenant (i.e., mycompany.luminatesec.com) rather than for a single application.

In order to modify the cookies one should defined Header Link-Translation Rules on the Set-Cookie response header.

Here is a sample Header Link-Translation Rule to support this scenario:

Header Name Message Type Source URL (Pattern) Destination URL (Rewrite-Value)
Set-Cookie HttpResponse internal.app.domain companyname.luminatesec.com

 

Modifying CORS Policies with Address Translation Rules

Another possible useful transformation that can be performed using Header Link-Translation Rules is that of a Cross-Origin Resource Sharing Policies. In this case, the transformation will be performed on, for example, Access-Control-Allow-Origin response header.