How to secure non-standard apps with MFA or passwordless (without rewrites)

In today’s rapidly evolving business environment, enterprise applications are crucial for driving innovation and productivity.  They are the lifeblood of the modern organization and are relied upon for every business purpose, in every department, for almost everything.

Because they house the crown jewels of data in the form of personally identifiable information (PII), applications are prime targets for cybercriminals as a means to get into and compromise a company’s infrastructure. Therefore, securing apps is the top priority for organizations.

However, application security is not always straightforward, especially for legacy or non-standard-based applications that were built before modern authentication tools were created. 

What are standard-based apps and non-standard-based apps?

From an identity standpoint, applications are broadly categorized into two types: standard-based (also called federated) and non-standard-based (sometimes called non-federated) apps. Making non-standard apps secure is not as simple as buying the latest MFA or passwordless authentication technology and putting it in front of the app. An app that wasn’t written with standards has traditionally needed to have its code rewritten so that it can understand the language of modern authentication technology. Rewriting an app can take an average of three to six months and cost an average of $150K.

Gartner® refers to standard and non-standard application enablement, which includes capabilities to enable access, authentication, and SSO to both modern apps and legacy applications that do not support modern identity protocols, using technologies like proxy services, agents, or other mechanisms. Securing these legacy apps is very different from modern cloud apps.

Before explaining the difference between standards-based and non-standards-based apps, it’s important to define identity standards. 

What is an identity standard? 

According to the Identity Management Institute, identity standards are technical specifications designed to integrate user identities across multiple platforms. They provide a structured approach to handling user identities and managing access rights within an application, enhancing the app’s security and interoperability.

Here’s an analogy: think about standards in the context of electrical outlets and plugs. Imagine you’re traveling the world with your laptop, phone, and a variety of other gadgets. In every new country you visit, you find that the electrical outlets are different, and none of your devices’ plugs fit. You would need to buy a new charger for each device in every country. 

Standards are rules; they help with compliance and ensure consistency. With identity, standards like SAML or OIDC are like universal plugs and outlets that allow different software applications to connect and interact with each other, regardless of where they were developed or what specific technologies they use.

Standard-based apps: seamless and secure authentication

Standard-based applications are designed using these identity standards. Commonly today, you can find apps using SAML (Security Assertion Markup Language) or OIDC (OpenID Connect). 

Common open identity industry standards used by enterprises  

The following list of open identity standards includes the most commonly used standards apps are built upon today. It is not inclusive of all standards but focuses on those that are most relevant for an IAM best practices discussion. Note that LDAP and SAML are over 20 years old; however, they are still commonplace in enterprise applications. 

LDAP (Lightweight Directory Access Protocol): LDAP is a protocol enabling apps to quickly query user information and helps to eliminate the need for IT intervention. It’s like a telephone directory for networked data. Just like flipping through a directory to find someone’s number, LDAP-aware apps can query an LDAP server to find and fetch desired data. It’s a key player in areas like single sign-on and compliance regulation adherence.

SAML (Security Assertion Markup Language): SAML is an open standard that makes SSO possible. The purpose of SAML is to enable security information about identity, authentication, and authorization to be shared across different systems. Think of SAML as the digital bouncer at the entrance of your favorite club, checking IDs (but here, digital signatures). It facilitates secure exchanges of authentication data between parties, primarily for web browser single sign-on. SAML promotes easy interoperability among diverse systems.

OAuth: OAuth is an open-standard authorization protocol that came after SAML to improve SSO. Like a valet key for your car, it grants limited access to your vehicle. In the digital world, OAuth 2.0 allows third-party clients to access protected resources using access tokens approved by the resource owner. Depending on the situation, one or more grant types can be applied. OAuth 2 and OpenID Connect are now the favored mechanisms for user consent enforcement in fields like Open Banking.

OIDC (OpenID Connect): OpenID Connect (OIDC) is a layer that enhances the OAuth 2.0 identity framework. It enables third-party applications to validate the identity of the user and access their essential profile data.

This OAuth article from Okta sheds more light on these standards, which provide a uniform approach to identity management, simplifying data security and user authentication. 

For example, cloud-based apps and services like Google and Salesforce are typically built on these standards to offer a more effortless, secure user experience and reduce the likelihood of security breaches.

Non-standard-based apps: an unreliable relic from the past

In contrast to standards-based apps, non-standards-based apps are typically older applications that weren’t developed with identity standards. They rely solely on usernames and passwords for authentication, making them less secure and more susceptible to breaches.

These applications might include older versions of business software that haven’t been updated to meet current security standards.

Note: while the terms “non-standard-based apps” and “legacy apps” are sometimes used interchangeably, they are not always synonymous. Not all legacy apps lack identity protocols, and not all non-standard-based apps are necessarily old or outdated.

The challenges with non-standard-based apps

