Enterprises like to provide one single remote access point to all their users. The users can be a mix of laptop users, mobile users, corporate issued device users or BYOD users. Some users might need to use extra authentication methods like a Smartcard to access their resources (eg: finance dept to access sensitive data). Some users want plain simple remote access for webapps or lab environments. Forcing all the users to go through same authentication method would be difficult in this kind of mixed user group.
NetScaler Gateway introduced support for SSL Renegotiation feature in the latest GA release (10.5-50.10). SSL Renegotiation feature enables a client-server pair to perform a new SSL handshake sequence over an existing SSL connection. This feature has very good use cases like providing user credentials on a shopping site only when user decides to buy. This concept is extended to NetScaler Gateway where the server (Gateway) decides to renegotiate only when the user attempts to access certain resources. As part of renegotiation, Gateway will prompt the user to present certificate for validation and only then will the resources be accessible.
How to use SSL Renegotiation feature on NetScaler Gateway?
There are certain configurations required for use of SSL renegotiation on Gateway. Before the latest GA release, enabling clientAuth on SSL virtual server settings of Gateway VIP would force the users to present a valid certificate during login process even though, clientCert was set to “optional”. Hence, it was not possible to allow users with and without certificate on the same Gateway virtual server.
For invoking renegotiation only when required, we need to disable clientAuth SSL parameter on the Gateway virtual server. Also, the deny-ssl-renegotiation SSL parameter, it specifies under what conditions renegotiation feature is allowed, should be set to NONSECURE. One can use the SSL profile to create these settings and set the profile at Gateway SSL entity level. Below given are the sample CLI and GUI configurations for the same.
Then, create a cert-action which has two factor authentication ON. Using a cert-policy, bind this action to the Gateway virtual server.
The CA certificate bindings and configurations remain same as they are earlier. With this set of configs, users with and without certificate can login to the same Gateway virtual server.
For the usecase where user is allowed access to specific resource only if he/she has presented a valid certificate, you can use authorization policies along with above configs. After configuring SSL renegotiation, use authorization policy where the rule checks for the presence of certificate and provides access to backend resource. If rule fails (no cert presented during login), then authorization fails and access to backend resource fails.
Another usecase is, this configuration is useful to reduce the no.of certificate prompts during login process. With earlier builds, when there is EPA configures along with cert-based authentication, user gets multiple prompts to select the user certificate. This is because of multiple SSL connections initiated by browser, EPA plugin and Gateway plugin. With above renegotiate configurations, user will be prompted only during authentication request (/cgi/login) only. Since this request comes only once by either the browser or Gateway plugin, certificate selection is prompted only once.
CLI
> add ssl profile ssl-reneg-pro -clientauth DISABLED -denySSLReneg NONSECURE
Done
> set ssl vserver vpnvs1 -sslProfile ssl-reneg-pro
Done
> add certAction ca1 -twoFactor ON
Done
> add certPolicy cp1 ns_true ca1
Done
> add authorization policy certauthorize “REQ.SSL.CLIENT.CERT EXISTS && REQ.IP.DESTIP == 10.10.10.1” ALLOW
Done
>