PoC Guide: Secure Access to Azure-managed SaaS Applications and Citrix Secure Private Access

Overview

As users access confidential content within SaaS applications, organizations must be able to simplify user login operations while still enforcing authentication standards. Organizations must be able to secure SaaS applications even though it exists beyond the confines of the data center. Citrix Workspace provides organizations with enhanced security controls for SaaS applications.

In this scenario, a user authenticates to Citrix Workspace using Active Directory as the primary user directory and launches an Azure-managed SaaS app.

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 SaaS applications.

The following animation shows a user accessing a SaaS app with Azure-provided 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 an SP-initiated SSO flow where the user tries to access the SaaS app directly from their preferred browser.

Assumptions:

Azure is already configured to provide SSO to a SaaS app
Users can successfully sign into the Azure app portal and launch the SaaS app

This proof of concept guide demonstrates how to:

Setup Citrix Workspace
Integrate a primary user directory
Incorporate Single Sign-On for SaaS applications
Define website filtering policies
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

Setting up the Workspace URL
Enabling the appropriate services

Set Workspace URL

Connect to Citrix Cloud and log in as your administrator account
Within Citrix Workspace, access Workspace Configuration from the upper-left menu
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.

Secure Private Access
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 will be available once a primary user directory gets 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: 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 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: Users can authenticate to Citrix Workspace with an Azure Active Directory identity. This guide details the required steps to enable this authentication option.

Note

When using AAD as your primary authentication directory, you cannot federate the primary domain (user’s login domain) because this creates a loop. In such cases, you must federate a new domain.

AAD user accounts must have the attribute immutableID set; otherwise, the authentication fails with the error message: AADSTS51004
Azure AD Connect synchronized accounts get this attribute set automatically.
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.
Okta: Organizations can use Okta as the primary user directory for Citrix Workspace. This guide provides instructions for configuring this option.

Create a SaaS App

To successfully create the SaaS with Citrix Workspace, the administrator needs to do the following:

Configure a SaaS App
Authorize SaaS App

Configure a SaaS App

With the SaaS app configured within Azure, the SaaS app can get configured within Citrix Workspace.

Within Azure, select Azure Active Directory
Select Enterprise Applications

Within the list, select the SaaS app, which brings up the application overview
Select Properties

Copy the User Access URL and remember for later use
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

Applications - Template

In the Choose a template wizard, find the correct template. In this example, select Humanity

Select Next

Applications - App details

In the App details screen, replace the URL with the User Access URL copied from Azure.
At the end of the URL, add the following: &whr=federated_domain replacing federated_domain with the domain associated with the user's identity (information after the @ sign in the user's email). The federated domain entry informs Azure to redirect to the correct federated domain configuration. The federated domain information gets configured within Azure in an upcoming section.

Note: You can also route the traffic through the Connector Appliance deployed in your data center. Therefore you need to switch from "Outside my corporate network" to "Inside my corporate network".

Select Next

Applications - Single Sign-On

In the Single Sign-On window, set Assertion URL to be https://login.microsoftonline.com/login.srf (1)
Set Audience to be urn:federation:MicrosoftOnline (2)
Verify the Name ID Format=Persistent and Name ID=Active Directory GUID (3)
Select the box labeled Launch the app using the specified URL (SP Initiated). (4)
Once authenticated, the user automatically gets redirected to the SaaS app instead of the Azure App Portal.
Under Advanced attributes, verify Attribute Name=IDPEmail, Attribute Format=Unspecified, and Attribute Value=Email (5)

Note

The second Advanced attribute option is added automatically to suppress the MFA authentication request when the user has already entered the MFA during user authentication to Citrix Workspace.

Attribute Name: http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
Attribute Format: Unspecified
Attribute Value: Custom value
Custom Value: http://schemas.microsoft.com/claims/multipleauthn

For Azure AD to accept this claim, we must add a parameter -SupportsMfa $true when setting up the domain federation.

Note: The steps (6), (7), and (8) are only needed to be done for the first app.

Select Download to capture the CRT-based certificate. (6)
Next to the Login URL, select the Copy button to capture the Login URL. This URL gets used later. (7)
Select the SAML Metadata link (8)

Within the SAML Metadata file, look for EntityID. Please copy the entire URL and store it for later use. Once captured, the SAML Metadata file can be closed.

Select Next

Applications - App Connectivity

In the App Connectivity window, verify how the traffic should be routed (in this case, direct from the client to the SaaS application)

Select Next
Select Finish to complete the configuration of the Humanity SaaS apps.

Authorize SaaS App and configure enhanced security

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

Enter the Policy name and a brief Policy description.
In the Applications drop-down list, search for "Humanity" and select it.

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 watermarking and printing restriction configured.
If no enhanced security is needed, change "Allow access with restrictions" to "Allow access".
Specify the TCP/UDP apps action.
The previous 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.

Note: For initial SSO testing, it is always a good idea to configure enhanced security with the option "Open in remote browser" set.

Federate Azure Authentication to Citrix Workspace

To successfully federate the SaaS app with Citrix Workspace, the administrator needs to do the following:

Verify Authentication Domain
Configure Domain Federation

Verify Authentication Domain

Azure must verify the fully qualified domain name to federate authentication to Citrix Workspace. Within the Azure Portal, do the following:

Access Azure Active Directory
Select Custom domain names in the navigation window
Select Add custom domain
Enter the fully qualified domain name

Select Add domain
Azure provides records to incorporate into your domain name registrar. Once done, select Verify.

Once complete, the domain includes a verified mark

