Cloudentity Blog

The term "API" is tricky.  It stands for Application Programming Interface, but a lot of people seem to think it means “All Powerful Incantation.” You always see decision makers sigh in relief when they find out a product they’re looking at has an API, they’re not sure what it means but they know their developers will be able to do magic with it.

Trouble is, an API isn’t a single thing.  It’s the classic elephant where blind men each get hold of a different part of the elephant… “It’s a snake!” “It’s a tree trunk!” “It’s a wall!” To front-end developers it’s a collection of resources. To a SysOps engineer it’s a firewall. To an engineer it’s an abstraction. And to an Information Security officer, it’s a big mess.

Security management has historically been focused on the User attempting to access a resource. But in the increasingly complex world of CI/CD methodologies and microservices, it’s no longer “Users” and “Resources” we need to secure. Applications need to talk to each other, resources need to move from development through production and be managed by automated systems, and the systems themselves have become consumers and contributors.

We tend to think of “Identity” as a static thing. I’m “me” and I can prove it! Only my “identity” is extremely fluid. Identity, in the IAM world of Identity Access Management, isn’t just me proving I’m Michael Bissell, but it’s me proving that I’m allowed to do things, and therein lies the challenge.

To be honest, most companies still use their IdP (Identity Provider) as a way to login with AuthN, plain old Authentication. They think they’re doing AuthZ (Authorization), but in reality, you have a fractured Identity strategy any time you have a system that has to make a second call to a database after I log in, just to figure out what I get to do.

I started my career back in the days when we hosted servers in the basement of the office. At the time, we never really thought much about security until we deployed the code (which pretty much meant FTPing a bunch of files to a server). Security was handled at the router first – block malicious traffic from getting in the door. Then we locked down the firewall on the server itself (no, you can’t telnet from outside the building).