The reality for app owners is this: non-standards-based apps pose significant challenges for implementing advanced security measures like passwordless authentication or phishing-resistant multi-factor authentication (MFA). This is because they lack the necessary framework and functionality to support these features.

Forms-based and header-based apps

When it comes to authentication, most non-standard-based apps are either forms-based or header-based. They were commonly used before the arrival of more modern and secure protocols like SAML or OIDC and are often found in legacy applications that have not been updated or modernized.

Forms based applications
With forms-based applications, a user is typically presented with a form in which they must enter their username and password. The form data is then sent to the server, usually via an HTTP POST method. The server checks this data against stored user credentials, and if the entered credentials match the stored ones, the server provides access to the protected resources. 

Header-based applications
With header-based applications, user attribute data are sent in the headers, and the user request is authenticated to an intermediary identity provider or service. The app trusts the intermediary solution, authenticates the user propagates the required Hypertext Transfer Protocol (HTTP) headers to the destination web service.

Both methods are less secure and robust than modern authentication methods like SAML or OIDC.

Remember: standards are constantly evolving. Just when you’ve updated all your apps, standards change, and you have to update them all again. 

Repercussions of using non-standard-based apps

As a result, companies must find a way to manage these non-standards-based applications, and the solution is not optimal. Often, the approach involves extensive rewriting and modernization of the application code to integrate identity standards. 

This is a complex, time-consuming process. So businesses resist modernizing or recoding certain software due to the high costs and risks involved, especially in cases where such changes could disrupt key business functions.

Here’s an example: let’s say an organization needs to migrate an older application running on CA SiteMinder or Oracle Access Manager (OAM) to Azure Active Directory or AWS. To secure these with passwordless authentication by a HYPR or Yubico type of solution, the application would need to be fundamentally altered and adapted. This process could potentially disrupt the service and require substantial resources and expertise.

In another example, a large consumer products company was leveraging an older web application used in toothpaste manufacturing. Changing even a single line of code could disable a crucial operation.

The modernization process typically does not offer direct business benefits. Although it could result in more secure and efficient software, the immediate costs and operational risks often outweigh these potential long-term advantages. In the case of larger organizations with numerous applications, rewriting or modernizing all of them would be impractical.

The future of enterprise apps — the last mile enforcement point 

Despite the complexities involved, companies recognize the importance of securing their applications with robust identity standards. According to a study by the Identity Defined Security Alliance, a whopping 84% of organizations have experienced an identity-related security breach, underscoring the necessity of implementing strong identity standards as a preventive measure. 

Whether it involves modernizing legacy systems or adopting new, standards-based applications, businesses are increasingly prioritizing digital security.  As cyber threats become more sophisticated, the move towards standards-based applications is not only recommended but necessary.

Often, many companies face mandates or requirements for more robust security measures. They need a solution that acts as the Policy Enforcement Point (PEP), ensuring the implementation of these policies. These solutions can also function as a Policy Decision Point (PDP), or it can communicate with external PDPs to determine the necessary authentication/authorization steps.

Using Identity Orchestration to secure all applications

The “last mile enforcement point” is the point at which access decisions are enforced, right at the door of the protected application. This is crucial for several reasons:

Close to the Application: By positioning a solution like Strata’s Maverics as the last point of contact before the application, it ensures that there is a security check as close as possible to the application. This is particularly important for legacy or non-standard applications that might not support more modern authentication protocols. Orchestrators can handle the authentication process regardless of what the application natively supports.

Consistent Policy Enforcement: Maverics orchestrators can enforce a consistent policy across all applications, including standard and non-standard ones. This means that regardless of how an application is built or what protocols it supports, an orchestrator can enforce a consistent set of rules for who gets access and when.

Flexible Policy Decision Point: As was mentioned in the previous conversation, the orchestrators can either make decisions about access itself or defer to another system to make that decision. This flexibility allows the orchestrators to fit into a variety of different architectures and use cases.

Authentication and Authorization: The Orchestrator enforces both authentication (verifying who a user is) and authorization (deciding what that user is allowed to do).  This dual role means it can handle complex access decisions, providing a consistent experience across all applications.

Maverics — the last line of defense for an application

Ultimately, the Maverics Identity Orchestrator acts as the “last line of defense” for an application, ensuring that only authenticated and authorized users are given access. Its location and role as the last mile enforcement point provide an additional layer of security, especially for those legacy applications that may not support modern authentication and authorization protocols.

Wondering about the potential return on investment when modernizing and migrating your identity management systems? Read the Forrester Total Economic Impact study to discover the financial impact of your potential identity modernization initiatives.

____________________________

*Gartner, Magic Quadrant™ for Access Management,  Henrique Teixeira, Abhyuday Data, Michael Kelley, James Hoover, Brian Guthrie, Published 1 November 2022

GARTNER and MAGIC QUADRANT are registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.