PoC Guide: Secure Access to SaaS Applications with Okta and Citrix Secure Private Access

Overview

As users consume more SaaS-based applications, organizations must be able to unify all sanctioned apps and simplify user login operations while still enforcing authentication standards. Organizations must be able to secure these applications even though they exist beyond the confines of the data center. Citrix Workspace provides organizations with secure access to SaaS apps.

In this scenario, a user authenticates to Citrix Workspace using either Active Directory or Okta as the primary user directory. Okta also provides single sign-on services for a defined set of SaaS applications.

If the Citrix Secure Private Access service is assigned to the Citrix subscription, enhanced security policies, ranging from applying screen-based watermarks, restricting printing/downloading actions, screen grabbing restrictions, keyboard obfuscation, and protecting users from untrustworthy links, are applied on top of the Okta-based SaaS applications.

The following animation shows a user accessing a SaaS application with Okta providing SSO and secured with Citrix Secure Private Access.

This demonstration shows an IdP-initiated SSO flow where the user launches the application from within Citrix Workspace. This PoC guide also supports a SP-initiated SSO flow where the user tries to access the SaaS app directly from their preferred browser.

Assumptions:

• Okta is already configured to provide SSO to Office 365 and other SaaS apps
• Users can successfully sign into the Okta portal and launch Office 365 and other SaaS apps
• Citrix Workspaces is already configured with Active Directory or Okta as the user’s primary identity directory.

This proof of concept guide demonstrates how to:

1. Setup Citrix Workspace
2. Integrate a primary user directory
3. Incorporate Single Sign-On for SaaS applications
4. Define website filtering policies
5. Validate the configuration

Setup Citrix Workspace

The initial steps for setting up the environment is to get Citrix Workspace prepared for the organization, which includes

1. Setting up the Workspace URL
2. Enabling the appropriate services

Set Workspace URL

1. Connect to Citrix Cloud and log in as your administrator account
2. Within Citrix Workspace, access Workspace Configuration from the upper-left menu
3. From the Access tab, enter a unique URL for the organization and select Enabled

Enable Services

From the Service Integration tab, enable the following services to support the secure access to SaaS apps use case

1. Secure Private Access
2. Remote Browser Isolation

Verify

Citrix Workspace takes a few moments to update services and URL settings. From a browser, verify that the custom Workspace URL is active. However, logon is unavailable until a primary user directory is defined and configured.

Integrate a Primary User Directory

Before users can authenticate to Workspace, a primary user directory must be configured. The primary user directory is the only identity that the user requires as all requests for apps within Workspace use single sign-on to secondary identities.

An organization can use any one of the following primary user directories

• Active Directory (AD): To enable Active Directory authentication, a cloud connector must be deployed within the same data center as an Active Directory domain controller by following the Cloud Connector Installation guide.
• Active Directory (AD) with Time-Based One Time Password: Active Directory-based authentication can also include multifactor authentication with a Time-based One Time Password (TOTP). This guide details the required steps to enable this authentication option.
• Azure Active Directory (AAD): Users can authenticate to Citrix Workspace with an Azure Active Directory identity. This guide provides details on configuring this option.
• Citrix Gateway: Organizations can use an on-premises Citrix Gateway to act as an identity provider for Citrix Workspace. This guide provides details on the integration.
• Google: Organizations can use Google as the primary user directory for Citrix Workspace. This guide provides instructions for configuring this option.
• Okta: Organizations can use Okta as the primary user directory for Citrix Workspace. This guide provides instructions for configuring this option.

Add Okta as Single Sign-On Provider

To successfully integrate Okta apps with Citrix Workspace, the administrator needs to do the following

• Identify SAML Login URL
• Identify IdP Issuer URI
• Setup SAML Identity Provider
• Configure a SaaS app
• Authorize SaaS app
• Setup IdP Routing

Identify SAML Login URL

• Log into Okta as an administrator
• Select Applications
• Select the application to add into Citrix Workspace. In this example, Microsoft Office 365 is used.
• Under General, scroll down until the correct App Embed Link is located. This is used as the SAML Login URL for Citrix Workspace.

Identify IdP Issuer URI

• Log into Citrix Cloud as an administrator
• Under the Identity and Access Management section, select API Access
• Capture the customer ID parameter. This is used to create the IdP Issuer URI in the format: https://citrix.com/<customerID>

Setup SAML Identity Provider

Okta needs to use Citrix Workspace as a SAML identity provider, resulting in Okta becoming a service provider in the SAML configuration.

• Log into Okta as an administrator
• Select Security -> Identity Providers
• Select Add Identity Provider -> Add SAML 2.0 IdP

• Provide a Name
• For the IdP user name, use the following expression: idpuser.userName (this is case sensitive)
• Match against should be Okta Username or email
• If no match is found, select Redirect to Okta sign-in page
• For the IdP Issuer URI, use the URL https://citrix.com/<customerID>. CustomerID is from the IdP Issuer URI section

• Leave this part of the process open until we are able to obtain the single sign-on URL and SSL certificate from Citrix Cloud.

Configure a SaaS App

• Within Citrix Cloud, select Manage from the Secure Private Access tile.

• Within the Secure Private Access menu, select Applications
• In the Application section, select Add an app
• In the Choose a template wizard, select Skip
• Because this is a SaaS app, select Outside my corporate network
• In the App details window, provide an App name
• For the URL, use the App Embed Link from the Identity SAML Login URL section
• Enhanced security policies use the related domains field to determine the URLs to secure. One related domain is automatically added based on the entered URL added in the previous step. That specific related domain is associated with the Okta application link. Enhanced security policies require related domains for the actual application, which is often *.<companyID>.SaaSApp.com (as an example *.citrix.slack.com)

