Context-based app routing and resource locations selection

When an app is configured, the app URL and related domains are assigned to a routing type and resource location. This is done during app configuration. This configuration for app routing and resource location then applies to all users who have access to the app. But there might be scenarios such as the following:

• An admin wants to route the same app differently for different users. For example, an internal app URL must be routed externally for a few users to prevent traffic from being routed to the Secure Private Access service.

• There is a need to use different resource locations for different users to route requests to the optimal data center to improve performance.

This can now be done within Access Policies using the Routing Exceptions feature. The routing exceptions configuration in the access policy allows admins to edit the internal routing type per URL or resource location based on the user context. Because this setting is within the access policies, it applies only to the users that are part of that access policy only.

Note:

If there is a routing and resource location configuration within an access policy, then it overrides the app configurations.

The following examples demonstrate the routing exception 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 that 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 Routing exceptions option.

   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 Routing exceptions option.
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 of the applications added in the access policy.

   • When the toggle is ON: A list of all the apps’ URLs and related domains is displayed in a tabular format along with their global routing and resource location configuration. This list contains the URLs and related domains of all the applications added in the access policy. 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 the 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.

   

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

4. In Routing type, modify 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. In Resource location, modify the resource location, if necessary. This option is applicable only for the internally routed domains.

   Note:

   If an app is created using an IP address, you cannot modify the routing type to External as only the Internal via Connector option is displayed in the Routing type list. You can only modify the resource location. However, this restriction does not apply to apps created using an FQDN.

   

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).