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
- SSO to SaaS and web apps
- Enhanced security for SaaS and web apps
- 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
- Principal: who/what is signing in (this is often the user)
- Identity Provider: the entity that verifies the principal is who they claim to be
- Service Provider: The entity a principal wishes to access (a SaaS app)
- 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.
- SSO to SaaS and web apps
- Enhanced security for SaaS and web apps
- 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
Ask the Architect 
So does the SSO with Workspace app only work with Citrix Cloud? Or will this work with on-perm and NetScaler setup?
LikeLike
As part of the Access Control service, it is only available with Citrix Cloud and Workspace. However, you can use no-prem NetScalers to create SSO to SaaS apps using the NetScaler UI, but they won’t get included in Workspace.
LikeLike
Thanks for the reply.
LikeLike
Nevermind, I found my answer sorry for the noob question. 🙂
LikeLike
Hi Daniel. Great post series about Citrix Workspace, which I am currently working with. I was wondering if you have any experience with SaaS applications that are already configured for SSO with ADFS? I am having trouble getting these to work. It works fine without access control, because that just launches my local browser which uses my Windows credentials to sign in to f.ex. FreshDesk and O365. But when I enable Access Control on them to use the enhanced security, SSO fails, apparently because the embedded browser does not send my local username/password through to the SaaS application. I am wondering if there is any option to use the “Relying party” feature in ADFS, to make the Citrix Identity Provider micro-service collaborate with our ADFS. I hope you get my meaning…
LikeLike