Configure Single Sign-On to Office 365 apps with Citrix Secure Private Access (SPA)

CoAuthor: Christian Watson – Linkedin

If you want to provide the best end-user experience by providing access to Office 365 apps with Citrix cloud this is your guide when using AAD as a primary IdP in Citrix Workspace.

Many customers are using Citrix Secure Private Access (SPA) to deliver single sign-on and secure access to SaaS and web applications. However, integrating O365 applications with a seamless user experience presents organizations with a significant challenge:

How can we configure Citrix Cloud to provide single sign-on (SSO) to O365 apps without modifying the authentication flow for all users?

The Challange:

In Azure Active Directory (AAD), federating a primary domain will force all users in your organization to use the federated Identity Provider (IdP) for authentication. This means that all users associated with the primary domain will be redirected to the federated IdP during the login process. Because of the significance of this change, it is essential to understand the impact of federating a primary domain before making this change to the user experience.

To solve this, administrators can utilize a secondary (or dummy) domain as the federated domain in Citrix Cloud. This preserves the end-user experience while enabling SSO and enhanced security controls for O365 apps. The end users will still utilize their primary domain credentials, but the federated secondary (dummy) domain will be used to initiate the Single Sign-On process with Citrix Cloud SAML.

In this example my primary domain is azjavilab.com, meaning all users will authenticate with username@azjavilab.com AAD credentials when accessing O365 Apps, which represents the most common use case in a production environment. To configure the SSO experience without impacting the login flow for your users, register and verify a secondary (dummy) domain in AAD. This requires a verified secondary (dummy) domain to be able to verify (add TXT record) and later federate it for the SSO app. For example, I am using javilabdummydomain.store as a federated secondary domain to achieve the SSO experience.

For example, a customer has a requirement to control access to O365 apps for contractors using BYOD. They need to restrict downloads, clipboard access, printing, keylogging, publishing a watermark, and provide App Protection policies. They also wish to ensure a single sign-on experience using the Citrix Enterprise browser… Sound complicated? Let’s look at the end-user experience:

Youtube Video coming soon

Configuration Steps

1 – Buy a Secondary domain and verify it with Azure – the step-by-step process is explained on this link https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain

Open the Azure Console and navigate to Custom domains

Add TXT Record for the dummy domain:

2 – Configure Office 365 app to federate the domain. Click add an App

Configure the application, choosing Office 365

Choose SAML and follow the steps to configure Azure AD and retrieve the dummy domain

Before you federate it, you will be prompted to confirm

Open the Azure Console and navigate to Azure Active Directory/custom domains as shown below

Click Save

3 – Now we are going to enable access and security policies when accessing to this application

And our Office 365 app with SSO is ready in our workspace

Office 365 Apps

Citrix official documentation: https://docs.citrix.com/en-us/tech-zone/learn/poc-guides/access-control-azuresso-o365.html

If it is preferable to launch a specific Microsoft 365 app (Word, Outlook, or Excel) instead of the Microsoft 365 portal, the administrator needs to create a separate application instance within Citrix Cloud for each application . Each app has a unique URL, which must include the correct value for the (federated domain) at the end of each URL, which are listed below. The federated domain entry tells Azure to redirect to the correct federated domain configuration.