Many of our customers, including the US Department of Defense, are mandated to include consent banners for users accessing any computing system. This blog will walk you through the steps required to configure and enforce a user consent banner prior to smart card authentication for ICA users accessing NetScaler Gateway.
Before reading further, I highly recommend you read my previous article — Reducing PIN Prompts with NetScaler Gateway and Smart Cards — as I will be using this architecture as a basis for this blog. I also recommend you read my colleague’s article — How to Easily Host a Multi-Auth Landing Page on NetScaler Gateway — as it has similar configurations that will familiarize you with how to make a basic Responder Policy web page. This configuration also relies on Optimal Gateway Routing at StoreFront to separate out the Authentication Gateway from the ICA Proxy Gateway so check here if you are unfamiliar.
I’ll also caveat that this is mainly geared at organizations mandating smart card authentication at NetScaler Gateway. This blog can easily be adapted to work with a single, non-smart card Gateway.
Architecture Summary
To baseline we’ll start with the diagram from my previous NetScaler Smart Card article linked above.
We will be using the two Virtual Servers (vServer 1 and vServer 2) on the external network to apply Responder Polices which enforce a consent banner. An HTTP cookie will be used to track the users acceptance of a consent banner. To enforce this, we’ll be checking for the existence of the cookie before allowing the user to authenticate at vServer 1. If they do not have the cookie, they will be presented with a consent banner from vServer 2 before they are allowed to authenticate. One difference in the architecture I will propose, is that users will be browsing to the ICA proxy Gateway first, rather than the access front-end Gateway. This is to prevent users from being prompted for smart card authentication prior to accepting the consent banner.
To facilitate this, the user flow will follow this process:
- The user browses to the ICA Proxy Gateway (vServer 2) which is not configured to ask for SSL client certificates. A Responder Policy checks for the existence of the acceptance cookie. It does not exist, so the user is presented with the consent banner web page. This is a small change from my previous article where users browse to the access front-end (vServer 1) first.
- The user clicks ‘Accept’ which executes a JavaScript function to set the acceptance cookie and force a reload of the web page.
- The consent banner page is reloaded, and the Responder Policy checks again for the cookie. This time it exists so the user is HTTP 302 redirected to the access front-end (vServer 1).
- A Responder Policy on the access front-end (authentication) Gateway checks for the acceptance cookie. The user has the appropriate cookie and the Responder Policy does nothing. They are now able to authenticate into the system. If the user attempts to browse directly to the authentication Gateway without consenting to the access policy page (no browser cookie), the Responder Policy will redirect them to the ICA Proxy Gateway housing the consent web page.
Components and Lab Configuration
To demonstrate this, I will be using the following components:
- A cookie (acceptEula) that will be used to track the consent banner acceptance. This will be a session cookie that will be cleared once the user closes their browser. You can choose to expire the cookie sooner if desired. I have also set the domain and path settings for the cookie to make it available for any server in my stg.home lab domain.
- Three Responder Policies and three Responder Actions to present the consent web page and to redirect users as necessary. These policies will check for the existence of the acceptance cookie before taking the appropriate action.
- HTML code to display the consent banner page as part of a Responder Action. A JavaScript function is set to execute when the user clicks an ‘Accept’ button. This JavaScript will set the acceptance cookie using cookie and then force a reload of the page using location.reload(true).
Three NetScaler Gateway Virtual Servers for authentication, ICA proxy, and StoreFront callback (as in the diagram above) will be used.
- auth.stg.home: Only provides smart card authentication into the environment. ICA proxy is disabled. We will configure this server to redirect to ica.stg.home if the acceptance cookie is not present.
- ica.stg.home: This provides ICA proxy capabilities and will also respond with our consent banner web page. It will check for the existence of the acceptance cookie. If the cookie does not exist, it will respond with the consent banner page. If the cookie is present, it will redirect the user to auth.stg.home for authentication. This is also the Gateway that users will access directly with their browser.
- callback.stg.home: Used for StoreFront callback. Does not need to be modified.
Caveats
- This does not work with native Receiver! Receiver does not accept HTML redirects or display of custom pages, so this configuration will only apply when using a browser to access the environment.
- While this will enforce the consent banner for most users, it is possible for someone to directly inject the proper cookie into their browser session and bypass the consent process. I believe the risk of this to be extremely low.
- These configurations are assuming that smart card is being enforced on the authentication NetScaler Gateway. It is possible to merge these configurations into a single Gateway Virtual Server if this is not the case.
- As always, test these configurations before rolling out into a production environment. Every environment is different so use good judgement when following these steps.
Creating the Responder Actions
To accomplish our goals, we will be creating three separate Responder Policy and Responder Action pairs to attach to our Gateway vServers. Navigate to AppExpert > Responder > Actions and create three Actions with configurations similar to the following (ignore the NOOP policy):
The Eula-Responder-Action is where you will configure your consent banner web code. You can either upload an HTML file or paste text into the NetScaler GUI. I recommend using text as this is easier to edit and will sync with any paired NetScaler in a High Availability pair. Here is some basic consent page HTML you can use to test (the important bits are in bold):
<!DOCTYPE html>
<script>
function acceptEula()
{ document.cookie=”acceptEula=True;domain=stg.home;path=/”;
location.reload(true); }
</script>
<html lang=”en”>
<head>
<meta http-equiv=”X-UA-Compatible” content=”IE=edge”>
<title>Consent Banner</title>
<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″/>
</head>
<body>
<p>You are accessing a controlled system.</p><p>By using this system you consent to the following conditions:</p>
<ul><li>Condition 1</li><li>Condition 2</li><li>Condition 3</li><li>Condition 4</li>
<p>
<button onClick=”acceptEula()”>Accept</button>
</body>
</html>
This simple page displays some placeholder text and then creates a button that calls our acceptEula() JavaScript function once the users clicks. The JavaScript code then sets the acceptEula cookie with my parent domain path (modify this for your environment) and forces a reload of the current page.
Create the Responder Policies
Now we can create our Responder Policies and link them to the appropriate Actions. Navigate to AppExpert > Responder > Policies and create three Policies with the following Expressions and Action links.
The Expressions check if the acceptEula cookie either exists or does not exist. Each Policy can take the appropriate Action based upon the result of the Expression.
Binding to NetScaler Gateway
Now that you have created and linked your Policies and Actions, you can bind them to your Gateway vServers. Navigate to NetScaler Gateway > Virtual Servers and bind as follows:
On your ICA Proxy Gateway bind the following Policies:
Note: The redirect Policy must be a lower priority then the EULA Policy to work. To work the ICA Only setting on this Gateway must be Disabled or the Responder Policies will not activate!
On your Authentication Gateway bind the following:
You can bind these by editing your Gateway server, scrolling down to Policies, and selecting the ‘+’ symbol to add a new Policy binding. Once there select Responder and Request and the type.
Then select Add Binding and add the appropriate Policies.
Summary
These configurations should give you a basis to enforce a consent banner for all users accessing a NetScaler Gateway system. Ensure that you test and validate these settings before modifying your production NetScaler Gateway servers. I would also highly recommend working with your internal web development team to make an appropriately branded consent page. Please feel free to use the comments below if you have any questions. For additional guidance, or a more customized solution, our Citrix Consulting team is always available.
Nick Czabaranek
Lead Architect US Public Sector Consulting
Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more TechBytes and subscribe.
Want specific TechBytes? Let us know! tech-content-feedback@citrix.com
