For this Security > 140, I discuss identity with Pam Dingle (@pamelarosiedee). Pam is Principal Technical Architect at Ping Identity, a veteran of building, innovating and riding the many waves of the identity ecosystem. We discuss an appropriately wide range of topics from how developers should approach identity to unempowered frogs:
Gunnar Peterson:
Consultants always talk about people, process and technology. However there is an old consulting truism - its never a process problem, its never a tech problem Its always a people problem. So when I go to a security conference and I talk about SAML or OAuth, I frequently get the thousand yard stare, and when I go to an Identity conference and talk about CSRF or DOR I also get blank looks. Thinking back, there are very smart and capable people at these conferences, and yet, in the main, the security people know little about identity and vice versa, It struck me that I do not even see the same people from one place to the next, about the only people I see at both types of conferences are Bob Blakley and you. These two domains, identity and security, are totally intertwined - so how do we get better cross-pollination?
Pam Dingle:
I see a number of things we can do to get that cross-pollination going. I think proximity breeds curiosity, and the best thing that can happen is for conferences to start creating cross-discipline tracks. A lot of professionals have limited travel budgets - so it needs to be possible for identity folks to be introduced to security concepts (and vice versa) without the barrier of cost. I also think that there are some interesting thought experiments that we could curate to merge what often feels like extremely separate paradigms. CSRF is in fact a really good example, because it has a direct bearing on the identity world (receiving a form submission and making assumptions about where it came from is not materially different from receiving an authentication or authorization response and making assumptions about where it came from). Putting security concepts into identity framing and vice versa could be a good way to start to entice people into common conversations, pulling us each out of our respective echo chambers.
GP:
It seems like companies’ approaches to mobile identity really cover a wide range. For better and worse, there is not a lot of consistency with how people try to solve mobile identity. You see all manner or different home grown solutions and a hodge podge of different standards (password, certs, SAML, FIDO, OAuth, MDM). Are there different challenges driving people to different architectures? Or is this just normal early days of a new technology?
PD:
A hodge podge is exactly the right way to characterize it. The use cases are distinct and sometimes only tangentially related, and yet somehow they all still fall under this useless umbrella classification of "mobile identity". I would say that the three most common mobile challenges we see today in Enterprises are: 1) How to secure native mobile applications that rely on REST APIs without caching user credentials on the device, 2) How to use the unique location, hardware, and proximity of a device to a user to enrich the security of an authentication ceremony, and 3) Is the device involved in either Challenge #1 or Challenge #2 a known and/or trusted and/or uncompromised device?
Standards like OAuth and OpenID Connect are primarily centered on challenge #1. Standards like FIDO are centered on challenge #2, and can play a fascinating role in combining device-local authenticators with central systems in a standardized way. Product sets like MDM and EMM are centered on challenge #3. Passwords and certs could be part of the implementation of any of those challenges, although the question of securing a private key or other secret on a mobile device tends to push back into challenge #3 territory.
I do think this is early days for mobile identity, and I have to say, it's fascinating to watch the space evolve. If you are developing consumer-facing mobile apps for example, your risk assessment is radically different than an Enterprise use case - you don't necessarily have the luxury that many Enterprises have, of refusing to run on a poorly secured device. As such, the last thing you might choose to do is put a big heavy trusted credential like a private key or a password on the device. Your best bet there might be to create a lightweight, short-lived, very tightly scoped token there, so that the attacker you assume is living on the device with your app can only steal limited stuff for a little while. Compare that to the way Enterprises think of devices, where they want to *believe* that their corporate devices are trustworthy, and are willing to pay for the promise of a safe space, so that they can build a solid foundation for a chain of trust. Is it real? Well that takes us back to identity-security cross-pollination...
GP:
For a long time, “identity” has been a grand topic with many facets and edge cases, but once you reduce it to implementation it ends up primarily being about SSO and Provisioning, with a side of MFA. What are you seeing in terms of new use cases that will drive identity going forward on the different platforms in play today? Is it pushing towards stronger auth, more attribute granularity, portability, bidirectional communications? What do you see as the next killer use cases for identity?
PD:
I think we're already neck deep in the next killer use case for identity, and the most critical thing we have to do is to realize it. In my opinion the next killer use case is not (as you might think) granting consent, but un-granting it.
The problem we've always had with delegation & consent is that the consequences of giving consent are rarely clear. We balance our desire for a thing we want right now in the moment, against a hazy set of possible future outcomes, and most of us choose the instant gratification, even those of us who are suspicious or afraid - because there are almost no alternatives. We are accustomed to granting things -- and the services we use are accustomed to asking for anything they want, but there is a tipping point coming. Our own devices have been consumerized, and the line between security and surveillance on those devices is blurring. Part of it is for our own good, and we SHOULD be allowing it. The rest is dangerous and exploitative. If, with SAML and OpenID Connect, we have a layer of plumbing that could become the lingua franca of identity and access, then we could now have a solid basis upon which to specify policy. And those policies don't have to only belong to corporations.
In case you think I've got a terminal case of "the world should be a better place", no, I don't think this type of thing will come about by general consensus. Somebody will build a thing people want, and will give them innovative tools to intuitively start and stop the flow of identity data, device context, and other identifying information. When that innovation happens, I believe the response will be enormous. If that doesn't happen, we'll continue as a population of uncomfortable yet unempowered frogs, turning up the water in our own saucepan.
GP:
So the inverse of SSO is Selective Service Revocation, then, interesting. Ok, for traditional identity protocols like SAML, OpenID Connect, OAuth, and so on, you’ve been working with these for awhile, since the beginning basically. When you work with developers on integrating these protocols into applications, what are a couple of things you wish you knew at the beginning that you know now on things to do or avoid on implementation and integration?
PD:
For me, the #1 hard-won life lesson is: fear the hello world identity integration. You know, that thing that you make as a developer where you just get the thing working in the simplest case, and THEN you'll go back and make it compliant, check your inputs, and so on. Except sometimes you never get back to it, and you end up with something that seems like it works but is in fact exceptionally dangerous, because the true measure of a successful integration should be what it rejects, not what it accepts. Mitigation of risk around hello world identity integrations should be a built-in part of any running identity deployment, but when every integration is bespoke, the cost is tough to swallow: this is why I'm such a huge fan of OpenID Connect. As a 'last mile' integration strategy for applications, OpenID Connect allows non-experts in identity to easily create integrations, but more importantly, if you use OpenID Connect you can also run conformance tests built by the community. The OpenID Foundation has invested in official, public conformance tests for productized software, but they have also made the conformance software available as open source for use in private testing scenarios. This combination of "easy to write a hello world integration" and "easy to make sure the hello world integration never goes into production" must be the industry's standard for the future, if we want adoption and security to go hand in hand.
Comments