SSO to SaaS

I have 174 passwords! (Actually I now have 175 – added a new one today)

Most of those passwords are for web and SaaS apps.

You know what people say, misery loves company and many of you know exactly what I have to deal with.

The Citrix Access Control service focuses on providing single sign-on (SSO) to SaaS and web apps. Actually, based on my look at the service, it provides 3 distinct capabilities

1. SSO to SaaS and web apps
2. Enhanced security for SaaS and web apps
3. URL filtering within SaaS and web apps

SSO
As of August 2018, Citrix Access Control is based on SAML. I’m not an authentication expert, so I had to do some studying to better understand how SAML works. A big part of this is to get a grasp of the lingo

1. Principal: who/what is signing in (this is often the user)
2. Identity Provider: the entity that verifies the principal is who they claim to be
3. Service Provider: The entity a principal wishes to access (a SaaS app)
4. Assertion: the identity provider’s proof the principal is who they say they are

How this works in Citrix Workspace is as follows:

The Gateway service uses the SSO micro service to get an assertion saying the user successfully authenticated to the identity provider. This assertion must get sent to the SaaS app, which is part of the SaaS app configuration within Access Control as the “Assertion URL” in the following image.

Workspace app uses Assertion URL (unique for each SaaS app) and presents the assertion. What makes this part easy, is that when you use one of the SaaS app templates within Access Control, most of the Assertion URL is preconfigured.

In order to link the user within our identity provider with a user in our service provider, we need an attribute(s) that is identical between the two. In many cases, the user’s email will suffice, which is shown in the previous image.

With the identity provider side complete, we now must configure the other side, the service provider (SaaS app).

The SaaS app needs to know the URL to verify the assertion (who originally requested the assertion for the user), which is the entity ID within the metadata file.

In addition, because we don’t want to send our assertion unencrypted, the SaaS app needs the certificate to successful decrypt and read the assertion. This is also contained within the metadata file as the X509 Certificate.

Hopefully, that sheds some light on how SSO to SaaS and web is accomplished within the Access Control service.  SSO is just one aspect of the Access Control service.

1. SSO to SaaS and web apps
2. Enhanced security for SaaS and web apps
3. URL filtering within SaaS and web apps

Daniel (Follow on Twitter @djfeller)
Citrix Workspace Poster
XenApp/XenDesktop On-Prem Poster
XenApp/XenDesktop Cloud Service Poster