This post has already been read 5964 times!
Firstly, Happy New Year! I hope you all had an enjoyable and restful Christmas and New Year.
Late last year (in fact very late) I was lucky enough to be approached about a project that Rick Dehlinger is running called Project Silverton. If you don’t already know anything about this here are a few links to get you up to speed real fast!
Project Silverton: https://www.mycugc.org/blog/intro-silvertonhcl
Why Silverton?: https://www.mycugc.org/blog/why-silvertonhcl
Taking Flight: https://www.mycugc.org/blog/silvertonhcl-projects-1
If you have read all of them then you will know that my part in this excellent community project is looking into Citrix NetScaler, Federated Authentication and your Google Account to provide a seamless single-sign-on experience for users consuming Citrix on a Chromebook, or any device for that matter!
Initially I was asked by Rick to configure the demo environment within Lab60 – Rick’s SilvertonHCL Lab running on Cisco HyperFlex (which I have to say is lightening fast!). The Basic idea was to provide a single entry point into the lab environment and by using NetScaler and various configurations publish 2 external FQDN’s. First citrix.chromesummit.com for regular NetScaler Unified Gateway Access and login.chromesummit.com for Google oAuth Authentication.
Whilst building out the demo environment I came across lots of “nice to have” things that would not be missed out in any production build. We figured all of these should be included in the demo environment and bolted them onto the initial build to enhance the user experience and provide a more streamlined access method to the apps and desktops.
So onto the purpose of this post.
This is the first of many posts that will come in the following days but more on the remaining posts later.
Initially I will outline exactly what we are trying to achieve, what the moving parts are and how the user is meant to navigate into Lab60 using the various methods.
Then in further posts I will detail how to build out this configuration in your own environment. So, initially an overview of what we are going for then detailed instructions in bite sized chunks about how to build the various components, awesome! The reason for this is that many people will already have part of the infrastructure built to allow this configuration and reading smaller posts will allow you to pick and choose the parts you wish to implement.
The upcoming posts will be:
- Pre-Reqs – What you need in place and some pointers to get these right before you start to look at the oAuth, FAS and NetScaler Integration.
- Google API Configuration – Enable access to the Google oAuth System.
- Federated Authentication – Configure Citrix Federated Authentication Service (FAS) to allow SSO from your NetScaler Google Authenticated Account to your Apps and Desktops.
- NetScaler Configuration – Configure your NetScaler to handle the oAuth Traffic, BOTH inbound URL’s, App and Desktop access using NetScaler Unified Gateway and all the Responders you require.
- StoreFront Configuration – Allow access from your new Unified Gateway(s).
- The Nice Bits – All the extras to enhance that experience for the users.
So, what exactly is the end game?
Essentially we have 1 external IP address accessible for Lab60. We want 2 FQDN’s to be pointed at this same IP Address. One of these will be for regular NetScaler Unified Gateway access and the other for Google oAuth access to the same Apps and Desktops.
This will be used for regular access to a NetScaler Unified Gateway. We want to provide access from all the usual devices to the apps and desktops within Lab60 using LDAP as the authentication method.
This will be used for Google oAuth authenticated sessions into Lab60. We want to pass off authentication to the Google oAuth service when this FQDN is used and then (once authenticated) hand the user back to the NetScaler and onto StoreFront. This will then use FAS to authenticate the user and enable them to launch the apps and desktops in the same way as if they had logged in using their LDAP credentials.
Both Web and Native Receiver (where applicable) access should be catered for on all devices including (and the purpose of this blog series) Citrix on a Chromebook.
Finally, we want to secure the entry points into the Lab60 environment and make the experience as seamless as possible for the end user (http to https redirection as an example).
So, that’s it for now. Hopefully you will get an idea of what the demo environment looks like and what this series of articles will help you to build.
Below are 2 videos of the demo environment in action.
The first is citrix.chromesummit.com being used from a browser and Receiver as you would in most normal Citrix environments.
The second is login.chromesummit.com being used firstly as a user that is NOT currently logged into their Google account, then as a user that is already logged into Google and finally using Receiver we want to pass the user back to the standard LDAP authentication as we don’t want to use Google oAuth for Receiver.
Ready to move onto the pre-reqs? You can find them here.
Dave Brett (@dbretty)