Complexity kills productivity. When it comes to enabling application access, enterprises should not have to choose between user experience and complex techniques that ensure application security. Traditionally, perimeter security is built on an assumption that whatever is inside the perimeter is trusted and users can access any corporate application through traditional authentication approaches. That's a big assumption that has become outdated based on the amount of recent attacks and data breach post mortems. The old model of perimeter security has lost its relevance. We are moving from a "trust, but verify" mantra to a "never trust, always verify" one.
Challenges in transforming your enterprise to a zero trust architecture
Most enterprises today operate hundreds of business-critical applications to support core business practices that were developed years ago with the assumption that anyone inside the perimeter will get single-sign-on access to any application or resource with legacy authentication schemes. The people who developed these applications couldn't foresee a rapid access paradigm shift with user diversification and therefore could not anticipate the requirements technology advancements would bring to market.
With more cloud adoption, the challenge of migrating apps to the cloud is a non-trivial effort. Many enterprises are struggling with how to leverage the cloud for both cloud-native applications and traditional on-prem applications. Today, users are more diverse: they access applications from home, coffee shops, airports or on the go. The growing user experience demands a new approach to security, one that can't be driven by corporate perimeters or even typical remote access (VPNs). We must consider any location valid for both users and resources, and we must work to preserve a uniform user experience regardless.
Users should be able to access any type of application, either hosted on-prem, in the cloud or as SaaS app seamlessly from a unified landing page without the need to remember multiple passwords and install clients on their devices. To address specific access needs, organizations must look beyond the traditional VPN approach to determine the best cloud fit for the application versus a one size fits all solution.
Single Sign On (SSO)
SSO addresses the challenge of applying security at the identity layer in a way that allows remote users (contractors, suppliers, vendors, partners and employees) to experience easy authentication to all authorized applications. Additionally, this allows CISOs and other security leaders to apply comprehensive security policies covering the entire IT system.
- Strengthens authentication and allows for traceability to all controlled applications.
- Enables users in accessing their applications using one set of credentials.
- Allows users to authenticate to all applications they have been sanctioned access to and eliminates additional authentication prompts when many different applications have been accessed during the same session.
- Often results in reducing the authentication-associated support tickets and increasing user and administrator's productivity.
Authentication or Identity Management, while the core component of a zero trust architecture, is tightly coupled with access. In my experience talking to customers, many wish to transform the traditional access model, but are reluctant to change applications specially developed many years ago. I see a pattern in conversations where more of these Identity and Access management solutions ask customers to modify their enterprise apps to talk SAML (Security Assertion Markup Language) or OIDC (OpenID Connect) and make them available to Internet through DMZ, so they can enable SSO. From an IDaaS vendor's lens, they can easily integrate their modern identity in the cloud solutions with the application, but from customer's perspective, the fear is more around the supportability for their legacy applications still running on old authentications schemes like NTLM, Kerberos or basic challenge. Here are two choices:
- For an IDaaS solution, host the applications in the DMZ to make it reachable from IDaaS in the cloud. Without a reverse proxy, there is no easy way to reach the application hosted behind the firewall for SAML transactions. This makes their internal applications vulnerable to different type of threats.
- For on-premise SAML Identity Providers (for example, ADFS), either host the Identity provider in the DMZ for users accessing the SAML enabled applications over Internet or provide VPN connectivity between users and on-prem IdP, hosted behind the firewall which takes them back to square one, ie. complex configuration and massive investments in maintaining multiple DMZ environments especially for applications hosted in multiple locations.
Even with the above two choices, they still need to maintain a separate infrastructure for legacy applications which cannot be SAML-enabled and still need SSO using NTLM/Kerberos or other methods of authentication. Customers want a unified SSO experience for their end users without making it complex for application owners or IT administrators.
Akamai Enterprise Application Access (EAA)
EAA is a simple way to secure and deliver your applications that are either hosted behind the firewall or as a SaaS application with SSO experience to end users. It is a secure remote access service that lets you protect your applications from Internet threats while giving control and governance of access from your contractors, partners, vendors and employees. End users can use EAA as a launchpad to access any SaaS applications (Salesforce, Microsoft Office 365, Workday, DropBox, ServiceNow or Google Suite etc.), enterprise applications and assets hosted in the data center or in public cloud - all through a unified portal.
EAA Authentication Bridge
EAA Identity service provides an authentication bridge that doesn't require any modification to existing applications as long as the applications can authenticate and authorize using SAML, OAuth, Windows integrated authentication methods (NTLM/Kerberos), custom X-forwarded-for headers or basic header-based authentication. Through a unified launchpad, users can get access to any application using EAA enabled with different type of authentication schemes. The EAA authentication bridge has the capability to convert SAML token received from SAML IdPs into an application-supported authentication scheme for example; Kerberos or custom HTTP headers. This enables customers to plan application migration to Cloud without modifying their applications or making them available to the Internet. In short, no "Rip-n-Replace".
EAA can help providing single sign-on access to:
- Any SaaS application hosted with a SaaS provider
- Enterprise applications using SAML 2.0 protocol
- Enterprise applications including (Windows application) using Integrated Windows authentication (NTLM or Kerberos)
- Enterprise applications using custom HTTP headers like X-forwarded-for users, remote-user or groups) for authentication and authorization.
EAA Authentication Bridge for Non-SAML enabled applications
HTTP headers offer great flexibility for passing critical information to the enterprise applications. Based on HTTP headers, customers can make their enterprise applications Single Sign on (SSO) capable through EAA, even if the applications cannot be enabled with the SAML protocol. Applications like Atlassian, Oracle, SAP or any legacy application can authenticate end-users based on the information received in an http header and attributes (for example, Client IP, remote user or X-forwarded-for groups).
So, the next time you plan to roll out a new web application, think about how Akamai can help you transform your enterprise strategy into a zero trust model for all type of users - without compromising the security posture or modifying your applications. Please visit Akamai.com/EAA for more information.