NetScaler Gateway: SAML with multiple IDPs using nFactor

Both SAML as well as nFactor are two NetScaler features that are highly underrated in my opinion. In this example I’ll share with you how I did combine them in a customer deployment to create a quite unique login experience.

Background

In the deployment in question I had one customer with the following requirements:

He’s running NetScaler Gateway along with a XenApp/XenDesktop farm

They wanted to provide access to a variety of different independent organizations

Ideally authentication should use SAML on NetScaler along with Citrix Federated Authentication Service (FAS) within XenApp/XenDesktop

The customer wanted to provide a single URL for all access to that service

This way each organisation that get’s on-boarded just needs to setup an ADFS server, provides the IDP certificate and could be integrated with a minor NetScaler configuration. The customers would retain authority about their user directory and users could re-use the credentials they’re familiar with.

Solution

The solution, as you might have guessed, was nFactor. After accessing the service the users are asked for their E-Mail address.

Based on this the user is then getting redirected to their respective organization’s IDP.

This is realized by a two-stage nFactor configuration in which the first stage gathers the username and the next factor is determined based on the E-Mail suffix provided.

Now I won’t go into every detail of how nFactor works. That will be worth an article on it’s own. For now you could find some background in the product documentation Multi-Factor nFactor Authentication

On a high level, the configuration for the described scenario looks as follows:

Next you’ll need the Authentication Policy which will be of type NO_AUTHN. This results in the first factor always being successful since we’re only gathering information. The actual authentication is completely up to the second factor.

Resulting User Experience

If a user logs in with a non-configured Domain he’ll receive a error message:

Customizations to the Login Schema

One of the great features of nFactor is the fact that you can finally fully customize your login form. So if you actually want to ask for an E-Mail instead of a UPN you can simply copy and customize one of the Login Schemas in /nsconfig/loginschema/LoginSchema/

Based on the OnlyUsername.xml I’ve created the following OnlyEmail.xml for example:

Thank you for sharing this information. This is a bit over my head at the moment, and I’m trying to learn and implement this, and you’ve documented it well enough that I *THINK* I understand whats happening! I have a question regarding the following line —

Hi Joe, thanks for the feedback and glad you find it useful! I think you might be right! Sadly I dont have my PoC running anymore so I hope I’ll manage to test this again some day to (potentially) correct the article.

I’m having some problems getting this to work right. I’m never prompted for the username, it just moves forward to my SAML authentication (which fails, but I believe that is unrelated). I don’t ever get the OnlyUser.xml to display.

Hi Joe, I’ve actually seen this happening before in some newer versions of NetScaler – but I don’t know if it’s fixed in the latest version. Are you using the latest build?

However, there is a workaround!
Apparently it seems that NetScaler doesn’t display Factors with only NO_AUTHN policies anymore – why? I don’t know.
So what you can do is add any second, lower (higher number) priority, policy. For example a LOCAL one. Just as a dummy.
This will make the factor to be displayed again. However, this second dummy policy will never match due to the lower priority.
That worked for me in one scenario where the above config failed after an update.

You mind sharing your firmware and result – if successful?
I’d then include a note in the article.

I actually got around this and was coming here to update you. I’m currently on 12.0 56.20.

I found CTX226488 that detailed the creation of a noauth policy. It says to use “http.req.url.contains(“/nf/auth/doAuthentication.do”)” as the rule instead of True. Sure enough, it works every time now!

Now I just have to figure out how to get my SAML actions set right. I’m getting errors from azure telling me that request property Subject is not supported. So much fun! :)

Nice! I wasn’t aware of that one. Probably a cleaner solution than the dummy-policy. Thanks for sharing!
You’re welcome! I’m happy to get more people hooked on playing around with the mighty nFactor :-)

This is a great article that fits exactly a scenario that we are trying to work through. However, we are having an issue federating with AzureAD as the IDP. After the Netscaler captures the username, it inserts it as the subject in the SAML request. AzureAD apparently does not support subject in SAML requests, despite documentation indicating that it would just ignore it. If I authenticate without capturing the user name first, the request is sent without a subject and authentication is successful.

I realize that this is a Microsoft problem, but I thought I might have better luck fixing it on the Netscaler than getting Microsoft to change. Any ideas?

Hi Wes, I’m not sure but the first – and only – thing that comes to my mind is traffic policies.
The NS forwarding credentials seems like a default behavior that might be hard/impossible to change.

Two things come to my mind – just wild guesses though
– in nFactor schemas when you drop down the “advance options” (or something similar) I think you can set username and password fields – maybe you can work with that
– in traffic policies you can actually tweak what is used for a SSO – it might be a very remote guess but maybe that can be used to be applied in this case as well (https://netscalerrocks.com/netscaler/flexible-sso-in-build-10-5-56-12/ has some indication on what I mean)