Advanced Concepts

Citrix Gateway SaaS and O365 Cloud Citrix Validated Reference Design

Overview

Software as a Service (SaaS) is a software distribution model to deliver software remotely as a web-based service. Commonly used SaaS apps including Microsoft Office 365 subscriptions.

SaaS apps can now be accessed using Citrix Workspace using the Citrix Gateway service. The Citrix Gateway service coupled with Citrix Workspace provides a unified user experience for the configured SaaS apps, configured virtual apps, or any other workspace resources.

SaaS apps delivery using the Citrix Gateway service provides you an easy, secure, robust, and scalable solution to manage the apps. SaaS apps delivered on the cloud have the following benefits:

Simple configuration – Easy to operate, update, and consume. Single sign-on – Hassle-free log on with Single sign-on. Standard template for different apps – Template based configuration of popular apps.

Prerequisites

To configure O365 apps in the Citrix Workspace app, make sure to complete the following:

  • If you have a primary domain available in Azure AD that is not federated with other services, you can use that domain to federate to Citrix Access Control. Ensure that this domain, either the parent or the child domain of it is not already federated and the parent domain of it is not already added in the Azure Active Directory (AAD).

    For example, if your user login using user1@demo.citrix.com, then demo.citrix.com is primary domain, citrix.com is parent domain, and us.demo.citrix.com is child domain.

  • If you cannot federate the primary domain, add a net new domain to Azure AD and federate it to Citrix Access Control. Create the domain and complete the verification. For details, see https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain.

    For details on why you need a federated domain, see How domain federation works.

  • Ensure that the new domain that you have added is in the “Verified” state in the Azure AD.

  • Set up a trust between your SAML identity provider and Azure AD. To set up a trust, you must have a domain that is verified in AAD. When a federation is configured in AAD using a domain, AAD trusts the SAML provider for user authentication to AAD, even if the user is from different domain than the federated domain. In the SP initiated flow when AAD must identify which IdP to use for authentication(accelerate user to federated IdP) it is identified using the whr query param or domain_hint passed to the URL https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-authentication-for-federated-users-portal.

    Adding a federation for a new domain does not impact an existing federation that you have in your setup. If you have ADFS already federated to a domain, it is not impacted as you are federating on a different domain that is neither sub domain or parent domain of an already federated domain.

    SSO can have the following two flows:

    IDP initiated flow: Typically used when you want to log in to the Azure AD portal. The Citrix Access Control service posts the SAML assertion to the Azure AD (AAD). AAD validates it based on the federation setting that we did earlier. If the validation passes, it extracts the nameid attribute of SAML. The nameid attribute must match immutableId of the user which is present in the AAD.

    SP initiated flow: Typically used when you want to land to the app directly instead of the AAD portal. In this flow, the Citrix Access Control service loads the URL that is configured in the app settings. The URL goes to AAD and because the URL has some indication of the federated domain, the user is redirected to the Citrix Gateway service with a SAML request and a relay state. The Citrix Access Control service posts the SAML assertion to AAD with the same relay state that came in the request. Once SAML is validated, AAD redirects a user to the context in the relay state and hence the user lands on the app directly.

  • Configure the O365 app in the Citrix Gateway service. For details see Support for Software as a Service app.

How domain federation works

The following figure illustrates a typical flow involved after a domain federation is complete.

How domain federation works

Consider that you want to add Office365 app into the Citrix Workspace and enable watermarking and restrict downloads. The typical flow is as follows:

  1. You launch the Office365 app in the Citrix Workspace.
  2. The request goes to the Citrix Access Control Service.
  3. Citrix Access Control service creates the SAML assertion and forwards it to Azure AD.
  4. As the request is coming from a trusted SAML IdP, Azure AD identifies it through the domain federation that is created and passes the SAML assertion to the Office365 app.

    The Office365 app is launched.

Authentication methods supported for Office365

By default, Citrix Cloud uses the Citrix identity provider to manage the identity information for all users in your Citrix Cloud account.

The Citrix Workspace supports the following authentication methods for Office365. Okta and Google IdP are not supported currently.

  • On-premises Active Directory
  • Active Directory plus Token
  • Azure Active Directory Note: If AAD is used to authenticate to the workspace, then you cannot federate the primary domain (user’s login domain) because this creates a loop. In such cases, you must federate a new domain
  • Citrix Gateway
  • Active Directory plus RADIUS

For more details, see Identity and access management.

Configure the O365 app in the Citrix Gateway service

The following are the high-level steps to configure the O365 app in the Citrix Gateway service. For more details, see Support for Software as a Service app.

  1. Go to Citrix Gateway service in Citrix Cloud.
  2. Add a SaaS/web app.
  3. Search for Office 365 and choose template.
  4. Add the following related domains in the App details. The following are the list of O365 domains. New domains are added when available.

    • *.office.com
    • *.office365.com
    • *.sharepoint.com
    • *.live.com
    • *.onenote.com
    • *.microsoft.com
    • *.powerbi.com
    • *.dynamics.com
    • *.microsoftstream.com
    • *.powerapps.com
    • *.yammer.com
    • *.windowsazure.com
    • *.msauth.net
    • *.msauthimages.net
    • *.msocdn.com
    • *.microsoftonline.com
    • *.windows.net
    • *.microsoftonline-p.com
    • *.akamaihd.net
    • *.sharepointonline.com
    • *.officescriptsservice.com
    • *.live.net
    • *.office.net
    • *.msftauth.net
  5. Enable enhanced security controls, if needed.
  6. Configure SSO.

    Note: The only change you must do is to make sure “Name ID” is the Active Directory GUID.

  7. Ensure advanced attributes also send IDPEmail.
    • Attribute Name: IDPEmail
    • Attribute Format: Unspecified
    • Attribute Value: Email
  8. Click SAML metadata to open in a new tab.
    • Copy “entityID”
    • Copy “Login URL”
    • Download the Certificate in CRT format

