It’s no secret that many home-grown applications, particularly within public sector environments, have suffered from a lack of robust authentication systems over the last two decades. As a result, organizations are now facing a substantial technical debt related to these applications. Rebuilding the security stack or even just the authentication stack of these applications can require significant capital investment. Fortunately, there are alternative methods to secure these web-based applications that provide the insights security teams need while still delivering an excellent user experience.
Zscaler Private Access (ZPA) is a game-changing solution that provides zero-trust access to web applications, without requiring the rebuilding of the application stack. Browser-based access is just one of the many components of ZPA, and in this post, we will walk you through a demonstration of how this powerful solution can help you secure the front-end of a legacy web application, in just a few clicks.
To illustrate the power of ZPA’s browser-based access model, we’ll be using a simple Python Flask app. You can download the app from here. Although this application is much simpler than the systems we’ll be discussing, it provides a clear example of the insecurities that can arise with a basic form-based application. By utilizing ZPA’s powerful security features, we’ll demonstrate how this app can be protected by a secure, robust system that eliminates common attack vectors.
As the application exists today, it uses a basic form-based authentication mechanism served as a web page on port TCP/80. To show that authentication is successful, the user is redirected to a page indicating that they’ve been successfully logged into the system.
For the purposes of this demonstration, the application is accessed at http://py-dev.tng-lab.org. Before we begin, it’s assumed that you have a basic knowledge of ZPA, a configured IdP (Identity Provider) and have already deployed a ZPA App Connector in your environment.
To configure ZPA for this application, we’ll start by creating a Server and a Server Group in the ZPA Admin Console. Note that while the Server can be configured without an associated Server Group in the admin console, the reverse is not true, so it’s important to start with the creation of the Server as shown below:
To configure ZPA for this web-based application, we need to create a Server Group that has Dynamic Server Discovery (DSD) disabled. This is important because we want to statically define the servers rather than let the system automatically discover application servers.
To create this Server Group, follow these steps:
Once this work has been completed we can move on to the creation of the ZPA Application Segment. This is where the configuration will be placed that provides the secure front-end to the web application. To create the Application Segment follow the steps below:
