In certain cases an organization may want to publish multiple web applications that are resolvable using the same DNS suffix (e.g. app1.subdomain.myorg.com, app2.subdomain.myorg.com, etc’). This could be a result of a load-balancer based topology which is exposing multiple applications using the same suffix or is driven by a dynamic development environment in an IaaS (such as OpenShift or K8S) where multiple resources are sharing the same suffix.
Assuming there is a set of application which share the same DNS suffix:
which should be exposed via Secure Access Cloud (SAC) using one external wildcard root domain: https://*.external.com
In order to achieve the above, the administrator should provision wildcard custom domain application in SAC.
Once the application is provisioned, the end user will be able to use the external addresses:
to access the following accordingly:
The external address prefix will be appended to the root domain of the internal address by SAC, allowing end users to access any application with the same suffix with the origin prefix without requiring the administrator to update the SAC configuration.
Secure Access Cloud
To keep the web site security principles, HTTPs protocol mostly used, this requires a dedicated “wildcard” certificate. Generating a private certificate for the application root domain and appropriate private key is the prerequisite for the wild card application provisioning.
The certificate has to be a “wildcard” certificate (i.e. *.external.com), this way it will secure www.external.com, as well as hr.external.com, login.external.com, and others. The asterisk is
used to serve as placeholder for all possible subdomains
Certificate format has to comply with “pem” format;
The private key has to comply with “pem” format:
Wild card internal address supports hostname only (not an IP address). Make sure the hostname of the internal application is resolvable by the connector either via DNS or by updating host file.
In order to provision wildcard custom domain application in SAC following configuration steps should be applied:
Step 1: Create the application in SAC as a wildcard with custom domain
Step 2: Provision root domain for the application internal address.
Step 3: Provision root domain for the application external address and obtain the CNAME for DNS record. Note: SAC allows to provision wild card applications in custom domain only.
Step 4: Upload certificate and private key. Both certificate and appropriate private key should be generated for wildcard domain in advance.
Wildcard application apply to all subdomains of the root domain configured as the internal address in SAC. For that reason, the access and governance policies provisioned for this object applies on all sub domain applications.
In some cases, it would be required to apply specific policy on dedicated application which belong to the wild card root domain. One of the possible reasons could be granting access to specific application for administrators only.
This configuration is possible by provisioning explicit Custom Domain application (not wild card) in SAC and assigning it to the relevant policy.
For example, there is a wildcard web application (“External”) with custom root domain *.external.com and 3 subdomains: hr.external.com; login.external.com; support.external.com. This application is assigned to a policy named (“Wildcard policy”).
In order to allow secure access to the support.external.com application for administrators only, following configurations need to beed applied:
While the wild card application provisioned in SAC allows to process the requests from application external root domain to application internal root domain, it has to comply with following format: