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 world of Identity Access Management (IAM), isn’t just proof that I’m Michael Bissell, but also proof that I’m allowed to do things. 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.
To get a really clear picture of who I am and what I get to do, my IAM needs to be fed from a LOT of different sources. And not just on a nightly synchronization job, or even at the time of login, but constantly, and in such a way that it can be acted on immediately if there is a breach.
So let’s consider some of those things you need to know about me to have a clear, in-the-moment picture of “me.”
My Colleagues and Friends
In a GDPR world where consent is king, authorization just went exponential. We need systems that say I’m me and I can access something, and systems that verify that. If your account is compromised, I shouldn’t be able to access your data anymore, even if I’m still golden.
Where I am supposed to be is pretty predictable — if I’m at home, I’m probably me. If I’m at the pub down the street…well I’m probably still me. But if I’m at the knitting shop on the other side of town, we might want to check that I’m still me. If I suddenly log in from New York AND Portland at the same time, we’re probably seeing a hack. Location is not just about where a user is, also when they are in a certain location, and rules need to be established for where and when is okay.
So much of what we buy access to is subscription-based. Knowing that I bought something, and, therefore, should have access to it should not be a manual process. It definitely shouldn’t be a separate process from managing my identity. If you revoke access because my renewal didn’t happen, or because there was a change in my status, then you shouldn’t have to wait for the next time I log in to tell the system about that change.
Note that I said organizations, plural. Most IDPs assume you’re an employee at one place or another, but in reality, we live in a world where I might need to log into a system as an employee for my company, or as contractor for your company. These relationships, once considered static, may change daily, or for a one-hour, on-site meeting.
At the time I log in, I might be “me,” but five minutes later, my account might be compromised, or in danger of being compromised. My persistent identity needs to be modified as we learn someone is getting close to impersonating me. A real-time change in my risk score should affect a real-time change in what I can access.
The problem is that most systems are not set up for this kind of real-time ingestion of all this data. We have a few tools at Cloudentity that make it a lot easier for us to manage real-time identity, like the Cloudentity TRUST Engine™, which uses behavioral machine learning to improve risk scores based on a wide range of data sources. We also have custom orchestration to allow the identity process to be informed from your proprietary or subscribed APIs. And our login and session management systems are informed by these tools.
At the end of the day, it’s not just about the tools to manage the data points that make me “me.” It’s about developing an identity strategy the considers the complex, dynamic nature of data that understand who I am.