Configure Domain Federation

The final configuration is to have Azure use Citrix Workspace as the federated authority for the verified domain. Configuring federation must be done with PowerShell.

Launch PowerShell
Add the appropriate modules with the following commands

Install-Module AzureAD -Force
Import-Module AzureAD -Force
Install-Module MSOnline -Force
Import-module MSOnline -Force

Connect to Microsoft Online via PowerShell and authenticate using a Microsoft cloud account (for instance, admin.user@onmicrosoft.com)

Connect-MSOLService

Verify that the domain is currently set to Managed within Azure by running the following PowerShell command

Get-MsolDomain

Use the following code in a PowerShell script to make this domain Federated by changing the variables to align with your environment

 $dom = "workspaces.wwco.net" # The fully qualified domain name verified within Azure
 $fedBrandName = "CitrixWorkspaceSAMLIdP" # A name to help remember the configuration purpose
 $uri = "https://app.netscalergateway.net/ngs/[entityID]/saml/login?APPID=[APPID]" # The Login URL from the Humanity app configuration
 $logoffuri = "https://app.netscalergateway.net/cgi/logout" # Standard entry for all. Do not change
 $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<location of certificate downloaded from Citrix Secure Private Access service/filename.crt>") # Path to the downloaded certificate file from Humanity app configuration (e.g., C:\temp\filename.crt)
 $certData = [system.convert]::tobase64string($cert.rawdata)
 $IssuerUri = "https://citrix.com/[entityID]" # The entityID taken from the Office365 app configuration SAML Metadata file

 Set-MsolDomainAuthentication `
     -DomainName $dom `
     –federationBrandName $fedBrandName `
     -Authentication Federated `
     -PassiveLogOnUri $uri `
     -LogOffUri $logoffuri `
     -SigningCertificate $certData `
     -IssuerUri $IssuerUri `
     -PreferredAuthenticationProtocol SAMLP

To suppress an MFA authentication request when the user has already entered the MFA during user authentication to Citrix Workspace, use the following command:

 Set-MsolDomainAuthentication `
     -DomainName $dom `
     –federationBrandName $fedBrandName `
     -Authentication Federated `
     -PassiveLogOnUri $uri `
     -LogOffUri $logoffuri `
     -SigningCertificate $certData `
     -IssuerUri $IssuerUri `
     -PreferredAuthenticationProtocol SAMLP `
     -SupportsMfa $true

Verify that the domain is currently set to Federated within Azure by running the following PowerShell command

Get-MsolDomain

Verify the federation settings in Azure by running the following PowerShell command

Get-MsolDomainFederationSettings -DomainName $dom

Note

If the federation settings need to be removed, run the following PowerShell command:
Set-MsolDomainAuthentication -DomainName $dom -Authentication Managed

Validate

IdP-Initiated Validation

Log into Citrix Workspace as a user
Select the SaaS application
Observe the URL to see it briefly redirect through Azure
The SaaS portal successfully launches

SP-Initiated Validation

Launch a browser
Go to the company-defined URL for the SaaS application
The browser redirects to Azure Active Directory and then to Citrix Workspace for authentication
Once the user authenticates with the primary user directory, the SaaS app launches with Citrix 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
Switch to the tab 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 SaaS app.
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 URLs
The SaaS App successfully launches

SP-Initiated Validation

Launch a browser
Go to the SaaS app website and Sign In. If there is an option to do SSO, select the option.
The browser redirects the browser to Citrix Workspace for authentication
Enter the user name.
Once the user authenticates with the primary user directory, Office 365 launches in the local browser if enhanced security is disabled.
If enhanced security is enabled, a Secure Browser instance launches the SaaS app.

Stay Signed In

In the default configuration, Azure Active Directory displays a dialog box during the logon process allowing the users to remain signed in.

This is an Azure setting that can be easily changed by doing the following:

Within Azure, select Azure Active Directory
Select Company Branding
Select the enabled Locale
In the Edit company branding pane, select No in the Show option to remain signed in

Select Save

Troubleshooting

User Account Does Not Exist in the Directory

When trying to launch Microsoft 365, the user might receive the following error:
AADSTS51004: The user account "account name" does not exist in the "GUID" directory. To sign into this application, the account must be added to the directory.

The following are suggestions on how to solve this issue:

Verify that the user is authorized to use the SaaS app within Azure Active Directory
Verify that the identified email address within the error matches the primary user directory, Azure Active Directory, and the SaaS app.

Verify that the attribute immutableId is set at the user object.
(This is not the case in pure AAD environments!)
The immutableId can be easily calculated and set using the following PowerShell commands:

$userUPN="john.doh@company.com"  #change the userPricipalName before executing
Install-Module AzureAD -Force
Import-Module AzureAD -Force
Install-Module MSOnline -Force
Import-module MSOnline -Force
Connect-MsolService
$userObjectID=(Get-MsolUser -UserPrincipalName $userUPN).objectId
$userImmutableId=[System.Convert]::ToBase64String([System.Guid]::New($userObjectID).ToByteArray())
Set-MsolUser -UserPrincipalName $userUPN -ImmutableId $userImmutableId

Federation Realm Object

During validation, a user might receive the following error:
AADSTS50107: The requested federation realm object 'https://<ADFShostname>/adfs/services/trust' does not exist.

This is often caused by the domain not being verified or properly federated. Review the following sections of the PoC guide:

Enhanced Security Policies Failing

Users might experience enhanced security policy (watermark, printing, or clipboard access) failure. 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 application section. 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 are added like the following *.domain.com