Many of you probably already know that Receiver for Chrome leverages Receiver for Web for authentication unlike other native Receivers, like the ones for Windows and Mac. This is not necessarily a disadvantage, as it means Receiver for Chrome can potentially support all auth methods supported by Receiver for Web or Netscaler gateway from day one (for example, two-factor authentication, tokens, username/password, and so on).
Any customization made in Receiver for Web, like branding, styles etc., immediately applies to Receiver for Chrome. I couldn’t possibly try to create a comprehensive list of every single method here, but I would still like to look at few important ones.
Username/Password: the most common method is active directory username/password and a common request is ability to save/remember credentials. Unfortunately, in the current design, this is not possible, as Receiver for Chrome doesn’t control the login flow while entering credentials. Receiver for Web has a default timeout of 20 mins, unless the user interacts with the page. You could try a couple of things below:
- Increase session timeout to make logon cookies stay longer. For example, let users login once at start of work and let the logon session expire after work hours.
- Another indirect way is to use the browser to login to Receiver for Web, instead of using Receiver for Chrome UI, if using Storefront 3.6. “Change Receiver” can then be used to use full version i.e. Receiver for Chrome. When a user tries to launch an app/desktop, ICA file, which can be double clicked to launch sessions, is downloaded. Since the browser allows users to save username/password, this is convenient. This also means users can use multiple stores via different browser tabs, which is not possible if entering Store URL inside Receiver for Chrome. Storefront v3.6 is useful in this case ,mainly for the availability of “Change Receiver” option. You can also let Receiver open ICA files like below:
If Receiver for HTML5 is not deployed then older storefronts should also work. Of course if Receiver for HTML5 meets user’s needs then just keep using the light version!
Anonymous sessions: One of the reasons that different methods are used instead of active directory credentials, is for additional security and also not having to type passwords. Until the release of Receiver for Chrome v2.0, anonymous logon was the only option to avoid passwords. This is very useful especially for Kiosk mode use case. Again this may not be applicable to every use case. We are essentially avoiding authentication here.
With Receiver for Chrome 2.1, there are two more additional options:
Smartcard authentication: Most of you are probably fully aware already of this method and how to configure XA/XD backend for Smartcard auth. Please refer the documentation for configuring Smartcard auth in ChromeOS to learn more details.
A few points to note for smartcard authentication with Receiver for Chrome:
- Google Smartcard connector. This app, written by Google, interacts with USB smartcard readers on the device and exposes PC/SC Lite APIs to other apps including Receiver.
- Certificate providers: Middle ware apps written by vendors interact with Smartcard connector, access Smartcard reader, read certificates and provide Smartcard certificates to ChromeOS. They also implement signing functionality so any PIN prompts are shown by these apps. An example is CACKey. Please refer to “Deploy Smartcards on ChromeOS” for more details on connector and middle ware apps.
- Receiver for Web/NetScaler Gateway: When Smartcard auth is configured on a Storefront, Receiver for Web requests ChromeOS to present client certificates on the Smartcard. Chrome OS presents the certificates it received from providers. PIN prompt is shown here to continue authentication. Receiver for Web has whitelist of allowed OS(es) for Smartcard Auth. Storefront 3.6 now whitelists ChromeOS as well. For earlier versions of Storefront, custom script can be used to allow Smartcard auth on ChromeOS. Please contact Citrix support if you need custom script.
- Receiver doesn’t control Smartcard auth flow with Storefront. However in few cases Storefront might request user to close the browser to clear cookies.
In this state, reload button added in Receiver for Chrome 2.1 is helpful to clear all cookies and load Store URL again. Signing out from Chrome device might also be needed if it still doesn’t resolve the issue.
- Once user tries to launch app/desktop, Receiver does get involved via Smartcard redirection. It interacts with Smartcard connector app for PC/SC lite APIs. Any PIN prompts required for Windows logon are shown within user session so Certificate providers play no role in this. Any in-session use like double hop or signing email is again fully handled by Receiver.
- When using Netscaler Gateway you need to follow the configuration mentioned at http://support.citrix.com/article/CTX200137. Otherwise you might see Receiver showing error SSL_CLIENT_AUTH_CERT_NEEDED when launching sessions.
For a quick video demo see: Smartcard Authentication with Chrome.
SAML SSO with Federated Authentication service: The last option I want to share is SAML based SSO. Again this is not really specific to Chrome devices. Netscaler gateway supports many different third party identity providers for authentication including SAML.
Once gateway auth is done, there are couple of options. First is Federated Authentication from XenApp/XenDesktop 7.9 that lets user logon to apps/desktops using virtual smartcard certificates which could also be used to sign documents/email. Other option is with XenApp 6.5 where Kerberos Constrained Delegation (KCD) can be used.
On Chrome devices, Google lets you configure SAML IdP for logging onto chromebooks. Chrome also makes SAML cookies used for chrome device logon to be available in browser. This means if you try to visit a website, like our Netscaler Gateway, which authenticates to same SAML IdP as Chrome device, then you would be already logged on.
Once we tie all these pieces together we have SSO in Chrome and Receiver. Please refer to SAML SSO with Receiver for Chrome configuration for detailed information.
Here are a few important steps to note:
- Make chrome devices use SAML IdP to logon by configuring SAML based Federated SSO in Chrome. For e.g. Let users logon to Chrome devices via ADFS 2.0 AD accounts.
- Make SAML cookies available to Receiver. By default only browser has access to these. SAML SSO for Chrome Apps extension, again written by Google, lets cookies be accessible to other apps like Receiver. For security reasons, Extension only does this when Google policy is configured.
- Configure NSG to do SAML auth with same IdP. Configure federated auth in XA/XD 7.9. Technically KCD should work with XenApp 6.5.
- Add Google policy to make Receiver use NSG that has SAML auth configured and pre-install Receiver. This is optional but improves the user experience as users see Receiver already present after logging on to Chrome device, and when they launch Receiver they see that they are already authenticated with Storefront.
- Since this works with Google policies, this is mainly applicable if you are using Google Chrome management.
For a quick video demo, see: SAML SSO with Receiver for Chrome
Please note that most of these authentication options are available for Receiver for HTML5 as well except Smartcard authentication.
Hopefully, this helped you in knowing few important authentication options. Looking forward for your feedback on any of the topics.