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.
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… Not even at the time of login, but constantly, and in such a way 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 YOU'RE you. If your account gets 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, but where and when, 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, you shouldn’t have to wait for the next time I log in to tell the system about that change.
Note that I put “Organizations” in 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 5 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 effect 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 – we have 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
But 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.