Context-based app routing and resource locations selection

When an app is configured, the app URL is assigned to one routing type and for each URL routed internally, a resource location is selected. Admins do not have an option to edit the domain routing type or the resource location once an application is published. There might be scenarios where for a set of users;

• An internal app URL must be routed externally to prevent traffic from being routed to the Secure Private Access service.
• There is a need to change the resource locations to route requests to the optimal data center to improve performance.

The dynamic domain routing configuration (Routing exceptions) in the access policy allows admins to edit the internal routing type per URL based on the user context. Administrators can modify the resource locations so that the user requests are routed to the optimal data center, ensuring that user requests are handled efficiently and performance is optimized.

The following examples demonstrate the dynamic domain routing configuration use cases.

Use case: Context-based routing

Scenario:

• Group A Users: Employees of company ABC who access the Outlook app and Microsoft Teams app via Secure Private Access which is routed internally.
• Group B Users: Employees of a third-party company working with ABC. They access certain applications (excluding Outlook) via Secure Private Access. They also have their own Outlook application accessed over the internet and do not want to route their Outlook traffic via Secure Private Access.

Problem:

• Group B users log in to the Secure Access Agent to access ABC apps.
• Their requests to access Outlook via their native browser are routed through Secure Private Access, resulting in access denial.
• The destination domain for the Outlook application is the same for both Group A and Group B users.
• The access policy allows access only for Group A users, causing access denial for Group B users when they try to launch Microsoft Teams or Outlook.
• Group B users cannot access their company Outlook because of this routing issue.

Solution:

The ABC company admin can make the following configuration changes to resolve this issue:

1. Define a new access policy specifically for Group B users accessing the Office 365 app.

2. In the access policy, enable the dynamic domain routing configuration (Routing exceptions).

   The admin can view the list of all URLs and related domains of all internal apps associated with the access policy.

3. For all Office365 app URLs, configure the routing to happen externally.

   This ensures that Group B users’ requests to access their Outlook application are routed over the internet, bypassing Secure Private Access.

   By implementing these changes, Group B users can access their company Outlook application over the internet without being routed through Secure Private Access, while still maintaining access to other ABC applications as needed.

Use Case: User context-based resource location selection

Scenarios:

• Company XYZ: It has two sets of users located in the US East Coast and the US West Coast.
• Data centers: Two data centers, one on the East Coast and one on the West Coast, both hosting the same Jira application.
• Objective: The admin wants to route the access requests of end users to the selected resource locations based on user context (geo location, network location, user name, and user group) to ensure optimal performance and routing.

Solution:

1. Edit the access policy associated with the Jira application to accommodate the new routing requirements.
2. Within the access policy, enable the dynamic domain routing configuration (Routing exceptions).
3. Modify the resource locations per user context.

The admin can ensure that user requests are routed to the optimal data center based on their context, thereby improving performance and managing routing effectively for all users in the company.

Steps to change the routing type or resource location

1. Create or edit an access policy. For details, see Create access policies.

2. In Step 3: Action page, enable the contextual routing domain configuration by sliding the Routing exceptions toggle switch.

   The Routing exceptions toggle allows you to edit the resource locations and routing information for domains configured within the application.

   • When the toggle is ON: A list of all the apps’ URLs and related domains that are routed internally is displayed in a tabular format. You can click the edit icon next to a domain to modify its resource location and routing type. This routing exception is applicable to all users in the access policy only.
   • When the toggle is OFF: Existing routing exceptions for the domains are removed and are not applicable. End users are routed based on the global configuration set during the application setup only. This routing exception is applicable to all users in the access policy only.

   Note:

   The FQDN/ID column in the table only lists the FQDNs and host names and not the IP addresses of the applications.

   

3. Click the edit icon next to the domain for which you want to modify the routing type.

4. In Edit domain details, select the routing type:

   • Internal: The traffic flows via the Connector Appliance.
     • For a web app, the traffic flows within the data center.
     • For a SaaS app, the traffic is routed outside the network through the Connector Appliance.
   • Internal – Bypass Proxy: The domain traffic is routed through Citrix Cloud Connector appliances, bypassing the customer’s web proxy configured on the Connector Appliance.
   • External: The traffic flows directly to the internet.
5. Modify the resource location, if necessary. This option is applicable only for the internally routed domains.
6. Click Save.

Note:

• You can only change the routing and resource location, but cannot add or delete routing domain in the routing table.
• If you delete a domain that has contextual routing enabled from the main routing table, the domain is not deleted from the Routing exceptions table within the access policy. This means that the contextual routing configuration for that domain remains intact in the access policy.
• If you delete an app that has contextual routing enabled, then the domain is deleted from the Routing exceptions table within the access policy. This means that all contextual routing configurations associated with that app are removed from the access policy.
• The selected related domain overwrites the default setting when the condition meets for the users that are part of this access policy. Otherwise the default routing is applied.
• If the routing is not modified or if the Routing exceptions feature is not enabled, the routing happens based on the default settings in the main routing table (Settings > Application domain).