Secure Private Access onboarding and set up

The Secure Private Access™ service offers a streamlined admin experience that simplifies the process of configuring Zero Trust Network Access. This enhanced feature provides a step-by-step guide to set up access for a range of apps, including SaaS apps, internal web apps, and TCP apps. The admin console allows administrators to configure device posture scans, create apps, and access policies all within a single, unified interface.

Note:

Citrix Secure Private Access is integrated with Google Chrome Enterprise Premium, which allows customers to securely access private web and SaaS applications using Google Chrome Enterprise Premium as their enterprise browser.

The high-level steps to onboard and setup Secure Private Access include the following:

1. Setup Google Chrome integration.
2. Create Device Posture scans.
3. Add apps for your users.
4. Assigns permissions for app access by creating the required access policies.
5. Review the app configuration.

Important:

You can set Google Chrome as your enterprise browser. For details, see the following topics.

• Set Google Chrome as your enterprise browser
• Considerations prior to switching browser

Access the Secure Private Access admin-guided workflow wizard

Perform the following steps to access the wizard.

1. Log in to Citrix Cloud™ and then click Secure Private Access.
2. Select Fully Cloud-delivered Service architecture and then click Continue.

Setup Google Chrome integration

In the Google Chrome Integration page, perform the following steps:

1. Copy the autogenerated service account email and paste it into the appropriate field in the Google Admin console.

   1. In the Google Admin console, go to Admin Roles.
   2. Select the role that is created for the Secure Private Access service and apply the recommended privileges. For the list of privileges, see Admin roles and privileges.
   3. Under Admins, select Assign service accounts.

   4. Paste the Citrix service account (tenant-sa-<random-string>.iam.gserviceaccount.com) and select Add. Then select Assign Role.

      For details about roles, see About administrator roles.

   5. Copy the Google Customer ID that is available in Google Account Settings within the Google Admin console into the Google Customer ID field in the Google Chrome Integration page.

   6. Specify the users or user groups (available in Google Admin console > Directory) to which the Google Chrome integration must be enabled.

      • All users - Policies are enforced universally for all users within the Google Workspace domain.
      • Specific user groups - Policies are enforced on the specific user groups thus enabling granular control. Ensure that the user groups are formatted correctly as email addresses. For example, marketing@company.com, it-department@company.com.

2. Click Run CEP verification to verify your Google Workspace configuration to ensure that it is ready for Chrome Enterprise Premium integration before proceeding with the next step.

   • Once the CEP verification is successful, the Secure Private Access service successfully connects to the Google customer ID and a Secure Gateway is created.
   • Upon successful creation of the Secure Gateway, the system displays the egress IP addresses assigned to it.
   • When a user attempts to access a SaaS application, the request does not go directly to the SaaS provider. Instead, the traffic is first routed through the Secure Gateway, which functions as a partner connector. This gateway acts as an intermediary, inspecting and securing all traffic before it reaches the destination application.

   

3. Click Next.

Important:

• You can also update the integration details after the customer is onboarded to CEP. For details, see Update Google integration details post onboarding.
• For more details about Secure Private Access integration with Google Chrome Enterprise Premium, see Integration with Google Chrome Enterprise Premium.

Create device posture scans

Note:

Configuring device posture is optional for onboarding and can be completed later, during the post-deployment phase.

The device posture scans ensure that only compliant subscriber devices can access your Workspace services. The Device Posture checks determine if devices are compliant or non-compliant and then use this information to provide adaptive access to all types of apps and desktops.

1. (Optional) Connect to any third-party solutions integrated with the Device Posture service. For details, see Third-party integration with device posture.

1. Click Next and then click Create device policy. For details, see Configure Device Posture policies.
2. Click Next.

Note:

The authentication mechanism for Secure Private Access is inherited from the identity provider that is connected in the Workspace configuration > Authentication tab.

Add and manage apps

For the first-time users, the Applications landing page does not display any apps. Add an app by clicking Add an app. You can add SaaS apps, Web apps, and TCP/UDP apps from this page. To add an app, click Add an app.

For details on adding apps, see the following topics.

• Add an Enterprise Web app
  • Support for Enterprise web apps
  • Configure direct access to Web apps
• Add a SaaS app
  • Support for Software as a Service app
  • SaaS app server-specific configuration
• Configure client-server apps
  • Support for client-server apps
• Launch an app
  • Launch a configured app - end user workflow
• Role-based access to admins
  • Role-based access control in Secure Private Access

After you create applications, they appear on the Applications page.

Configure access policies

​Note:

Setting up access policies is not necessary to complete the onboarding process and can be defined later.

Access policies within Secure Private Access allow you to enable or disable access to the apps based on the context of the user or user’s device. You can create multiple access rules and configure different access conditions for different users or user groups within a single policy. These rules can be applied separately for both HTTP/HTTPS and TCP/UDP apps, all within a single policy.

Access restrictions must be configured through the Google Admin console rather than within the Secure Private Access interface.

Rules are configured in the Google Admin console > Rules. These rules are advanced settings related to DLP, such as adding a watermark, blocking the download of files with social security numbers, and URL filtering.

For details on creating policies and rules for Google Chrome in the Google Admin console, see the following topics:

• Set Chrome Enterprise connector policies for Chrome Enterprise
• Data protection rules

For the first-time users, the Access Policies landing page does not display any policies. Once you create a policy, you can see it listed here.

1. Click Create policy.
2. Enter the policy name and description of the policy.
3. In Applications, select the app or set of apps on which this policy must be enforced.

