By Nathanael Coffing, CSO and co-founder of Cloudentity
A couple of weeks ago, a leading identity provider suffered a zero-day vulnerability that was immediately used maliciously to compromise financial, retail and healthcare customers.
The big question is— why was this "modern" IAM platform so appealing to security researchers and hackers alike, and how can we, as an industry, do a better job protecting our most sensitive assets; breaking apart the monolithic approach into developer-friendly mini and micro identity services?
The reason for the research is clear.
“It was a monstrous Java Enterprise application with a huge attack surface, so I decided to take a deeper look into it."
This creates a myriad of other questions that all center around two questions— why are we stuck with identity monoliths that paralyze the business, and how can the industry accelerate adoption of zero-trust authenticated and authorized service architectures?
Let’s start with a bit of history. IAM platforms have spent two decades evolving from internal WAM/SSO platforms into employee governance, and then again into external CIAM systems. Thus, the entire spectrum of customer IAM platforms (with a few notable exceptions) have been built upon internal-facing workforce IAM platforms that have the same data model, technology, and monolith, along with the addition of a couple new bells and whistles like OAuth and OIDC support layers transformed overnight into external facing CIAM platforms. But what the security researchers and hackers have rightly found, is the internals haven’t changed. These external-facing CIAM systems have been built right on top of archaic code from the early 2000's. Rolling out new protocol support and offering pseudo-scalability became far more important than securing and modernizing the platform's code base.
With that in mind, we’d like to address a few ways to identify whether your IAM platform is modern (cloud-native) or legacy (monolith).
- Look at the Data Model
- Data Model: If your platform requires LDAP or a structured data model, it’s not modern—the data structure isn't modern, the replication isn't modern, the scalability isn't modern and the protocol isn't modern.
- Data Persistence: If your platform uses LDAP or traditional SQL to store all its data, both ephemeral (sessions, tokens) and long-lived—the data layer is not modern, the ability to replicate and scale is limited and the data access protocol is outdated. Look for distributed SQL or NoSQL for long-lived data and distributed in-memory grids or in-memory key-value stores for ephemeral data.
- Data Structure: Flat, static and centralized data models don't support current business initiatives like B2B2C and B2B. Look for a solution that has the ability to take advantage of federated and distributed data. Does your IAM data live in one place? No, it's distributed and your IAM system should be too.
- Transient Data: If your platform treats transient objects like sessions or tokens as long-lived objects, it's not modern. Sessions and tokens are temporary and should be treated that way. Look for a solution that allows you to use short-term or transactional tokens (milliseconds or seconds, not minutes or hours).
- Consider Application
- Software Architecture: If your platform is built as a multi-tier, multi-layer application, it's not modern. Look for domain separation, lightweight containers, stateless and easy-to-autoscale services.
- Software Ecosystem: If your platform requires libraries deprecated a decade or two ago, it isn't modern. Look for a solution that only depends on open-source projects that are well-maintained and still current.
- DevOps Integration: If your platform requires complex integration with your monitoring and audit tooling, it's not modern. The modern software utilizes connectors that natively integrate into your DevOps infrastructure, utilizing protocols like Open Telemetry.
- Evaluate Scale
- Scale: If your platform's transactional bandwidth is measured in tens or hundreds of transactions per second, it's not modern. Customer and partner ecosystems require tens or hundreds of thousands of transactions per second, not the hundreds of transactions per second of employee platform.
- Session Length: If your platform measures token validity in minutes, hours or days, as opposed to seconds and milliseconds, it’s not modern.
- Separation of Function: When there’s a critical security functions like authentication and authorization, it’s mandatory to mitigate risks by separating out independent functions. OAuth and OIDC were designed as separate protocols, explicitly for this reason. Having separate services in the event of a zero-day of the authentication service limits the breach to the authentication service. The authorization service using simple policies can mitigate the lateral movement of compromised sessions.
Cloudentity is the first company to release an identity, authorization and consent platform built as and for independent mini and microservices. This is a massive step forward for modern cloud-native identity, allowing not just the orchestration between a company’s existing IdP’s, but also the externalization of identity, authorization and consent away from the services, functions, containers, Kubernetes pods and monoliths. Externalization adds rocket fuel to your business, allowing developers to build new business functionality 40% faster and leverage rich authorization to adopt new B2B2C or B2***2C business structures.
Join us in the move to modern (cloud-native) IAM and watch identity projects move from multi-year projections to multi-week success stories.