Best practices for Web and SaaS application configurations

Application access for published and unpublished apps depends on the applications and access policies configured within the Secure Private Access service.

Application access within Secure Private Access for published and unpublished Apps

• Access to published web applications and related domains:

  • When an end user accesses an FQDN that is associated with a published web app, the access is allowed only if an access policy is configured explicitly with the action Allow or Allow with Restrictions for the user.

    Note:

    It is recommended not to have multiple applications share the same application URL domain or related domains for an exact match. If multiple apps share the same application URL domain or related domains, the access is provided based on exact FQDN match and policy prioritization. For details, see Access policy matching and prioritization.

  • If no access policy matches with the published app or if an app isn’t associated with any access policy, then access to the app is denied, by default. For details on access policies, see Access policies.

• Access to unpublished internal web applications and external internet URLs:

  To enable zero-trust, Secure Private Access denies access to internal web applications or intranet URLs that are not associated with an application and do not have an access policy configured for the application. To allow access for specific users, ensure that you have an access policy configured for your intranet web applications.

  For any URL that is not configured as an application within Secure Private Access, the traffic flows directly to the internet.

  • In such cases, access to intranet web application URL domains are routed directly and thus access is denied (unless the user is already inside the intranet).
  • For unpublished internet URLs, access is based on the rules configured for unsanctioned apps, if enabled. By default, this access is allowed within Secure Private Access. For details, see Configure rules for unsanctioned websites.

Access policy matching and prioritization

Secure Private Access does the following while matching an application for access:

1. Match the domain being accessed to the application URL’s domain or related domains for an exact match.

2. If a Secure Private Access application configured with an exact FQDN match is found, then Secure Private Access evaluates all policies configured for that application.

   • Policies are evaluated in a priority order until the user context matches. The action (allow/deny) is applied as per the first policy that matches in the priority order.
   • If no policy matches, then access is denied by default.

3. If an exact FQDN match is not found, then Secure Private Access matches the domain based on the longest match (such as a wildcard match) to find applications and corresponding policies.

   Example 1: Consider the following app and policy configurations:

   Application	Application URL	Related domain
   Intranet	https://app.intranet.local	*.cdn.com
   Wiki	https://wiki.intranet.local	*.intranet.local

   Policy name	Priority	User and associated apps
   PolicyA	High	Eng-User5 (Intranet)
   PolicyB	Low	HR-User4 (Wiki)

   If HR-User4 accesses app.intranet.local, then the following happens:

   1. Secure Private Access searches all policies for an exact match for the domain being accessed, app.intranet.local in this case.
   2. Secure Private Access finds PolicyA, and checks if the conditions match.
   3. As the conditions do not match, Secure Private Access stops here and does not continue to check the wildcard matches, even though PolicyB would have matched (since app.intranet.local does match on the Wiki app’s related domain of *.intranet.local) and given access.
   4. Hence HR-User4 is denied access to the Wiki app.

   Example 2: Consider the following apps and policy configuration where same domain is used in multiple applications:

   Application	Application URL	Related domain
   App1	xyz.com	app.intranet.local
   App2	app.intranet.local	-

   Policy name	Priority	User and associated apps
   PolicyA	High	Eng-User5 (App1)
   PolicyB	Low	HR-User7 (App2)

   When user Eng-User5 accesses app.intranet.local, both App1 and App2 will be a match based on the exact FQDN match and hence Eng-User5 user gets access through PolicyA.

   However, if App1 had *.intranet.local as a related domain instead, then the access for Eng-User5 would have been denied since app.intranet.local would have exact-matched PolicyB, for which the user, Eng-User5, does not have access.

App configuration best practices

IdP domains must have an application of their own

Instead of adding IdP domains as related domains in your intranet app configurations, we recommend the following:

• Create separate applications for all IdP domains.
• Create a policy to enable access to all users who need access to the IdP authentication page, and keep the policy as the highest priority.
• Hide this app (by selecting the Do not display application icon to users option) from the app configuration so that it does not enumerate on workspace. For information, see Configure application details.

Note:

This app configuration only enables access to the IdP authentication page. Further access to individual applications still depends on the individual app configurations and their respective access policies.

Example configuration:

1. Configure all common FQDNs into their own apps, grouping them together where applicable.

   For example, if you have a few apps that use Azure AD as an IdP and you must configure login.microsoftonline.com and other related domains (*.msauth.net), then do the following:

   • Create a single common application with https://login.microsoftonline.com as the application URL and *.login.microsoftonline.com and *.msauth.net as the related domains.
