I’ve recently started to explore the world that is non-human identity. Coming out of IETF 119, where some of the best (and most terrifying) hallway conversations were about physical and software supply chains, I realized this was a space that didn’t look like what I’d experienced early in my digital identity career.
When I was first responsible for the group managing digital identity for a university, our issues with non-human identity centered around access cards. These were provisioned in the same system that provisioned employee badges: the HR system. Having entities that were not people in a people-driven system always involved annoying policy contortions. It was fitting a square peg in a round hole.
That kind of non-human identity has nothing to do with what I learned at IETF 119. Personally, I blame cloud computing.
Cloud Computing
Depending on the person you’re talking to, cloud computing is often seen as the answer to a company’s computing cost and efficiency problems. Rather than paying for a data center, equipment, network capacity, and all the staff that goes with it, the company can buy only the computing power it needs, and the rest magically disappears. IT staff tend to look at cloud computing another way: the same headaches, just more complicated to manage because they are on someone else’s computers.
However, cost and some dimensions of efficiency are the driving force behind business costs, and cloud computing has become even more attractive. Companies regularly purchase cloud computing services from a variety of vendors. A cloud here via Microsoft for Azure, a cloud there at Amazon Web Services for database computing, and another cloud there at Google for storage. It looks fantastic on paper (or at least on a monitor), but it’s introduced big identity problems as a result.
Authorization in the Cloud
Processes and APIs are not people. They don’t get hired and fired over the course of years like people do. They may never be associated with a person at all. And yet, they usually have a start and an end. They need to be constrained to access or accomplish only the specific things they are supposed to do. They may delegate specific tasks to other processes. They need authorization and access control at a speed and scale that makes human authorization look like a walk in the park.
If all authorizations happen in one environment, it’s not too bad. Everything gets their data from the same sources and in the format they expect. It might be like those old key cards managed via a people system, even when they aren’t themselves people, but it is a simple enough model.
Authorization in Many Clouds
However, if the authorization has to happen across environments, things get hairy. The format of the code may change. The source of truth may vary depending on where the process started. There may be hundreds, thousands, millions more of these processes and APIs than there are people in the company. And these processes are almost entirely independent of any human involvement.
This new kind of non-human identity operates in ways human identities don’t. Batch processing is a great example since the process does not necessarily act on behalf of a user. Training an AI model is batch processing that runs for a week and has no human involved. Batch transactions in the bank, such as payroll, run unsupervised and aren’t handled as a person. Furthermore, a human may be flagged by a computer’s security system as showing strange behavior when they are logging in from both Brisbane and Chicago simultaneously. An application, in all its glory, may suddenly expand to be in data centers around the world because it’s dealing with a Taylor Swift concert sale. What would be anomalous for a person is just another day in cloud computing.
Sorry, HR badge system, you’re just not suited for managing authorization here.
I want to help you go from overwhelmed at the rapid pace of change in identity-related standards to prepared to strategically invest in the critical standards for your business. Follow me on LinkedIn or reach out to discuss my Digital Identity Standards Development Services.
DevOps, IT Admins, and IAM Practitioners
Developing and deploying code in a cloud environment is generally in the hands of the DevOps and IT teams. DevOps traditionally move quickly to develop and manage the applications a company needs to deliver its products or services. IT teams deal with the applications that have been developed and deployed. The staff in these groups often specialize in one cloud computing environment or another; it’s not easy to be a generalist in this space.
DevOps is often the fastest in terms of getting new code in place, and the IT admin tries to deal with the symptoms of what’s been developed and deployed. Neither group tends to think in terms of identity management; most IAM teams are focused on people. This is a problem.
Identity administrators are beginning to understand there is an authorization problem, but solutions are sparse. DevOps teams also realize they have an identity problem (ask your favorite DevOps person how much fun it is to manage API permissions without leaking a password or private key). But the DevOps team is not going to the IAM people and say, “Create all these millions of identities and manage them for us, kthxbai.” For one thing, it wouldn’t occur to them. For another, the IAM staff would have a nervous breakdown.
Standards to the Rescue!
And here’s where the hallway conversations at IETF 119 enter the story. The whole reason I learned about the authorization-in-the-cloud problem was because of discussions around two working groups and an almost-working group:
- Supply Chain Integrity, Transparency, and Trust (scitt)
- Workload Identity in Multi System Environments (wimse)
- Secure Patterns for Internet CrEdentials (spice)
SCITT
The big picture here is the software supply chain. A software supply chain is the collection of components, libraries, tools, and processes used to develop, build, and publish software. Software is very rarely one monolithic thing. Instead, it’s made up of lots of different components. Some may be open-source libraries, and some may be proprietary to the company selling them.
Just like a physical bill of materials is required when importing or exporting physical goods, there is also a software bill of materials (SBOM) that is supposed to list all the components of a software package. Now, wouldn’t it be fantastic if, based on a computer-readable, standardized format of an SBOM, a computer could decide in real-time whether a particular software package was safe to run based on a quick check for any severe security vulnerabilities associated with any of the components listed in the SBOM?
It’s an entirely different way of looking at authorization, and that’s what scitt is working on.
WIMSE
Workload identity is a term that’s still struggling to find a common, industry-wide definition (not an unusual problem in the IAM space). I do like Microsoft’s definition, though: “an identity you assign to a software workload (such as an application, service, script, or container) to authenticate and access other services and resources.”
I mentioned earlier that there can be a ridiculous number of applications and services running across multiple cloud environments. DevOps gets to develop and deploy those, but IT admins need to keep track of all the signals from all the services to make sure everything is running as expected and uninfluenced by hackers. There needs to be a standardized format for the signals all these workloads will send, regardless of any particular cloud environment.
Enter WIMSE. WIMSE is standardizing secure identity presentation for workload components to enable least-privilege access and obtain signals from audit trails so that IT admins get visibility and exercise control of over workload identities. To make it more challenging, this must be platform agnostic because no one is deploying single-platform environments.
SPICE
Sometimes, processes and APIs have nothing to do with humans. But sometimes, they do. They might run as a person in order to do something on that person’s behalf. In those cases, it would make life a lot easier to have a credential format that is lightweight enough to support the untold number of workload identities out there AND the human identities that might exist in the same complex ecosystem.
Here is where the proposed working group, spice, sits. Personally, I think it might have the hardest job of the three. While standardizing a common format makes a lot of sense, we can’t ignore that with human identities, issues like privacy, identity verification and proofing, and revocation are an incredibly big deal. Those same issues, however, either don’t apply or don’t apply in the same way for workload identities. If you insist on constraining the credential to be entirely human in its concerns, it’s too burdensome for the millions of apps and processes to handle at the speeds necessary. If you don’t constrain the credentials, security problems may creep in if the developers misuse the credentials.
So, of course, this is the group I volunteered to co-chair. I’m insane.
Wrap Up
Non-human identity is identity at an unprecedented scale. It’s a whole new world because there are many more workload instances than users. The same tooling and standards for human identity are not designed to operate at this new scale or velocity.
I have a lot more to learn in this space, and one person I follow (literally, I will chase him down in hallways) who knows a LOT about this stuff is Pieter Kasselman (Microsoft). He and several others are engaged within the IETF and the broader world to make sense of this complicated and anxiety-inducing space. If you work in IAM and you default to only thinking about the people in your organization, I’m afraid you need to start thinking much more broadly about your field. If you need a place to start, come to Identiverse 2024 or IETF 120 and hang out with me as we all learn about the non-human identity landscape.