4. Click Create Rule to create rules for the policy.

   

5. Enter the rule name and a brief description of the rule, and then click Next.

   

6. Select the users’ conditions. The Users condition is a mandatory condition to be met to grant access to the apps for the users.You can select the condition, followed by the domain, and then users.

   Select one of the following:

   • Matches any of – Only the users or groups that match any of the names listed in the field and belonging to the selected domain are allowed access.

   • Does not match any - All users or groups except those listed in the field and belonging to the selected domain are allowed access.

     Note:

     You can search for users by display name, email ID, or user principal name. This search option allows admins to accurately identify and grant access to the correct user, even if they have multiple accounts.

   

7. (Optional) Click + to add multiple conditions based on the context.

   When you add conditions based on a context, an AND operation is applied on the conditions and the policy is evaluated only if the Users and the optional contextual based conditions are met. You can apply the following conditions based on context.

   • Geo location – Select the condition and the geographic location from where the users are accessing the apps.
     • Matches any of: Only users or user groups accessing the apps from any of the geographic locations listed are enabled for access to the apps.
     • Does not match any: All users or user groups other than those from the listed geographic locations are enabled for access.
   • Network location – Select the condition and the network using which the users access the apps.
     • Matches any of: Only users or user groups accessing the apps from any of the network locations listed are enabled for access to the apps.
     • Does not match any: All users or user groups other than those from the listed network locations are enabled for access.
   • Device posture check – Select the conditions that the user device must fulfill to access the apps.
8. Click Next.

9. Select the actions that must be applied based on the condition evaluation.

   • Allow access
   • Deny access

   

10. (Optional) Modify the routing type or resource location for a specific domain, if required. The Routing exceptions toggle allows you to edit the resource locations and routing information for domains of the apps added in the access policy.

    • In Routing type, modify the routing type:

      • Internal: The traffic flows through 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.

    • In Resource location, modify the resource location, if necessary. This option is applicable only for the internally routed domains.

    For more information about contextual routing, see Context-based app routing and resource locations selection.

    After you create the policies, they appear on the Access policies page.

    

11. Click Next. The Review page displays the policy details.
12. You can verify the details and click Finish.

Review the configuration

The Review page provides a comprehensive overview of the end user’s configuration, including the authentication mechanism used for their access. This authentication mechanism is not configured independently for the Secure Private Access service. It is inherited from the identity provider that is connected in the Workspace configuration > Authentication tab. You can click the Identity and Access Management > Authentication link to view the list of identity providers available for a user.

Important:

• After you have completed the configuration using the wizard, you can modify the configuration of a section by directly going to that section. You do not have to follow the sequence.
• If you delete all the configured apps or the policies, you must add them again.

Points to remember after a policy is created

• The policy that you created appears under the Policy rules section and is enabled by default. You can disable the rules, if required. However, ensure that at least one rule is enabled for the policy to be active.

• A priority order is assigned to the policy by default. The priority with a lower value has the highest preference. The rule with a lowest priority number is evaluated first. If the rule (n) does not match the conditions defined, the next rule (n+1) is evaluated and so on.

Evaluation of rules with priority order example:

Consider that you have created two rules, Rule 1 and Rule 2. Rule 1 is assigned to user A and Rule 2 is assigned to user B, then both rules are evaluated. Consider that both rules Rule 1 and Rule 2 are assigned to user A. In this case, Rule 1 has the higher priority. If the condition in Rule 1 is met, then Rule 1 is applied and Rule 2 is skipped. Otherwise, if the condition in Rule 1 is not met, then Rule 2 is applied to user A.

Note:

If none of the rules are evaluated, then the app is not enumerated to the users.

Add IP addresses of SaaS apps

After onboarding customers to Secure Private Access and Chrome Enterprise Premium, you must allow the list of the IP addresses used by your SaaS applications. This step is critical to ensure that:

• Users can access SaaS applications without connectivity issues or blocks caused by network security controls.
• Traffic from Citrix Secure Private Access and Chrome Enterprise Premium is recognized as legitimate and not inadvertently filtered or denied.

Update Google integration details post onboarding

Once customers are successfully onboarded to Chrome Enterprise Premium, Secure Private Access allows for post-onboarding management of their integration details. This includes the ability to update critical identifiers such as the customer ID and to modify associated user groups.

Perform the following steps to update the integration details post onboarding:

1. In the Secure Private Access admin console, go to Browser settings > Browser.

   The Browser page displays the Google Chrome integrations details.

   The system also displays the egress IP addresses associated with the Secure Gateway. Each time a user tries to access a Software as a Service (SaaS) application within this integration, traffic is routed through the Google Secure Gateway, which acts as a partner connector, instead of directly connecting to the SaaS application. This gateway inspects and secures the traffic, enforcing security policies and access controls, and ensuring compliance with the organization’s security posture.

   

2. Click the edit icon and update the customer ID or the user groups or both.

3. Click Run CEP verification to verify your Google Workspace configuration is ready for Chrome Enterprise Premium integration.

   If there are any issues with the integration details, the CEP verification fails and a warning message appears with specific error information to help you resolve the configuration issues.

Provisioning failure issue with multiple user groups

When configuring Chrome Enterprise Integration in Secure Private Access (through the onboarding wizard or the Browser settings page), specifying more than eight user groups might cause provisioning failures. As a workaround, do the following:

• Use a dedicated directory parent group that encompasses all required groups.
• Configure this parent group during onboarding.
• If group membership changes in the directory, repeat the synchronization process to Google’s Directory.