Tag: AAA

Using NetScaler as OpenID Connect SP with ADFS as IDP

How do you configure Citrix NetScaler OpenID Connect Service Provider with Microsoft ADFS as OpenID Connect Identity Provider? I’ve tried making it easy to understand and how you do it using CLI (NetScaler CLI and powershell).

Read this post for doing this with SAML.



Using NetScaler as SAML SP with ADFS as IDP

How do you configure Citrix NetScaler SAML Service Provider with Microsoft ADFS as SAML Identity Provider? I’ve tried making it easy to understand and how you do it using CLI (NetScaler CLI and powershell).

Before we begin, let us look at what we need to establish the federation:

  • NetScaler (with at least Enterprise license)
  • Active Directory domain and ADFS (read this post if you want to load balance and use NetScaler as ADFS Proxy)
  • Website (lb vserver) we want to protect with AAA (will be referred to as the service provider)
  • AAA vserver to bind SAML Service Provider policy

In my case, the following FQDNs are used:

  • LB vserver: webapp-test.domain.com / LB-WEBAPP-TEST
  • AAA vserver: sp.domain.com / AAA-SP-DOMAIN.COM (note: it will actually not be access by the web browser)
  • ADFS: adfs.domain.com

When installing ADFS two self signed certificates are issued for Token-signing and Token-decryption. When it comes to the NetScaler, we could always use whatever certificate for the signing and decryption – but I recommend using a certificate that isn’t used for web site communication. That’s why I create a self signed certificate that I use: (note: I do this on my computer, modify the variables to match your environment – and even though this certificate and key is self signed – keep them secure)

The certificate (not the key) needs to be copied to the ADFS server for when we create the Relying Party Trust, and we also need to copy the ADFS Token-signing certificate to the NetScaler (below called adfs.domain.com-signing).

Copy the newly created certificate and key to the NetScaler, as well as the ADFS Token-signing certificate:

Now we need to create the SAML Service Provider action and profile, as well as bind it to the AAA vserver:

(Note: As I stated before, this policy is bound to the AAA vserver but the expression is matching the hostname of the LB vserver – since the web browser actually never is redirected to the AAA vserver in this scenario)

As a last step, create (if it isn’t already) an authentication profile and bind it to the LB vserver:

Now configure ADFS (modify the variables to match your need):

 



Prepopulate username with NetScalers RfWebUI

We’ve been seeing an issue with AAA in front of ADFS where credentials entered at the service provider (Office 365 for example) doesn’t populate the username in the NetScaler login, which works with ADFS. This isn’t the biggest issue, but something that makes it annoying to use AAA instead of pure ADFS. We were able to do this just fine with the cookie NSC_NAME (or even query based) before when not using RfWebUI. Because RfWebUI is the latest and greatest as well as responsive, most want to use it.

I’ve been looking into how to solve this using RfWebUI and may not have found the best solution in the world, but it works reliably and is easy to implement. A big thanks to Sam Jacobs who helped me out with the javascript parts, I haven’t been working with it before so was crucial to tying the knot on the issue.

The first thing I had to figure out was how to extract the username that Office 365 sends to ADFS. We can see the username in the query to ADFS as follows:

Note: It is URL Encoded which means the @ will be presented as %40.

The thing is that when using AAA, a new redirect will be made directly inside NetScaler to the AAA vserver for authentication. I was thinking of either trying to add ”Set-Cookie: UserNameCookie=<email>” somewhere here but I was thinking that this may not work since rewrites doesn’t always work on internal redirects and I may have to add another redirect to an already long chain of redirects – which may cause issues for some browser. What I did find was a cookie named NSC_TASS that contains a long string of random letters, numbers and symbols. After trying some things I was able do decode it by first converting it from URL Encoded format and then from Base64. When doing this, I was able to see the original ADFS URL containing the query with the username. To do this, I had to run the following to get the email/username in the correct format for the NetScaler login:

In other words we do the following: Grab the value of NSC_TASS and decode the URL Encoding. After that, decode it using Base64. Then typecast it to a HTTP URL and grab the value of the query username, and decode the URL Encoding (converting %40 to @ in my case).

Now to the part where I had to get some help to actually insert the username into the form. The solutions works fine, but if you have a better way of doing it please share! We had to put a small loop and wait to make sure the input field is created before the username can be inserted. The result looks like this:

We’re waiting for the window to load, but for some reason that doesn’t mean that the input field ”login” exists (yet) and that’s where the setInterval-loop comes in. Without the loop, I did see it work most of the times on computers but rarely on phones. To make sure that this only happens when being redirected, we’ll be verifying that the cookie NSC_TASS exists and that the referrer length is greater or equal 1. After that we verifies that the element ”login” is created and inserts the username / email and changes focus to the password input.

Now it’s just a matter of using a rewirte to insert this:

If you are using the GUI, the rewrite part looks like this:

I hope this can help some people out there making their end users happier! If you find a way of doing this easier, please share!



NetScaler user authentication to backend with cookies

A system one of my co-workers are load balancing and configuring AAA/SSO uses cookies for authentication. The username is inserted using a cookie, for example ”username=simon”. It’s very easy to first of all identify this cookie and modify it to another value, which makes it insecure.

The idea we got was to stop exposing the cookie to the user and only add it so that the backend sees it using a rewrite. The second thing we also want to do is remove this cookie so even though the user has the cookie, it will never be sent to the backend.

The solution is quite simple and looks like this:

From my initial tests, this will remove all cookies named ”username” (case insensitive) and add a new one with values from NetScaler AAA. If the user isn’t sending any Cookie-header at all, we’ll add one as well.

Seems to work very well!

Have you done this in any other way? Feel free to post how you did it.