Configure domain federation from Azure AD to Citrix Workspace

Prerequisites:

  • Enable PowerShell in Azure AD
  • Install Microsoft MSOnline module

The following are the PowerShell commands to install the required modules.

PS> Install-Module AzureAD -Force

PS> Import-Module AzureAD -Force

PS> Install-Module MSOnline -Force

PS> Import-module MSOnline -Force

If the modules are already installed, then run the following command.

PS> connect-msolservice

Note: A Microsoft cloud account is required to connect to msolservice. For example, admin.user@onmicrosoft.com

Steps to configure domain federation from Azure AD to Citrix Workspace

  1. Run the following commands in the PowerShell to configure the federation:

    • PS> $dom = "ad-domain.com"

    Note: ad-domain.com is the new domain added to Azure AD

    • PS> $IssuerUri = "https://citrix.com/[customerID]"

    Note: The customerID can be found from the following locations:

    • Citrix Cloud > Identity and Access Management > API Access
    • Citrix Cloud > Citrix Gateway Service > Add a Web/SaaSApp > Single sign on > SAML Metadata file > entityID

    • PS> $fedBrandName = “CitrixWorkspace”
    • PS> $logoffuri = "https://app.netscalergateway.net/cgi/logout"
    • PS> $uri = "https://app.netscalergateway.net/ngs/[customerID]/saml/login?APPID=[AppID]”

    Note: $uri can be copied from Citrix Gateway Service > Add a Web/SaaSApp > Single sign on > Login URL or from SAML Metadata > Location.

    • PS> $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<location of certificate downloaded from Citrix Gateway service/filename.crt>”)

      For example: PS> $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\cert\saml_idp.crt")

    PS> $certData = [system.convert]::tobase64string($cert.rawdata)

  2. Run the PS string to complete the Federation to Citrix Gateway:

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

  3. Verify domain federation settings by running the following command:

    Get-MsolDomainFederationSettings -DomainName <domain name>

Federation setting validation

Configuring individual Office suite applications in Citrix Workspace

Perform the following to configure individual office suite applications:

  1. Complete the domain federation as detailed in previous sections.
  2. Choose the O365 template.
  3. Change the name of the app to, for example, MS Word.
  4. Change the app URL to accordingly.

Word: https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2Foffice.live.com%2Fstart%2FWord.aspx%3Fauth%3D2&whr=<federated domain>

Powerpoint: <https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2Fwww.office.com%2Flaunch%2Fpowerpoint%3Fauth%3D2&whr=<federated domain>

Excel: https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2Foffice.live.com%2Fstart%2FExcel.aspx%3Fauth%3D2&whr=<federated domain>

CRM/Dynamics Online: https://<tenant>.crm.dynamics.com/?whr=<federated domain>

OneDrive for Business: https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2F<tenant>-my.sharepoint.com%2F&whr=<federated domain>

Outlook Calendar: https://outlook.office.com/owa/?realm=<federated domain>&path=/calendar/view/Month

Outlook Web Access to Exchange Online: https://outlook.com/owa/<federated domain>

SharePoint Online: https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2F<tenant>.sharepoint.com%2F&whr=<federated domain>

Third party apps integrated into Azure AD

If you have integrated third party applications like Box, Salesforce, ServiceNow, Workday, you can obtain the Smart Links for these apps from the Azure AD.

Perform the following steps.

  1. Log in to your Azure AD Portal https://portal.azure.com.

  2. Select All Services > Azure Active Directory, and select your directory.

    Select all services

  3. Select Enterprise Applications and then choose the application you want to generate a Smart Link to.

    Select enterprise applications

  4. Select Properties and copy the User access URL.

    Select properties

  5. After you append whr to the URL, the whr parameters appear as shown in the example URL.

    Example URL: https://myapps.microsoft.com/signin/Workday/1234567891234567891234567896d64b?whr=ctxnsqa.net

    Note: Append whr to the URL so that AAD knows which IdP to use to authenticate a user based on federation setting and auto redirect to that IdP.

  6. Set enhanced security controls.
  7. Configure SSO.
    • Name ID = AD GUID
    • Enable SP-initiated check box

      When you do IdP initiated flow it always lands users on the Azure AD portal page. If you want to land directly on the app page, then SP initiated flow is needed as it sends the correct relay state in the SAML assertion.

Note:

  • If users log on to Citrix Workspace using AAD, then the primary domain of the users that is used to log in must not be federated to the Citrix Gateway service. This results in a loop. In such cases, use another domain different from the domains of users login to AAD to federate to the Citrix Gateway service.

  • If primary domain is federated to Citrix Gateway service, then all user logins on that domain in AAD are redirected to Citrix Gateway service. For POC, if needed, you can federate a test domain before federating primary domain.
  • If AAD has location policy turned on, users must be from the list of allowed IP addresses of a corporate network only. In such cases, you can publish the O365 app as a Web app and route its traffic via the on-premises gateway connector.
  • When logging on to the AAD, if you want to avoid Stay signed in? prompt, you can change this setting by using the AAD. Note the important message that appears when you change the setting and revert if necessary.

Select stay signed in

Message when reverting the setting

Azure PowerShell Module Reference

Azure PowerShell Command Reference

Deploy Office 365 Directory Synchronization in Microsoft Azure