Last one (for now); having SSO all the way to the application is critical for users and from security perspective. And most importantly; achievable with NetScaler.
Overview
In the example the web application acts as an OIDC SP, using NetScaler as an OIDC IdP. NetScaler authentication itself is similar to the previous post, so it’s acting as a SAML SP for the Microsoft Entra. With this setup we’re able to achieve SSO to the application using modern authentication capabilities.
AAA processing
- User initiates a connection to https://prodsystem-sso.customer.com/system/login?oidc=aaa.company.com (if needed, the NetScaler can redirect user from the root path to the proper URL path)
- NetScaler Proxies the request to the web front end server
- Web front server is configured as an OAuth SP and the traffic is redirected to https://aaa.company.com/logon/LogonPoint/tmindex.html
- NetScaler proxies the OAuth SP redirect response to the client
- The browser requests https://aaa.company.com/logon/LogonPoint/tmindex.html
- 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/…
- The browser requests https://login.microsoftonline.com/…
- An authentication challenge is presented (based on Entra ID Conditional Access policy)
- A successful authentication
- SAML assertion is added for the user session and the session is redirected back to https://aaa.company.com/…
- The browser requests https://aaa.company.com/… (with SAML assertion) and the session is authenticated and OAuth tokenized
- 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)
- A list of groups is collected from LDAP
- User session is redirected back to the original URL https://prodsystem-sso.customer.com (with OAuth access token and authentication cookie (NSC_AAAC))
- The browser requests for https://prodsystem-sso.customer.com (with OAuth access token and authentication cookie (NSC_AAAC))
- The load balancing vServer proxies the traffic to the web front (optionally checks for AD group-based authorization), SSO is done using the NetScaler issued OAuth access token.
- A session is established from the NetScaler to the backend
- An authenticated (and optionally authorized) session is established
- OAuth refresh tokens are updated between NetScaler (OAuth IdP) and web front server (OAuth SP)
Summary
The motive for doing the setup above can vary, but for example the corporate policy could dictate that all application authentication should use SAML, but the web application only supports OIDC. This way we can meet the authentication requirement, but also have SSO.
With commonly used OIDC/OAuth2 we need to bear in mind that the the application server needs to communicate with the IdP token endpoint and if that’s in the internet, it might not be safe to allow the server to connect to internet.
In the example we’re using SAML in the front and OIDC in the back, but we could do the other way around. We could also hook NetScaler up with Google Identity or Okta (we’ve done several implementations!).
Followup
Reach out to us!
There you go, a couple of examples as promised. There’s a lot of NetScaler here, but the concepts apply to many others as well, feel free to apply them to the product of your choosing. If you need help though, we’re most familiar with NetScaler (and migrating stuff from other vendors to this great product).
I’m geared up (as you can see) for a call or F2F, just drop me an email at kari.ruissalo@comping.fi if you want to work with us at Comping.
The cat is not part of the deal, but I’m familiar with the command (“cat” and also “tail”)!
