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.

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.

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.

Then configure the ‘Advanced Settings’:

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:

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

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

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.

The post NetScaler SAML and Okta appeared first on SeriousTek.