This blog post was co-authored by Roman Dario Lemes Gonzalez, Citrix Gateway Architect.

As modern full stack application developers, we have a lot to juggle, from satisfying business requirements to ensuring performance, responsiveness, scalability, extensibility, flexibility, usability, and supportability. And security is always somewhere on our list of delivery requirements! Security requirements are essential. But we’re working to combat unknowns, and we’re often operating areas that can be pretty vague.

Recently, we were struggling to settle on a list of security requirements for a custom web app for our Account Data Governance (ADG) initiative, an ongoing effort to standardize, administer and improve account data quality and integrity.

One of the critical ADG business requirements was to get rid of historical account duplicates accumulated over a long time. We couldn’t bulk delete them because of the volume and computational complexity. We decided to create a custom solution that involved a set of apps to compute deduplication criteria, survivorship logic, distribution mechanism, as well as an interface to enable business data stewards to evaluate and approve deduplication requests.

In this blog post, I want to share the security conundrum we encountered in building this UI and how our very own Citrix ADC came to the rescue!

Working Through Security Requirements

We started by looking at the delivery attributes of the web app, and we adopted some critical security considerations during the assessment:

  1. Whitelist/blacklist user responses and systems as applicable
  2. Ensure not to reflect user input directly on any of the app responses
  3. Always bind database parameters instead of appending values
  4. Use HTTPS for everything
  5. Hash passwords and require them to be longer and more complex
  6. Implement authentication, authorization, access control, and session management
  7. For items 4-6, use an existing authentication framework that is easily plugable for all security needs instead of creating a custom extension

We accomplished the first six items. But the challenge arose when we started working through the authentication framework requirement. The web app was built on an on-prem Apache SOLR platform in standalone mode and didn’t directly support third-party authentication extensions like LDAP API, or Okta. We couldn’t meet consideration #7 because of the app-level changes needed for integrating external security. We tried working around it by customizing the app and ran into challenges like:

  • Extensive application code-level changes
  • Introduction of new points of failure
  • Maintenance of newly added components, operations, and processes

That’s when we turned to Citrix ADC, which can take care of all these security integrations with no change or impact to the app itself.

Citrix ADC to the Rescue!

Citrix ADC helped us to achieve all our security attributes, including transport layer security (for HTTPS), recover, load balance, authentication, and authorization. Here’s how we met our security recommendations and made the web app compliant with Citrix security standards:

1) Enable end-to-end SSL (Transport Layer Security) for the app with Citrix ADC
TLS/SSL is designed to provide data transport security between the client browser and the server. In a simple SSL offloading scenario, the communication between the client and Citrix ADC is over a secure HTTPS connection. The communication from the ADC to the backend server is over a HTTP-based connection, where the data is passed on as plain text. But when the ADC and the back-end servers don’t reside in the same data center, there’s an increased risk of the clear text data being compromised if someone accesses the back-end network. So you need to encrypt the communication between ADC and the back-end servers, as well, to configure end-to-end SSL. Check out this Citrix article for more details.

2) Configure crash recovery with secondary server using the ADC load-balancing option

  1. Create a load-balancing virtual server (see LB in the image below)
  2. Update DNS services
  3. Bind load-balancing servers to services

Our requirement here is to provide active-passive disaster-recovery capabilities. The secondary server is required to serve traffic only when the primary server is unavailable. When traffic flows to recovery server, the application UI notifies end users about the change so they can inform the systems management team, which will prepare for recovery in terms of data index refresh validation and issue resolution. Users will continue to use the recovery server until the primary server’s issue is addressed. With Citrix ADC, there’s seamless transition between the primary and secondary systems for end users. For more information, check out this post on how load balancing works and this post on configuring a proxy server.

3) Enable SSO (Single Sign On) and AAA (Authentication Authorization and Auditing) on the application using ADC

Finally, we needed to integrate authentication and authorization with Citrix SSO through Citrix ADC. You can view product-level configuration steps and detailed information here. This does not need configuration or a code change at the application level.

E2E Authentication Flow

Here’s a peek at the application load screen:

Our web app with ADC integration has been in production for the last few months, and users are having a great experience with security and load balancing. Here are some of the benefits we achieved:

  1. An authentication framework that is so easy to integrate. Citrix ADC is not just our own product. It’s also encouraged as the standard authentication framework across all practices and applications within Citrix.
  2. The Citrix ADC handles all security attributes (security, authentication, authorization, load balancing, content switching, etc.), so no configuration or code-level changes are needed at the app level.
  3. High availability and infallible.
  4. Auditing is always available for app traffic, and we can conduct security forensics as needed.
  5. User access control and users groups are handled within the AAA feature.

We’re excited about this because, according to the ADC team, we pioneered integration of an existing custom web app with Citrix ADC to achieve all the security and authentication requirements. And just by plugging the app in the ADC framework!

If you’re trying to implement security for a custom application or a container that’s incompatible with any authentication API, try Citrix ADC. All you have to do is bring the application details to configure in ADC and, with a few clicks (and no impact to the target app), you’ll cover all your authentication factors. More information is available in the resources I’ve linked below.

Learn More