Who’d Have Thunk It? Using Enterprise Application Access for DevOps!

by Damian Danchenko

Continuous integration and delivery (CI/CD) of application code and configurations is at the heart of DevOps. This basically means a rapid cycle where code and configuration changes are developed, tested and released on the order of days (or hours), rather than weeks or months.

In order for this to work though, an organization must have complete development, staging, and production environments that operate independently of each other. At the same time, there needs to be established processes to allow development to move easily between each of the environments. For regression tests and stress simulation, tests must be performed on the whole application, not just parts of it. This extensive testing of a distributed system is hard to do outside of the production environment.

Enterprise Application Access and DevOps

Enterprise Application Access (EAA) is primarily used by organizations to give remote users access to internal applications and websites. Rather than providing network access to these remote users via a VPN tunnel, EAA restricts access at the application level. See the following image and and explanation for how this works:

  1. Remote users connect to the EAA Edge server. Only authenticated users have access.
  2. Meanwhile, the EAA Connector establishes a connection to the internal application or website.
  3. At the same time, the Connector also establishes an outgoing 443 connection with the EAA Edge server. That connection gets “stitched” together with the connection from the remote user, forming the complete, seamless connection.

Because there’s no need to change firewall settings to provide access, EAA Connectors can make outbound 443 (HTTPS) connections to the EAA Edge servers, shifting access control away from the company’s enterprise environment.

Now here’s where it gets interesting for DevOps. With EAA, organizations can have development websites secured behind a firewall, and can still be used as an origin for development CDN configurations. So now, we have a completely separate, fully-integrated development environment, whereby users can test development websites, alongside their respective development CDN configurations.

With the ability to integrate Active Directory, SAML and/or other third-party Single Sign-On (SSO) options through EAA, access to the development website can be tightly controlled and monitored.

Example EAA DevOps Workflow

Below is a sample workflow, with Akamai Ion as the CDN.

  1. Set up a development application (website, etc) in an internal-only environment. No DMZ setup required, so the development environment is secured.
  2. Set up a development Ion configuration that mimics a production configuration, but goes forward to the internal development environment via EAA.
  3. Develop application code alongside an Ion development configuration, completely separate from production.
  4. Stress test and validate the complete development website with the Ion development configuration in front of the development website.
  5. Release application code to production, while at the same time replicating Ion development config changes on the production config.

With this approach, development CDN configurations can be tested against a development website, rather than a production website. And no need to put a development website in a DMZ, just to be accessible by the CDN.

Customer Use Case

One customer of ours has already been utilizing Ion Premier to accelerate their primary company website. As with most organizations, they have an internal development environment for testing code before eventually moving to their production environment.

One piece lacking though is the ability to integrate a pure development Ion environment with their development website application. Akamai properties need to able to reach a publicly-facing website as origin, so having Akamai reach forward to an intranet site, behind a firewall, naturally wouldn’t work.

That is, until, the customer requested an EAA Proof of Concept. The goal for the customer was to be able to develop on their development environment, and have a development Ion property that mimics their production property.

Solution Details

The data flow can be described as the following:

  • dev.company.com is the internal development environment that they access when within their network. This ends up being the origin for EAA.
  • dev-www-company-com.go.akamai-access.com is the publicly-accessible access point for EAA, the EAA Edge server. Without Ion, external users could use that hostname to access the internal website through EAA. With Ion though, dev-www-company-com.go.akamai-access.com ends up being the origin for Ion.
  • Finally, dev-www.company.com ultimately resolves to dev-www.company.com.edgekey.net, which then points to the EAA Edge server.
    The diagram below illustrates the setup:

  1. User browses to dev-www.company.com, which is mapped to a dev instance of the Akamai Ion CDN.
  2. Ion goes forward to the EAA Edge server as origin.
  3. Meanwhile, the EAA Connector establishes a connection the the internal website, dev.company.com.
  4. At the same time, the Connector also establishes an outgoing 443 connection with the EAA Edge server. That connection gets “stitched” together with the connection from Ion, forming the seamless connection.

The company is using the Active Directory (AD) feature in EAA to assign access to the development site. Active Directory users from within the company are synced to the EAA Management Portal. EAA only syncs and maintains the list of users to be authenticated, not the actual credentials. Authentication is brokered by AD in the company’s environment directly.


Enterprise Application Access can be used as an integral part of any DevOps workflow, connecting the dots between Akamai development configurations and development applications behind a firewall. Complete development, production, and even staging environments can be realized, without having to compromise security or workflows.

Using EAA, website developers can see how application code changes behave with new Ion configurations, without needing to deploy to production first. And application access can be tightly controlled, managed and monitored by the organization.

We’re excited to see how other organizations utilize EAA to close the gap of their DevOps workflows. And while EAA isn’t free, it also isn’t very expensive. Talk to your Akamai representative about seats and pricing, we think you’ll be pleasantly surprised.

Categories: DevOps Articles, Technology

Suggested Article