Easily Provide Apps, Desktops and secured Web Sites with just one portal URL and SSO!
As we all know NetScaler is the best solution in providing both XenApp and XenDesktop applications and also is very good in offloading and securing web applications. Unfortunately the combination of both, providing web apps and windows apps isn’t possible with just one authentication. This used to be a weakness and isn’t very transparent and comfortable for the user.
Not any more – with our new portal approach we are able to combine the web application features with the good old Access Gateway Enterprise functionality.
How it looks?
The NetScaler provides the login page, as users are already used to.
After successfully logging in, the user gets to a portal site where he sees all applications, whether if it’s a XenApp, XenDesktop or Web application.
When the user clicks the content icon, a new browser window with a web application (e.g. SharePoint 2010) comes up. If a user clicks a XenApp or XenDesktop icon, the ICA client connects the terminal server application or the virtual desktop. The NetScaler takes care of the authentication and provides a single-sign-on to the backends.
With our new portal approach its possible to provide the three common types of application with just one authentication and only one portal URL to remember. Isn’t that awesome?
Some details on how its done
The key components are:
– NetScaler: Provides the centralized access point with following features ( Content Switch, Load Balancers, AAA and AG)
– Citrix Web Interface: Gathers all applications and presents them on one website, controlled by Active Directory groups and Access Gateway filters
– XenApp/ XenDesktop: To provide terminal applications and virtual desktops as well as content links to web apps
– Web Sites: Any website running in your internal network or somewhere in the cloud (e.g. Sharepoint, Exchange Outlook Web Access, …)
By default the NetScaler prevents to put a LB virtual service in front of an AAA or AG resource. To skirt this behavior you need create a chain of load balancers, see below:
Coming from the internet the content switch is located before AAA and AG. It decides based on the content, whether to route the traffic to an AAA virtual server, Access Gateway virtual server or a LB virtual server, providing a web application.
It is necessary to rewrite the Access Gateway authentication cookie. Else NetScaler will delete and AG will reject it . On the first load balancer in front of the AG vServer we bound a Rewriting Request Policy with the following content:
Action: HTTP.REQ.HEADER(“Cookie”).REGEX_SELECT(re!CTX_AAAC!) REPLACE “NSC_AAAC”
and a Rewriting Response
Action: HTTP.RES.FULL_HEADER.REGEX_SELECT(re!NSC_AAAC!) REPLACE “MR_AAAC”
Single Sign On Policy
As the credentials are entered in Traffic Manager they are not automatically passed to the Access Gateway Server. This can be solved with a form based Single Sign On policy:
TM_FormSSO-to_AG -actionURL “/cgi/login” -userField login -passwdField passwd -ssoSuccessRule “HTTP.RES.SET_COOKIE.EXISTS(”NSC_CERT”) && HTTP.RES.SET_COOKIE.EXISTS(”NSC_AAAC”)”
In order to explain traffic flow, here is a short explanation of the process:
1.) Without being authenticated Content Switch routes traffic to load balancer in front of AG. Only with a valid cookie this load balancer can be passed.
2.) In order to authenticate, traffic is routed to AAA virtual server.
3.) Now ordinary logon page is displayed and user authenticates against backend services, like Active Directory and/or Radius.
4.) Containing the encrypted authentication cookie, user now is able to bypass load balancer and gets to AG object.
5.) We implemented a single-sign-on policy avoiding to authenticate against AG
6.) As usual AG authenticates against Web Interface and displays all available resources, such as XenApp, XenDesktop and Web Sites.
7.) To start an ICA connection a separate AG object is being used as ICA proxy.
8.) To open an internal web site, AG can pass the credentials and provides single-sing-on.
Interested? Contact us! NetScaler@provectus.de
Special thanks goes to Peter Leimgruber, Dominic Feser and Maximilian Leimgruber for supporting me during the development progress.