Intercept SaaS Services with the Akamai EAA Client

by Jano van Deventer on June 25, 2019

I was quite fortunate to visit Tokyo for the first time last year, and it was an unforgettable experience to explore all the sights and sounds around the Ginza district and to interact with the very friendly Japanese people. It wasn’t all play, though — and I had to get some real work done as well.

Securing SaaS Services

A requirement that arose from a customer meeting was to deliver a solution to replace Microsoft DirectAccess since the customer was migrating to Windows 10. This is a common theme, with many enterprise customers looking for new security technologies to deliver internal applications to remote employees and third parties. Interest in Zero Trust solutions is quickly ramping up as other large organisations, including Akamai, have already started the Zero Trust journey. For more background on the trend to replace VPNs, please refer to this article.

The Ask

The customer had a specific interest to forward a defined SaaS provider’s traffic through the on-premise forward proxy, as depicted in the diagram below. The reason behind this flow is twofold; from a SaaS vendor’s perspective, with a customer location defined, it is not too difficult to implement a DOS policy to protect the SaaS service. From a customer’s point of view, the IT staff may want to restrict access to a SaaS service based on a specific defined location, rather than allowing access from anywhere. The DOS policy is deployed on the SaaS provider’s side, based on source IP address. With traffic transiting from the on-premise proxy with a determined NATed IP address, it’s a simple exercise to enforce this policy.

Akamai Identity-Aware Proxy (IAP)

The Enterprise Application Access (EAA) solution delivers secure access to internal web servers, remote desktop servers, and SSH servers for corporate users and third-party access. The EAA solution is built on a dual reverse proxy architecture. The first cloud proxy is responsible for handling the pre-authentication of all user access. The second on-prem proxy assists with authentication brokering to Active Directory, and provides other application delivery controller services such as health checks, load balancing, and single sign-on. An inherent benefit of Akamai’s approach with the IAP is the capability for service insertion between the user and the application server; in other words, the vast Akamai Intelligent Edge Platform of over 250,000 nodes can be leveraged to provide not only improved performance but also application security.

… let’s pause to talk about the network …

Traditional access technologies such as IPsec and SSL VPNs provide direct access to the data center network — DirectAccess falls in this bucket, as it leverages IPsec. Why should you care about this? Well, the hackers and malware coders are very familiar with your environment, and as part of their reconnaissance they will do a ping sweep to find the private server IP addresses. Malware will exploit this, and it’s not uncommon to see infection taking place laterally between servers. The second network consideration is the perimeter firewall. As indicated by the inbound arrow in Figure 1, you will have to expose an open TCP port to the Internet. The drawback of this situation is that you potentially have to deal with a lot of unauthorised network-level traffic flooding into the perimeter firewall. Wouldn’t it be nice if you could close the tap a little bit?

In the next figure, I briefly introduce the EAA architecture — but on this topic of the perimeter firewall, I will point out that EAA doesn’t require any inbound TCP port to be opened. Thank you, Akamai, for stopping the floods!

The EAA Client to the Rescue!

The Akamai EAA Client is a thin client that complements Akamai’s Zero Trust solution to offer support for all applications, especially thick clients that use non-web-based ports and protocols that are running in the data center. Some examples include Outlook, SAP Gui, SQL Clients, and the AWS Command Line Interface. Specific to the customer requirement for forwarding SaaS traffic to an explicit forward proxy, the EAA Client has a very nice feature that offers the capability to intercept destination traffic based on DNS name. Let’s see how this works. Say, for example, the browser tries to get to the destination URL drive.google.com — rather than resolving the DNS to Google’s IP address, the EAA Client will intercept the DNS request for drive.google.com and resolve it to a reserved address. This allows the EAA Client to then intercept all traffic destined for drive.google.com.

You may wonder what happens next with the traffic after the EAA Client has done its work of hijacking the traffic. It’s rather quite neat. Akamai has decided to leverage WebSockets to create a full-duplex communication channel (as defined by Wikipedia) so the application request can securely flow to its destination. A little later in this article, I introduce a high-level call flow diagram with a bit more detail.

Testing with G Suite

To test the concept, I decided to do some quick testing with Google G Suite. Let’s see what the configuring on EAA looks like. Rather than configuring all the individual G Suite components such as drive.google.com, mail.google.com, accounts.google.com, etc., it is possible to use a wildcard configuration such as *.google.com, which greatly simplifies the configuration and reduces the deployment time.

The user will authenticate through the EAA Client against the configured Identity Provider (IdP). Once the EAA Client is authenticated, it will start to intercept the DNS requests for the specific configured wildcard host; in my example, this is *.google.com and is indicated by step ① in Figure 4. Next, the GET request is sent, and as the destination is a reserved IP address that the EAA Client is listening on, it will receive the request in step ②, which is forwarded through the Akamai platform in step ③ to the EAA Connector, which will forward it to the Forward Proxy in step ④. The Forward Proxy then retrieves the content, which is delivered to the browser as shown in steps ⑤ to ⑩.

In Summary

With the new Akamai EAA Client, more secure access use cases can now be supported — for example, the SaaS problem being solved above. Some of the benefits associated with the EAA solution include:

Greatly improved security posture by enabling a Zero Trust architecture. You can finally use your firewall for what it’s intended — to keep unauthorised traffic out of the data center by first allowing legitimate users to authenticate through the Akamai EAA cloud.
As a cloud service, the ease of deployment of EAA is unsurpassed, and new applications can be provisioned within minutes.
Ease of management. No more downtime. No more midnight-hour maintenance windows to upgrade appliances. Although the EAA Connector is a required component in the data center, this virtual machine is headless and doesn’t require any active maintenance.

When I first heard about this SaaS service intercept use case, my initial thought was that it is probably a one-off customer requirement. I was pleasantly surprised to learn from my colleague that a customer in China has the same requirement. If you are interested to run a quick test of EAA, you can head over to the Akamai Free Trials page and kick off a 30-day trial.