In the early days of the cloud, authenticating people and apps was a lot simpler.

Apps could be authenticated using a fairly static catalog of software-as-a-service and on-premises solutions, using single sign-on or SSO tools from the likes of Ping Identity Holding Corp., Okta Inc. and Cisco Systems Inc.’s Duo. But the growth of the supercloud — the notion of a cloud architecture that enables applications to run on an abstraction layer across cloud providers — brought trouble.

Stretched thin

SSO tools were stretched thin because the number of cloud-based apps grew by leaps and bounds, with microservices and containers making things more complex. That forced corporate SSO administrators to expand their reach and keep track of these new app repositories. Some of the tools lacked a sufficient degree of granularity to handle these new kinds of cloud collections, for example.

The situation is made worse yet by sloppy access controls, which were a perennial problem for information technology departments even before clouds were invented. Proofpoint Inc.’s annual Human Factor report, based on its customers’ telemetry from 2022, says that “around 10% of endpoints have an unprotected privileged account password, with 26% of those exposed accounts being domain administrators.” Those percentages can only increase as clouds become more complex and pervasive.

Even when accounts aren’t exposed, there are issues. One part of the problem is that authentication decisions have changed from an initial pass/fail moment to a more continuous checking, motivated by targeted phishing and other attacks that could make use of stolen credentials to gain access.

Even accounts that are protected by multifactor authentication, or MFA, are no longer safe: Proofpoint’s report, and others, document the rise of MFA bypass attempts as part of the reverse proxies contained in ready-made phishing kits from EvilProxy and Evilginx2 and NakedPages. These tools, offered as malware-as-a-service on the dark web, the shady corner of the internet reachable with special software, have become more popular as more users implement MFA. Clearly, the crooks aren’t sitting still.

As the number of identity records mushroomed, the need for better automated tools to manage all of the various authentication processes became both more compelling and more of a challenge.

In many cases, identity providers poorly handled provisioning and deprovisioning tasks, requiring complex manual methods. This is not a new issue: Writing in OneLogin Inc.’s blog four years ago, Tony Smith said that “provisioning and deprovisioning user accounts is the bane of any IT organization’s existence. It always needs to be done immediately, but it’s monotonous, time-consuming, and fraught with opportunities for human error.” That’s where automation can help eliminate these errors, and also make authentication more pervasive across cloud collections.

Identity tool overload

There’s yet another series of wrinkles in identity management: Not just one but several categories of identity tools are required. Some analysts differentiate between consumer identities, or systems that protect users and customers, and workforce identities, or systems that protect just about everything else. The two have different constraints, goals, scaling and design requirements, and user experiences.

Then there are products called privileged access managers, where access policies are created and enforced to limit who can access a particular application or network resource.

On top of these tools, there is the growing trend toward supporting passwordless authentication and passkeys, both from the perspective of authenticating users and applications. This means figuring out attestation workflows and who will broker the various authentication mechanisms, something that the Fast Identity Online Alliance, FIDO for short, has been busy working on.

Added to these authentication challenges is the rise of digital twins and use of more automated techniques such as machine learning and AI to build new applications that ingest massive amounts of data. Getting everything integrated with SSO and other identity tools and working with tracking real-time data feeds of people, places, things and apps adds an additional management burden.

For example, app vendors can make small changes to their login screens, or new containers will be spun up that need the correct access rights, or a developer has inadvertently left a backdoor in some virtual machine — which will be found by a malicious actor who then leverages their way into the enterprise. All of these can easily break SSO automation routines.

The way forward

The traditional SSO vendors – along with the major cloud platforms — aren’t standing still. They’ve been busy expanding their efforts to be more inclusive and more automated, and to cover multiple clouds and more homegrown apps that are developed in-house. Fortunately there are providers such as Itential Inc.’s Automation Platform, Britive.com and IamCloud.com, which have cross-cloud solutions designed from the beginning to handle identity issues mixing situations involving machines, people and apps equally well.

To provide more resiliency, the supercloud has to incorporate authentication automation directly into the software development pipelines and workflows. For example, Okta has its Customer Identity Cloud product that ties into Jenkins and Argo development pipelines, and many of its customers also use another product called Advanced Server Access to authenticate compute workloads, according to Sagnik Nandy, president and chief development officer of the company’s workforce cloud division.

That means companies have to do a better job of testing these authentication mechanisms. However, testing authentication infrastructure has always been a poor stepchild, even when the SSO universe was a lot simpler place. This blog post from Tricentis Testim, a general software testing provider, outlines some of the issues — and even though it was written more than two years ago, it’s still relevant.

The problem is that testing authentication automation hasn’t kept up with these new use cases, and in many cases the testing environments offered by the SSO vendors are inadequate, incomplete and exceeding finicky to use. On top of those drawbacks, the identity-oriented testing tools aren’t well-integrated into the overall software testing workflows, nor are they well-understood by non-identity app developers.

The upshot: The issues stemming from poorly provisioned containers, inconsistent access rights and over-privileged users will remain for the near future — all the more so as clouds become more pervasive and more complex.

Image: Pixabay