2. Select the Do not display application icon to users option while configuring the app. For details, see Configure application details.
3. Create an access policy for the common application and enable access to all users. For details, see Configure an access policy.
4. Assign highest priority to the access policy. For details, see Priority order.
5. Verify the diagnostic logs to confirm that the FQDN matches the app and that the policy is enforced as expected.

Same related domains must not be a part of multiple applications

Related domain must be unique to an app. Conflicting configurations might result in app access issues. If multiple apps are configured with the same FQDN or some variation of the wildcard FQDN, then you might encounter the following issues:

• The websites stop loading or might display a blank page.
• The Blocked Access page might appear when you access a URL.
• The login page might not load.

Thus we recommend having a unique related domain to be configured within a single app.

Incorrect configuration examples:

• Example: Duplicate related domains across multiple applications

  Assume you have 2 apps where both need access to Okta (example.okta.com):

  App	application URL domain	Related domain
  App1	https://code.example.net	example.okta.com
  App2	https://info.example.net	example.okta.com

  Policy name	Priority	User and associated apps
  Deny App1 to HR	High	User group HR for App1
  Grant Everyone access to App1	Medium	Enable access to user group Everyone to App1
  Grant Everyone access to App2	Low	Enable access to user group Everyone” to App2

  Problem with the configuration: Although the intent was to give all users access to App2, the user group HR cannot access App2. The user group HR gets redirected to Okta but is stuck based on the first policy that denied access to App1 (which also has the same related domain example.okta.com as App2).

  This scenario is common for Identity Providers such as Okta, but it can also happen with other tightly integrated apps with common related domains. For details on policy matching and prioritization, see Access policy matching and prioritization.

  Recommendation for the above configuration:

  1. Remove example.okta.com as a related domain from all apps.
  2. Create a new app just for Okta (with the application URL of https://example.okta.com and a related domain of *.okta.com).
  3. Hide this app from workspace.
  4. Assign the highest priority for the policy to remove any conflict.

  Best Practice:

  • An app’s related domains must not overlap with another app’s related domains.
  • If this occurs, a new published app must be created to cover the shared related domain and then access must be set accordingly.
  • Admins must evaluate if this shared related domain must appear as an actual app in Workspace.
  • If the app must not appear in Workspace, then while publishing the app, select the Do not display application icon to users option to hide it from Workspace.

Resolve conflicts resulting from same related domains

In scenarios where an app’s related domains overlap with another app’s domains, admins have the flexibility to route these applications either externally or internally via the Connector Appliances, based on specific requirements. The routing table within the Secure Private Access console (Settings > Application Domains) provides a comprehensive list of all configured domains for all applications. This table displays key information about each domain, including the routing type. Admins can easily modify the routing type by clicking the edit icon next to the corresponding domain entry.

The main route table displays the following information for any domain:

• FQDN/IP: FQDN or the IP address for which the type of traffic routing is desired to be configured.
• Type: App type. Internal, Internal – Bypass Proxy, or External as selected when adding the app.
  • Internal - The apps are external but the traffic must flow through the Connector Appliance to the outside network.
  • Internal – Bypass Proxy - The domain traffic is routed through Citrix Cloud Connector, bypassing the customer’s web proxy configured on the Connector Appliance.
  • External – The traffic flows directly to the internet.

  Important:

  If there are conflicts, then an alert icon is displayed for the respective row in the table. To resolve the conflict, admins should click the triangular icon associated with that entry and change the app type.

• Resource location: Resource location for routing of type Internal. If a resource location is not allocated, a triangular icon appears in the Resource location column for the respective app. When you hover on the icon, the following message is displayed.

  Missing resource location. Ensure that a resource location is associated with this FQDN.

• Status: The toggle switch in the Status column can be used to disable the route for a route entry without deleting the app. When the toggle switch is turned OFF, the route entry does not take effect. Also, if FQDNs of exact match exist, admins can select the route to be enabled or disabled.
• Comments: Displays comments, if any.
• Actions: The edit icon is used to add a resource location or change the type of route entry. The delete icon is used to delete the route.

Note:

A mini version of the application domains table is available to make the routing decisions during app configuration. The mini route table available in the App Connectivity section in the Citrix Secure Private Access service admin console.

Deep-link URLs

For deep-link URLs, the intranet application URL domain must be added as the related domain:

Example:

Intranet app has URL is configured with https://example.okta.com/deep-link-app-1 as the main application URL domain and the related domain has the intranet application URL domain i.e *.issues.example.net.

In this case, separately create an IdP app with URL https://example.okta.com and then related domain as *.example.okta.com.