| We are excited to announce that as of December 17, 2024, Conditional Authentication is now generally available! |
At Citrix, we pride ourselves on flexibility. Flexibility of hosting locations, deployment methods, access methods – and most importantly, authentication. We know how critical it is for our customers to be able to secure and protect their environments from threat actors, while maintaining the end user experience.
That is why we’re extremely excited to announce that native Conditional Authentication is now available for Citrix Cloud customers. We saw our customers often had a variety of reasons for multiple IdPs in an environment – such as company mergers, third-party contractor access, test IdP tenants, or sheer environment scale. Prior to this release, only one type of authentication method was allowed natively. Multiple methods required the use of Adaptive Authentication which relies on NetScaler nFactor, which increases complexity. Native Conditional Authentication is here to bring increased flexibility and operational efficiency to your Identity and Access Management (IAM) configuration.
Why use native conditional authentication?
Conditional Authentication is a new security feature to help further enhance your Zero Trust framework.
One of the core pillars of this new functionality is the ability to create multiple of the same type of Identity Provider (IdP) connections. Prior to today, you could only connect one EntraID (Azure AD), Okta, or any authentication type natively within Citrix Cloud. This limited customers who required multiple IdPs for a variety of reasons, often due to IT mergers or the requirement to use test IdP instances, or during an IdP migration where you would gradually move users from one IdP to the other. Now through our multi-IDP functionality, you can easily add as many IdPs of any type that your environment needs – prod, test, and beyond.
On top of this multi-IDP functionality, we have added the ability to create native authentication flows within Citrix Cloud. This allows end users to have different IdPs during their Workspace login, depending on the conditions configured. At this time, Conditional Authentication has four filter methods: User Group, Workspace URL, User UPN, and User Domain. Based on the policy rules and the policy priorities set by the administrator, the Conditional Authentication policy engine will direct the user to the correct IdP.
Whether you’re testing a new IdP setup through a test Workspace URL, or onboarding another IdP due to a merger – native Conditional Authentication is here to help.
How to get started
You can get started with Conditional Authentication today! Under Identity and Access Management > Authentication you will find the option to ‘Create conditional authentication profile’.
A Conditional Authentication policy is a policy that consists of one or more conditions that will direct a user towards a particular IdP. A Conditional Authentication profile is a collection of Conditional Authentication policies that control how your users authenticate to Workspace. A profile supports policy priority, so you can decide which policies should be evaluated first.
You can create various Conditional Authentication policies and assign them priority within the profile. Be sure to give each profile a familiar name for easy recognition within the IAM console. Then you can assign your Conditional Authentication profile as the authentication method within the Workspace Configuration section of the console.
What’s next
After Conditional Authentication becomes generally available later this year, we’re excited to be able to work on bringing even more functionality to the service.
First on our list is to integrate additional filtering methods into the policy engine. Most notably, adding the network location as a condition for filtering. This will allow administrators to enforce more stringent access control policies based on whether users are connected from the office or at home. Extending this control even further, we are working on integration with the Device Posture service. This would extend the filter settings to include certain requirements that the end devices must meet to gain access to resources.
Learn more
To learn more about Conditional Authentication, be sure to check out our product documentation.
Disclaimer: This publication may include references to the planned testing, release and/or availability of Cloud Software Group, Inc. products and services. The information provided in this publication is for informational purposes only, its contents are subject to change without notice, and it should not be relied on in making a purchasing decision. The information is not a commitment, promise or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for products remains at the sole discretion of Cloud Software Group, Inc.