Smartcard authentication: Most of you are probably fully aware already of this method and how to configure XA/XD backend for Smartcard auth.
With Receiver for Chrome 2.1, there are two more additional options: We are essentially avoiding authentication here. Again this may not be applicable to every use case. This is very useful especially for Kiosk mode use case. Until the release of Receiver for Chrome v2.0, anonymous logon was the only option to avoid passwords. Of course if Receiver for HTML5 meets user’s needs then just keep using the light version!Īnonymous 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. If Receiver for HTML5 is not deployed then older storefronts should also work. You can also let Receiver open ICA files like below: Storefront v3.6 is useful in this case ,mainly for the availability of “Change Receiver” option. This also means users can use multiple stores via different browser tabs, which is not possible if entering Store URL inside Receiver for Chrome. Since the browser allows users to save username/password, this is convenient. When a user tries to launch an app/desktop, ICA file, which can be double clicked to launch sessions, is downloaded.
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.For example, let users login once at start of work and let the logon session expire after work hours. Increase session timeout to make logon cookies stay longer.Receiver for Web has a default timeout of 20 mins, unless the user interacts with the page. Unfortunately, in the current design, this is not possible, as Receiver for Chrome doesn’t control the login flow while entering credentials. Username/Password: the most common method is active directory username/password and a common request is ability to save/remember credentials. 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. 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).Īny customization made in Receiver for Web, like branding, styles etc., immediately applies to Receiver for Chrome. 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. NetScaler Application Delivery Management.NetScaler App Delivery and Security Service.
0 kommentar(er)
