Federated authentication, NetScaler as SP

Second one – are you ready? I think this one is a bit more interesting and something you might run in to!

Overview

In the example the reverse proxy is protected with Microsoft Entra ID authentication capabilities. NetScaler is configured as SAML SP for Microsoft Entra ID and no SSO for the destination web front end is performed.

AAA processing

1. User initiates a connection to https://prodsystem.company.com (if needed, the NetScaler can redirect user from the root path to the proper URL path)
2. As the session was unauthenticated, the NetScaler AAA-TM redirects the user to the NetScaler authentication form page https://aaa.company.com/logon/LogonPoint/tmindex.html (in this example a separate authentication host name is used for the authentication services, which is shared with other services, due to this only one Enterprise Application is needed for the Entra ID, but the authorization needs to be done in NetScaler as the Entra ID only “sees” the shared authentication service)
3. The browser requests https://aaa.company.com/logon/LogonPoint/tmindex.html
4. As the authentication settings for https://aaa.company.com/logon/LogonPoint/tmindex.html are configured to always authenticate with Entra ID the user session is redirected to https://login.microsoftonline.com/…
5. The browser requests https://login.microsoftonline.com/…
6. An authentication challenge is presented (based on Entra ID Conditional Access policy)
7. A successful authentication
8. SAML assertion is added for the user session and the session is redirected back to https://aaa.company.com/…
9. The browser requests https://aaa.company.com/… (with SAML assertion) and the session is authenticated
10. After a successful authentication and LDAP bind the group membership for the user is queried (with the UUID in the SAML assertion, matches the on-prem LDAP userPrincipalName attribute)
11. A list of groups is collected from LDAP
12. User session is redirected back to the original URL https://prodsystem.company.com (with authentication cookie (NSC_AAAC))
13. The browser requests for https://prodsystem.company.com (with authentication cookie (NSC_AAAC))
14. The load balancing vServer proxies the traffic to the web front (optionally checks for AD group-based authorization), SSO is possible but only by configuring the NetScaler AAA as an IdP (for SAML or OIC/OAuth2). Basic authentication (username & password) is not available as the authentication was performed on Entra ID and the NetScaler relies on the SAML (which doesn’t include username and password by default)
15. A session is established from the NetScaler to the backend
16. An authenticated (and optionally authorized) session is established

Summary

Your business might require showing some legacy web application to the internet and it should be supported with a wide range of endpoint types (mobile phones, tablets, laptops, media screens, you name it), but the application doesn’t have any modern authentication capabilities. Using the NetScaler as an authenticating reverse proxy can greatly improve the security together with Microsoft Entra ID (or some other IdP like Google, Okta, etc…).

We have been involved in many projects where the NetScaler capabilities have been recognized and the existing proxy solution has been replaced with it.

Followup

Last one will be out tomorrow

In the last post of this series we’ll discuss about “chained federation” (I’m not sure, if this is a real thing, but it was something I came up with!).

Convinced? Any questions?