Citrix Workspace Authentication: Okta

None of us likes starting over. So if we don’t have to, why would we?

Unfortunately, with technology, many of us are forced to to follow a single path. That single path often requires us to start over. But this is one of the interesting things about Citrix Workspace and the user’s primary identity… Don’t start over – Simply integrate.

With an overall understanding on primary/secondary identities within Citrix Workspace, we can better understand how Citrix Workspace integrates with Okta as an identity provider for a user’s primary identity.  If our organization has standardized on Okta for identity, why would we want to move away from it to utilize a digital workspace?

Citrix Workspace simply brokers identity to your preferred identity provider, then leverages the user’s identity to generate of list of authorized resources to access.

Citrix Workspace accesses an OpenID Connect application created within Okta. The application authenticates the user with Okta, receiving two tokens in response:

  • Access Token: Provides proof that the user can access the Okta resource
  • Identity Token: Provides claims (info) about the authenticated user.

One of the interesting things about how this works is that the tokens sent back to Citrix Workspace are not impacted by any Okta MFA configurations. Okta authentication is a separate process from Citrix Workspace. If Okta configuration is based on password, SMS, TOTP (software/physical), Push, YubiKey or Windows Hello, then the result back to Citrix Workspace are the two tokens validating the user’s identity and authorizations. Your Okta admin can change the authentication policies without impacting Citrix Workspace.

This is extremely important because chances are the person responsible for Okta in your organization will most likely not be the same person responsible for Workspace.

Once Citrix Workspace receives the claims contained within the identity token, the resource feed micro-service is able to generate a list of authorized resources. The claims are important because different resource feed types have different requirements on the claims returned by Okta.

  • SaaS and Web apps: Uses the native Okta identity claims
  • Windows-based apps: For Citrix Virtual Apps and Desktops (VDI), the Okta ID must be linked to an Active Directory account. The identity token returned by Okta must include the user’s Active Directory SID, UPN and GUID.

This is for authorization. When user’s launch one of these resources, we must authenticate to the resource, which is often categorized as Single Sign-On.

  • SaaS applications: Utilize SAML-based authentication
  • Windows apps/desktops:  Utilize the Federated Authentication Service, which is able to use the Active Directory-based claims within the Okta identity token to provide single sign-on to Citrix Virtual Apps and Desktops (a topic for a future blog)

Take a look at the setup and user experience

Daniel (Follow on Twitter @djfeller)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.