Direct access to Enterprise web apps

Enterprise web applications like SharePoint, JIRA, Confluence, and others which are hosted by the customer either on-premises or on public clouds, can now be accessed directly from a client browser. End users no longer need to initiate access to their enterprise web apps from the Citrix Workspace experience. This feature also enables end users access to the web apps by clicking links from their emails, collaboration tools, or browser bookmarks. Thus provisioning a true zero footprint solution to the customers.

How it works

• Add a new DNS record or modify an existing DNS record for the configured Enterprise web apps.

• IT administrator would add a new public DNS record or modify an existing public DNS record for the configured enterprise web app FQDN to redirect the user to the Citrix Secure Private Access service.

• When the end-user initiates access to the configured enterprise web app, the app traffic is steered to the Citrix Secure Private Access service, which then will proxy the access to the app.

• Once the request lands on the Citrix Secure Private Access service, it checks for user authentication and application authorization, including contextual access policies checks.

• Upon successful validation, the Citrix Secure Private Access service communicates with Citrix Cloud Connector Appliances, deployed at the customer’s environment (either in on-premises or cloud) to enable access to the configured enterprise web app.

Configure Citrix Secure Private Access for direct access to Enterprise web apps

Prerequisites

Before you begin, you need the following for the application to be configured.

• Application FQDN
• SSL certificate – Public certificate for the app to be configured
• Resource location – Install Citrix Cloud Connector Appliances
• Access to the public DNS record to update it with the canonical name (CNAME) provided by Citrix during the app configuration.

Procedure to configure direct access to Enterprise web apps:

Important:

For a complete end-to-end configuration of an app, see Admin guided workflow for easy onboarding and set up.

1. On the Secure Private Access home page, click Continue.

   Note:

   The Continue button appears only for the first time that you use the wizard. In the subsequent usages, you can directly navigate to the Applications page and, then click Add an app.

2. Set up identity and authentication. For details, see Admin guided workflow for easy onboarding and set up.

3. Proceed to add an app. For details, see Add and manage applications.

4. Select the app that you want to add and click Skip.

5. In Where is the application location?, select the location.

6. Enter the following details in the App Details section and click Next.

   • App type – Select the app type (HTTP or HTTPS).

   • App name – Name of the application.

   • App description - A brief description of the app. This description that you enter here’s displayed to your users in the workspace.

   • App icon – Click Change icon to change the app icon. The icon file size must be 128x128 pixels. If you do not change the icon, the default icon is displayed.

     If you do not want to display the app icon, select Do not display application icon to users.

7. Select Direct Access to enable users access the app directly from a client browser. Enter the following details.

   • URL – URL for the back-end application. The URL must be in HTTPS format and a corresponding DNS entry must be added by the admin.

   • SSL certificate – Select an existing SSL certificate from the drop-down menu or add a new SSL certificate by clicking Add New SSL Certificate.

     Points to note:

     • Only a public or a trusted CA certificate is supported. Self-signed certificates aren’t supported.
     • A full chain of certificates must be uploaded.

   • Related Domains – The related domain is auto-populated based on the URL that you’ve provided. Related domain helps the service to identify the URL as part of the app and route traffic accordingly. You can add more than one related domain. You can bind an SSL certificate to each related domain, this is optional.

     Note:

     A warning message appears if duplicate related domains are added or if a related domain is also added as a URL for a different app (see the highlighted portion in the App Details image). To avoid these issues, see Best Practices for Web and SaaS application configurations.

   • CName record – Auto generated by Secure Private Access. This is the value that must be entered in the DNS to enable direct access to the application.

   

8. Click Next.

9. In the Single sign on section, select your preferred single sign-on type to be used for your application and click Next.

   

10. In the App Connectivity section, you can either select an existing resource location or create one and deploy a new Connector Appliance. To choose an existing resource location, click one of the resource locations from the list of resource locations, for example My Resource Location, and click Next. For details, see Route tables to resolve conflicts if the related domains in both SaaS and web apps are the same.

    

11. Click Finish. The app is added to the Applications page. You can or edit or delete an from the Applications page after you’ve configured the application. To do so, click the ellipsis button on an app and select the actions accordingly.

    • Edit Application
    • Delete

Important:

• To enable zero-trust-based access to the apps, apps are denied access by default. Access to the apps is enabled only if an access policy is associated with the application. For details on creating access policies, see Create access policies.
• If multiple apps are configured with the same FQDN or some variation of the wildcard FQDN, this might result in a conflicting configuration. To prevent conflicting configurations, see Best practices for Web and SaaS application configurations.
• For the list of available access restrictions, see Access restriction options.

Device Posture service with direct access apps

Citrix Secure Private Access with direct access apps when combined with the Device Posture service can ensure that only compliant devices access sensitive applications through direct access. Admins can block access to non-compliant or non-managed devices based on the Device Posture service scan results.

Steps to enable direct access for compliant devices only

To enable direct access to only compliant devices, the admin must perform the following steps:

1. From the Device Posture service admin console, create a device posture policy to check for the device posture scan conditions such as device certificate, antivirus, browser and then select Compliant as the policy result action. For details, see Configure device posture.

   

2. From the Secure Private Access admin console, perform the following:

   • Create an application for which you want to enable direct access. For details, see Direct access to Enterprise web apps.

   

   • Configure Secure Private Access with Device Posture. In Rule Scope, select Device posture check > Matches any of and enter the tag Compliant. This tag is sent from the Device Posture service.

   Note:

   The tag must be entered exactly as captured earlier, using initial caps (Compliant). Otherwise, the device posture policies do not function as intended. For details, see Citrix Secure Private Access configuration with Device Posture.

   

Once this configuration is performed, based on the device posture scan results, the device is tagged as compliant, non-compliant, or denied login and app access is enabled accordingly.

Example:

Consider that you have created a device posture policy to check for the presence of a device certificate on an endpoint device and determine its login status. Once the device posture policies are set and device posture is enabled, the following actions occur when an end user logs into Citrix Workspace.

1. The device posture scan checks the endpoint device for the presence of a device certificate.

   • If the device certificate is present on the device, the device is tagged as compliant.
   • If the device certificate is not present on the device, the device is tagged as non-compliant.
2. This information is then passed to the Citrix Secure Private Access service as tags.

3. The access policy is evaluated based on the device classification.

   • If the device is compliant, direct access is allowed for the apps.
   • If the device is non-compliant, direct access is disabled for the apps.

End user experience

The end user experience is based on the classification of the device as compliant or non-compliant.

• Compliant device:

  The user can launch the direct access app from Citrix Workspace or from the browser using the app URL.

• Non-compliant device:

  • The app is not enumerated in Citrix Workspace.
  • The user cannot launch the app from the browser using the app URL.
  • An access blocked page is displayed to the user.