NetScaler SAML and Okta

These days, SAML authentication is mainstream and web services are expected to support it in some fashion or another; the SAML 2.0 standard is over 10 years old at this point! One of the key areas of focus for NetScaler is Authentication and Authorization and as such you would expect full support of SAML – and you’d be right. But if you’ve never worked with the SAML protocol, it can seem very daunting at first!

The basic idea behind why you need or want SAML is that you want to have some other ‘party’ be authoritative for authentication – other than what 99.99% of enterprises use for authentication, you know…Microsoft Active Directory. The problem with AD is that it only understands username\password and certificate based authentication – if you try to talk federation, it just won’t work natively.

There are three basic concepts with SAML: the Service Provider (SP), Identity Provider (IdP), and the Assertion. The SP provides something that the user needs – an application or service for example. The IdP is the thing that authenticates, or validates the identity of the user. The assertion is a means of communication between the two – SAML is based on XML, so the assertion is mostly human readable. In it’s current build, the NetScaler supports acting as an IdP, an SP, or even both.

NetScaler and SAML

The NetScaler has supported SAML as a Service Provider since the 10.1 build, but there are a ton of different features and functionality that you need to be aware of. If you are looking to do a SAML project with NetScaler, I would recommend at least NetScaler 11.0 build 64.34 to get the most supported features.

NetScaler as Service Provider NetScaler as Identity Provider
NetScaler 10.1 •Signing & Digest: SHA1 only

•Single attribute only

•Signature enforcement

•POST binding only

•NO: Encryption, single logout, AuthnContext, Holder of Key, Certificate Thumbprint

NOT SUPPORTED
NetScaler 10.5 •REDIRECT binding •POST binding only
NetScaler 11.0 •Attribute Names up to 127 bytes

•Timed Assertion Validity \ Clock skew

•Added ARTIFACT Binding

•Client Certificate Logon

•SAML Session Cookies

•HTTP 401 Authentication

•Multiple Attribute Configuration

•Redirect binding added

•Timed Assertion Validity \ Clock skew

•Pre-configured Trusted SP

NetScaler 11.1 •FIPS offload support with signing support now available using SAML bindings: REDIRECT & POST

•FIPS – Only SHA1 supported

•SAML IdP Complete message signing

•RSA 1.5 encryption support

•FIPS offload support with signing support now available using SAML bindings: REDIRECT & POST

•FIPS – Only SHA1 supported

Why Okta?

Because they give stuff away for free!!! If you have never worked with SAML before, if you’re trying to brush up on your SAML skills, or just want a publicly available SAML provider for your lab or testing, go check out Okta Developer – it’s completely free, and gives you everything you need to test, troubleshoot, and understand the SAML protocol. You get a dedicated SP or IdP with a public URL, 3 application definitions, and 100 users – FREE! Plus, you can integrate your Active Directory as well.

adint

A Few Notes

There is a LOT to understand about SAML, which I’m not going to cover in this post, instead, I’ll point you to this post here. But there are a few things you need to be aware of:

  • Configuring SAML is not very difficult – essentially, you are configuring two services to talk to each other, and the configuration must be identical on both sides
  • Some providers have different names for the same things, so be careful
  • The most common binding methods HTTP REDIRECT and HTTP POST do not require a direct connection between the IdP and SP – the assertion is carried by the user client, most commonly a web browser
  • SAML relies on timestamps, just like Kerberos does, so NTP must be healthy on your NetScaler (and across your entire network)
  • SAML supports both signing of the assertion to prevent tampering as well as encrypting the assertion with a certificate
  • The SAML endpoint on the NetScaler is always: https://gateway.fqdn.com/cgi/samlauth
  • I recommend configuring the IdP first – there are several things you will need for the SP that are only available after you configure the IdP
  • IdP initiated flow
    • User logs on to identity provider and is presented with a list of applications; once an application is selected, the assertion is sent to the client then passed to the SP configured for that application
    • Users will see the IdP application list
  • SP initiated flow
    • User opens URL to SP, but is redirected to IdP for authentication; once successfully authenticated, the assertion is passed back to the client then sent to the SP
    • Users will see the SP application list

Single Sign-On Considerations

Single Sign-On is great for users because it allows them to only have to remember one set of credentials and enter those credentials one time. The problem with SSO is that it is becoming more complex – especially when you start using different authentication protocols and have on-premesis resources mixed in with cloud\SaaS applications. But don’t give up hope! Just understand what you can do with what you have.

When we are talking about SAML, it is important to understand that the password is NEVER sent in the assertion. This is a problem because it limits what we can do with SSO – and this is not a NetScaler limitation, but a limit of authentication in general. When we have a users password, we can do all sorts of authentication: Forms, HTTP Basic, NTLM, Kerberos – note that’s Kerberos Impersonation – aka: “easy Kerberos”.

If I’m using SAML and I don’t have the users password, the only options for single sign-on are: SAML or Kerberos Constrained Delegation (KCD). If KCD or SAML to the backend is not an option, you can use step-up authentication to gather the users password, but this will obviously be another prompt for password, so it’s not optimal.

Configuration Example

Here are the screenshots of a basic configuration example – this is for the NetScaler as SP and Okta as IdP, using an SP-initiated flow (remember, configure the IdP first) – first, create a basic SAML application in Okta.

okta1

Then configure the ‘Advanced Settings’:

 

okta2

Once you are done, Okta will present you with a few things that you will need to configure the NetScaler as SP – click the ‘View Setup Instructions’ to get the certificate, redirect URL, and other fields needed:

oktaapp3

Now you can move on to configure a SAML authentication profile on the NetScaler:

ns1

Don’t forget the advanced settings in the ‘More’ section:

ns2

That’s it!

There are numerous different configurations available – this post just covers one of them. Note that XenApp and XenDesktop don’t natively understand SAML authentication, they need the Federated Authentication Service introduced in XenDesktop 7.9. If you would like to see all of this in action, check out the October 2016 NetScaler Master class – available On-Demand here.

 

4 thoughts on “NetScaler SAML and Okta

  1. Hi Jacob, thanks for very good article! I was just wondering in your Okta configuration example, under ‘Advanced Settings’, which certificate have you used for Encryption? Also why “Single Logout” i sleft unchecked in Okta config, while you do specify it in NetScaler SAML Server config?

    Thank you!

    BR Zoran

  2. Zoran, you can use most any certificate – it does not need to be a code signing cert for example. I used the same certificate as the one that secures the AAA vServer.

    The Single Logout setting in Okta is left unchecked as it would only be needed if Okta were sending a logout to the NetScaler – in that case, the logout url of the NetScaler is https://fqdn.authvserver.com/cgi/tmlogout

  3. Great post – once the user has authenticated with an Okta SAML token to the Netscaler, is it possible to then send that same token back to the server behind the netscaler? Or what is the best way for the user to authenticate to the application running on the backend server? It seems like just authenticating to the netscaler is only the first step in gaining access to the application.

    • Jeremy- it is possible to do an authentication protocol transition. Since the incoming assertion likely only includes a username or email address (not the password) the NetScaler will only be able to do SAML auth to the backend, or KCD.

      The other option would be to prompt for password (step-up auth) then we would be able to do nearly any kind of authentication to the backend server.

      This is a limitation in authentication protocols – when I don’t have a password, I can’t do Kerberos impersonation (or NTLM, or 401\forms auth…) and can only pass the existing SAML assertion or do KCD.

Leave a Reply