• Select Next
• In the Single Sign On window, select Download to capture the PEM-based certificate.
• Select the Copy button to capture the Login URL

• Switch back to the Okta configuration. The Add Identity Provider dialog should still be visible
• For the IdP Single Sign-On URL, use the Citrix Login URL copied from the previous step. It should resemble https://app.netscalergateway.net/ngs/<customerid>/saml/login?APPID=<appid>
• In the IdP Signature Certificate, browse for the downloaded PEM certificate

• Once the wizard completes, copy the Assertion Consumer Service URL and the Audience URI.

• Switch back to the Citrix configuration.
• In the Single Sign On window, for the Assertion URL, use the Assertion Consumer Service URL item obtained from the SAML Identity Provider section
• For the Audience, use the Audience URI item obtained from the SAML Identity Provider section.
• The Name ID Format and Name ID can remain as email. Okta uses the Email address to associate with an Okta user.

• Select Next
• In the App Connectivity window, select Next
• Select Finish

Authorize SaaS App

• Within the Secure Private Access menu, select Access Policies
• In the Access Policies section, select Create Policy

• Enter the Policy name and a brief Policy description.
• In the Applications drop-down field, find and select the SaaS app

Note

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 applications, all within a single policy. For more information on multiple access rules, see Configure an access policy with multiple rules

• Click Create Rule to create rules for the policy.

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

• Add the appropriate users/groups who are authorized to launch the app, and click Next.

Note

Click + to add multiple conditions based on the context.

• Specify if the HTTP/HTTPS app can be accessed with or without restrictions.
  The previous screenshot has no restrictions configured. If enhanced security is needed, change "Allow access" to "Allow access with restrictions".
• Specify the TCP/UDP apps action.
  The above screenshot denies access to TCP/UDP apps.
• Click Next.

• The Summary page displays the policy rule details.
  Verify the details and click Finish.

• In the Create policy dialog, verify that Enable policy on save is checked, and click Save.

Setup IdP Routing

So far, the configuration supports an IdP-initiated launch process, where the user launches the app from within Citrix Workspace. In order to enable an SP-initiated process, where the user launches the app with a direct URL, Okta needs an IdP routing rule defined.

• Within the Okta admin console, select Security - Identity Providers
• Select Routing Rules
• Select Add Routing Rule
• Provide a Rule Name
• For the Use this identity provider option, select the Citrix identity provider created earlier

• Select Activate

Note: During the configuration, the Okta admin might be unable to sign into the Okta admin console because the inbound SAML configuration is incomplete. If this happens, the admin can bypass the IdP routing rule by accessing the Okta environment with the following address: https://companyname.okta.com/login/default

Validate

IdP-Initiated Validation

• Log into Citrix Workspace as a user
• Select the configured SaaS application
• Observe the Okta sign-on process briefly appearing
• The SaaS App successfully launches

SP-Initiated Validation

• Launch a browser
• Go to the company-defined URL for the SaaS application
• The browser redirects to Okta and then to Citrix Workspace for authentication
• Once the user authenticates with the primary user directory, the SaaS app launches with Okta providing single sign-on

Define Unsanctioned Websites

Unsanctioned websites are the apps that are not configured within the Secure Private Access configuration but can be accessed from the Citrix Enterprise Browser. You can configure rules for these unsanctioned websites. For example, a link within a SaaS app can point to a malicious website. With these rules, an administrator can take a specific website URL or a website category and allow access, block access, or redirect the request to a hosted, secure browser instance, helping to prevent browser-based attacks.

• From Citrix Cloud, Manage within the Secure Private Access tile

• If this guide was followed, the Set up end user authentication step and the Configure end user access to SaaS, web and virtual applications steps are complete.
• Within the Secure Private Access menu, select Settings
• In the Settings section, select Unsanctioned Websites
• Select Edit
• Enable the Filter website lists option

• Click Add in the respective section to block websites, allow websites, or redirect the user to a secure browser (Remote Browser Isolation)
• For example, to block websites in the blocked categories section, click Add
• Enter a website that users cannot access and click Add
• Click Save for the changes to take effect

Validate the Configuration

IdP-Initiated Validation

• Log into Citrix Workspace as a user
• Select the configured SaaS application. If enhanced security is disabled, the app launches within the local browser. Otherwise, the enterprise browser is used
• The user automatically signs on to the app
• The appropriate enhanced security policies are applied
• If configured, select a URL within the SaaS app that is in the blocked, allowed, and redirected categories
• If configured, select a URL within the SaaS app that is in the blocked, allowed, and redirected URLs
• The SaaS App successfully launches

SP-Initiated Validation

• Launch a browser
• Go to the company-defined URL for the SaaS application
• The browser directs the browser to Citrix Workspace for authentication
• Once the user authenticates with the primary user directory, the SaaS app launches in the local browser if enhanced security is disabled. If enhanced security is enabled, a Secure Browser instance launches the SaaS app

Troubleshooting

Enhanced Security Policies Failing

Users might experience failure by enhanced security policies (watermark, printing, or clipboard access). Typically, this happens because the SaaS application uses multiple domain names. Within the application configuration settings for the SaaS app, there was an entry for Related Domains.

The enhanced security policies are applied to those related domains. To identify missing domain names, an administrator can access the SaaS app with a local browser and do the following:

• Navigate to the section of the app where the policies fail
• In Google Chrome and Microsoft Edge (Chromium version), select the three dots in the upper right side of the browser to show a menu screen.
• Select More Tools.
• Select Developer Tools
• Within the developer tools, select Sources. This provides a list of access domain names for that section of the application. To enable the enhanced security policies for this portion of the app, those domain names must be entered into the related domains field within the app configuration. Related domains should be added like the following *.domain.com