The Evolution of Identity Management with Eric Olden

Secure Talk - Eric Olden

Justin Beals: Hello, everyone, and welcome to Secure Talk. This is your host, Justin Beals. I began my work in computers as a hobbyist a long time ago, and one of the very first things that I noticed in working with computers or learning how to work with computers is that we were fast moving to a very networked computing environment.

Essentially, we could have resources, data, or systems that are accessed by multiple people. And that was even true back in my middle school computer science laboratory, where we stacked Apple II e's and had a lot of fun working on those systems. As I began to be a professional in computer science, we certainly, with the advent of the internet, were building software for not just millions but perhaps billions of people to access them. 

With the understanding that each person was an individual and that they needed to access the right set of data for who they were at the time of data access. This is probably the first cyber security problem that I ever worked on as an actual engineer. It was very powerful, it was very exciting, and a little bit dangerous about how to architect properly identity management.In our software and in our solutions, as we progressed in building web applications, a big challenge for almost any project was the identity management portion of the project, and there was a time when I was proposing building new software where we would literally carve out the first 2 to 3 sprints of software development for setting up identity management, where are we going to store users? How do we decide what they have access to and where are they going to log in from? And then how do we maintain this identity expectation as they worked on data and looked at that data.  

As we learned how to do identity management more efficiently, what started popping up in the industry was identity management solutions where we could centralize location of identity information and even essentially outsource to a third party application authentication itself and some of the encryption tactics that go with it. That was a big win for me because all of a sudden, instead of spending three weeks on setting up identity management, we could get right to building what was unique about us and offload the identity management code to a third party.

It comes with risks, however, and identity has gotten much more complicated than it used to be.

 Today, we're going to talk to an expert in identity management. Eric Olden is a seasoned entrepreneur and technical founder with over 25 years of experience in the identity industry. He's the co-founder and CEO of Strata Identity, where he has pioneered innovative solutions that enable secure and straightforward access to applications and data across multiple clouds and identity providers.

Before Eric founded Strata, he led Oracle's global identity and security division and founded Simplified, the first identity as a-service single sign-on company, later acquired by RSA, along with founding Securint ClearTrust, also acquired by RSA. His contributions, and one of the major ones that I certainly took advantage of, was co-authoring SAML to introduce the concept of federated identity and the identity query language to enhance policy governance.

He holds multiple patents in identity management and cyber security. 

Please join me in welcoming Eric to SecureTalk this week. Hi everyone and welcome back to SecureTalk. Today we have Eric Olden with us. Eric, thanks for joining the podcast today. We appreciate it. 

Eric Olden: Thanks for having me, Justin. 

Justin Beals: Excellent.

Well, um, we do have a little bit of a rhythm to these things and we actually like to start out just learning about our guests' kind of initial experiences with computing. Were you an early adopter as a kid, or did you get into it later in life? 

Eric Olden: You know, I was of the generation. I grew up in the eighties and I got into computers through video games and all through elementary school and high school, my mom was constantly saying, Oh, you're wasting all your time.

And what she didn't realize was that was how I was figuring out. How to get this machine to play more video games? And one thing led to the next and, you know, found out from myself, a CTO of a identity security company and college and would not have expected that early on because I don't know if that's a natural progression, but that's what happened in my case. Self-taught.

] Justin Beals: So you were self-taught from a computing perspective then. What were some of the early programming languages and systems you were working on? You know, 

Eric Olden: most of it coming around video games and Windows in particular. Some of it was DOS before. We got Windows and, you know, just figuring out how computers work.

One thing that the funny story in our family is my dad got an Apple IIe, and he brought it home, and the first thing I did when I had an opportunity was I took the whole thing apart, and then my brother's like, dad's gonna be so mad. And I said, Oh, it's okay. If someone built it, I can rebuild it. And I was so confident in, I don't know, probably fourth grade and put all the pieces back and it did not work.

And my dad was coming home, and my brother's like, Oh, you're going to get in so much trouble. And back on that computer, if you had one, you may remember they had this ribbon cable, and it was a rainbow. And it was; I had not seeded it correctly. I had it upside down. So right in the nick of time, I flipped it around, plugged it in, it booted, and everything was, was good after that.

And so that was probably the school of hard knocks, I think, a crash course in computer assembly. 

Justin Beals: I still have my old Apple basic book. I think that was one of the first languages I learned. Yeah. It's been a lot of time in the middle school labs. We had those old Apple twos in every grade school lab. I remember.

It's interesting to me cause you mentioned that, you know, you're from the Bay area. So were you in the belly of the beast for the home computing, the, you know, the, the computer hobbyist revolution during that time? 

Eric Olden: Well, I was young at the time, but my mom worked for Apple in the eighties and Apple I grew up in the South Bay in Silicon Valley, and I would drive to high school in Mountain View, and I would pass the infinite loop campus right there on Highway 85 and two 80 areas and, you know, Cupertino.

And I just took it for granted. I thought everyone that's what it was like everywhere, but so yeah, I guess in the belly of the beast and that part of the peninsula and then growing up and going to college and starting my first company there, we were in San Francisco during the. com days. So I think I was really, really close to a lot of the early stuff.

But It wasn't a master plan that we had. It was just, Hey, that's where my family, we'd been there since the 1800s. So it was kind of just there at the right time, I guess. 

Justin Beals: So I do have to ask, like my college, I was playing with computers. I was doing a lot of just playing on the one at the time where IP addresses, but we had a network that we can move around in mostly because I was interested in theater.

That was my degree. And so I wanted to join all the listservs for other theater professionals to hear what they were talking about. But you were interested in identity access management. And that's a very, you know, a very distinct area early on in web application development. How how did you even get introduced to the idea?

Eric Olden: So I went to school in Berkeley, and in the time I graduated in 1995, so junior-senior year were like 1993 through 95, and that was right when mosaic and all of the Netscape early stuff came out. And the way I [got exposed to it was that the computer lab for the engineering school had the best connection to the internet.

And I knew that Hey, if I just went to these buildings and Evans computer hall and I went to the basement there, we'd have really fast internet. Now, we weren't doing very many compelling things because there wasn't a lot of content there. But one thing led to the next and. At the time, there was a whole thought that the internet's going to be academic and you can't use it for business.

And I thought I don't think that's going to last. So,what is holding back the real use of the Internet for commerce? And it was security. And there were a lot of people trying to solve problems around encryption problems around, um, transactional security, authentication. But what people hadn't really solved in the late 90s was how to manage all of these users on your website.

And now, we call it consumer or customer identity and access management. At the time, we were, you know, one thing led to the next, and our first customer was Cisco. And at the time, they were the biggest e-commerce site in the world. And three guys in Berkeley wound up building this software. That Cisco deployed, and it worked.

And all of a sudden we were in the business of now what we call identity management, but it started in our world as entitlements management. And that was just what Cisco was calling it. And then we sold to Wells Fargo as the number two company. And then the Lehman brothers was the third. And once you had three all doing the same thing, that's when we realized, Hey, this is a product. It's, it's something that we can scale. And one thing led to the next. And it went from a handful of guys to, you know, almost 300 employees and, you know, about to go public. And then the. com crash happened. But so very interesting time in the market and definitely informative for me growing up and learning entrepreneurship very quickly.

Justin Beals: And I'm, curious about the nature of the entrepreneurship. Did you walk into these contracts with Cisco? For example, thinking of it more as a services, like we're going to, you know, write some custom code, build a database, build an interface where you can authenticate it, and you'll own it. Or were you thinking product right off the bat?

Eric Olden: Well, we were thinking product right off the bat because we had done similar to what you were describing for other companies before that when we were trying to figure out how would we build this, and we built some implementation for Silicon Graphics, SGI, they were a great customer of ours. Yeah, right there by my high school in Mountain View.

You know, but we saw early on there was a lot of use of Perl. That was like the way to do it. CGI was, you know, way that you could do the most interactive things. But to set it into context, what we learned in those early kind of services-driven things, there's one big breakthrough that now we take for granted.

But in the nineties, it was a big thing was maintaining state from one webpage to the next and being able to control state. That's when I had the realization if we can make state happen, then we can say whether it should happen. And once we can apply a policy to state, that became access control. And then everything that stemmed from that at the time, mostly, mostly of it was password-based authentication.

But one thing led to the next. And we said, Hey, what if we did this for, you know, a thousand users, 10, 000 users. And then we were saying, because of customers like Cisco, how does this work with 5 million users? And at the time, people just didn't have systems with millions of users in them, but we did so that I think was the transition when we realized, Hey, if we're going to build it at the scale of millions, we have to really think about a repeatable product rather than a toolkit, and I think that was really where things solidified around our product Clear Trust was the was the product that we built. And by the time we were working with Cisco, is 100 percent product. And but it was a lot of learning curve to be honest, I think. I didn't study product management. I didn't study, you know, software engineering, you know, of all things they studied, you know, pre-law finance and sociology.

So those are all the things I thought were interesting. And I just did the software kind of on my spare time. And anyways, so sociology major that is running a CT as a CTO of a software company in the nineties was, I don't know how people, I guess they didn't know what else to expect back then. I have webmasters. Don't blame me.

Justin Beals:  That was the dream job. Wasn't it a webmaster? I, I totally, I wanted to be one. Yeah. But I think I'm going to tangent here a little bit. It's not an unheard story. I sometimes wonder if it's more folklore than real, but I meet enough people that have taken this path that it seems. A distinct possibility, a high possibility, that people with a liberal arts background, critical thinking, wanting to work in problem-solving spaces, a desire to create sometimes find out being in computer science and developing interesting technologies and products for the market. I don't think I, I think while it's a fun story, it's also a true tale. We see a fair bit of it. 

Eric Olden: Yeah. And you know, I think of all of the schools of thoughts, I think the thing that are really two things, the systems thinking and dealing with first principles. And, you know, when you really understand how those things work, then you can apply them in a lot of different scenarios. And, you know, like you think about systems, thinking about inputs and outputs and stocks and how you manage something in a closed loop or an open loop, you know, that's what computers did, right?

So, that example of that cable being upside down, I didn't complete the circuit. And in my mind, I knew something was either shorted or something wasn't connected. And no one told me that that's. How to debug that. It just, I think came to me because of the way I think about systems and of all things like aquariums, like I kept tropical fish a lot, a long time.

And you think about, well, why do tropical fish, you know, African cichlids, have anything to do with computers? Well, there's a whole ecosystem that you need to manage, and if your chemistry and the water goes wrong, or you have too much of, you know, one thing or the other, the fish die. So it's about maintaining balance and that equilibrium I think is, you know, is a reflection of that.

And I carry it to what we do here today in, you know, the multi-cloud world. It's just a big system of connected networks and, you know, where it starts and where it ends and you know, everything in between. So, I do think you're right in that regard. That's been my experience anyways. 

Justin Beals: Well, and certainly as we talk about security, that being able to utilize systems thinking allows us to define a boundary, which I think is a verse principle and being like, what are we securing?

You know, and what are the characteristics of that boundary area? Now, I was interested in one other thing in your past. You mentioned that you developed this company. You were doing, I'm going to,  identity management in a way early on, but you were also deeply involved in things like SAML and getting SAML off the ground.

And I know I've used that standard in building web applications and authentication. Tell us a little bit about the origin of SAML and how you got involved in that project. 

Eric Olden: Yeah, so when we were in the enterprise, right?, so the big companies that we sold to, one of the most important ones for us at that time was Lehman Brothers.

And they had three data centers. They had New Jersey, London, and Tokyo. And they were running my software in two. And a competitor software in the third in Tokyo. And I was trying to convince leadership at Lehman Brothers, hey, wouldn't it be best if you just let my company secure it and clear trust, just run that everywhere, cause then we can connect it all. Because we control both ends of the, the connection and the, the CIO said, I would never do that. And I said, interesting, why he goes, because I don't want to ever put all my eggs in one basket. And, you know, here's the thing. How about you rethink how you're going to do it and you can't throw the competitor out.

You have to find a way to work with them. And the company at the time he's talking about that our competitor work at the time was Netegrity. And they were based good company based in Waltham, Massachusetts. And we were in San Francisco. And so there's kind of a cross-bay rivalry, if you will, across the country.

Yeah. And, oh man, it was tough to say, okay, we're going to partner with them. We were just fierce rivals. And we had. My head of engineering, Darren Platt, he and I have been designing this way to make different connections work where your trust is delegated. And we had done a lot of that based on the way that credit card transactions are settled. And we call it the four corners model where you've got, you know, issuing bank, a merchant bank, a retailer, and the consumer,  and the relationship between those four. In the real world was well done, well understood, and we said, how can we take a similar concept where the different entities are independent?They are not related to another. How do they get that working? 

And so we started to like, peel that onion back. We realized, hey, in order to do that, you need to trust. In the internet, that was cryptographic. And so we started to design a cryptography model that would use certificates to verify different endpoints.

And that was, I thin,k the most significant part and then the second part was, well, if you're going to be sending information about the customer from one to the next to the next, you need a way to securely move that data. And so that became the authentication and authorization part of  the problem for us.

And we figured how to encrypt that data and sign the assertion, is now we would call it at the time. We were talking about cookies and redirects and things like that in the prototype days. But in the end, we got it all working. We said, hey, this is great. Now, we just need to have someone who we don't trust.

Play a part in this. And that's when it became, we got to make it an open standard. Can't have it a proprietary feature because then, like the Lehman Brothers use case would be out of scope. So it was at that point we said, all right, let's find a way to write a standard. And I approached Oasis at the time XML company standards body.

And I said, Hey, we want to do transactions in the secure, trusted way. And we'd like to bring this to Oasis. And then, coincidentally, the rival from Netegrity they were interested in doing the same thing. They were approaching the problem, but more around the way that you would think about SOAP web services.

And we said, hey, we can make these two work together. It's not an either-or. So why don't we take that token, put it on our trust framework, and now we can trust those transactions and the tokens, and we can move something across tiers. And, you know, that was the way that it got started. And it was a lot of fun.

There's a lot of naysayers at the time that, Hey, you know, you're, you've never done this before, you can't do it. The standards gotta come from big companies. Like, you know, the typicals, but in the end, you know, I just stand by adoption and saying, Hey, if it's really open and it's really adopted, then it can be a de facto standard.

And here we are, 2024, and it's, it's everywhere. So it's a lot, it got further than I ever hoped, but that was the origin for us in the nineties, late nineties. 

Justin Beals: I always felt like there was something really elegant to the standard, and that was this concept of assertions. You would go through a process against an authentication like a domain or, or some type of data store that authenticated you, and then it created a certain number of assertions.

There was no guarantee What those were valid for in other places, but they were available if if they would trust it to unlock, you know, other data. And that's an incredibly flexible modality. Anyone can participate. It is, you know, open both in that we publish the code, but also open in that participation in the network of information is available to all in a way.

I have to applaud y'all on that. That was fun to see. Yeah, 

Eric Olden: Yeah, that that I think what you're getting  at was one of the first principles of SAML, right? Is to be able to transact without having it in any particular use case. In the early days, when we were doing it before we got to 1. 0, I think we did that really, really well.

I think we started to see some drift and scope creep in SAML, certainly, by the time it made it to SAML 2, then you had all sorts of profiles that were stipulating how you do very specific things, which it made it easier if both parties wanted to do that one thing, but it started to move from that general-purpose to more special purpose, and it got a whole lot more complex.

So I think, in my personal opinion, the glory days of SAML was SAML 1. 1. That was, I think, the peak in my view of the combination of simplicity, and it did what it needed to do. 

Justin Beals: Yeah, it's, you know, which probably brings us to the thing that I learned the most about the next iteration, which was OAuth and I have a quote for us that I think is kind of funny.

It said, you know, it, it asked which the best, best identification, identification framework was on the market. And the quote is, “One is really complicated and often confusing. The other one also uses XML”.

Maybe you can tell us a little bit about, you know, we have some new, I think of, oh, certainly, but there are a lot of now identity standards that are out there in the marketplace. Yeah. 

Eric Olden: You know, I think there's, I'm a huge believer in standards because they are open, right. And nobody controls it. It's a community-driven thing.

And the best ideas generally win, right? Sometimes politics, you know, are unavoidable, but when it comes to the more elegant and the simplest solution, I think Mark Twain said  it best. I writ, I would have written a shorter letter, but I didn't have the time. Right. And so what I mean by that is. Uh, another metaphor or example is what is a camel?It's a horse that was designed by a committee. 

And you kind of see when things start to get bloated, right? It's like, they're not necessarily bad ideas, but you start to put one onto the next. And that was what I was getting to about where SAML 2. 0 got, was, man, there's way more things here than what we really need.

So wherever you can, I think, peel it back to the basics and say, Hey, let's stick with this because the simpler it is, the easier it is for people to implement. And I think something that's easy to implement, even if it doesn't do everything you want it to do. It is going to get the adoption and then you could solve those specific problems on your own because you've got something that fundamentally gets, the basic core use cases done.

That's just my opinion, I guess. 

Justin Beals: Yeah, it certainly drives the broadest horizontal value for the most number of participants, customers, users, and I think in network computing, it's something we're always thinking about a little bit; I think it's a good time. I I'd love to learn a little bit about Strata, your, latest venture, what you're working on.

What types of problems in the identity access space are you working on there? 

Eric Olden: So what we're doing with Strata, I tell people we're building the VMware of identity. And part of that is to communicate. How when you think about what virtualization and VMware did to computing transformed it, and it went from everything was hardware driven where lock-in was the default, and people had to really which operating system they're going to build their applications on, and you have all these dependencies, and it was really, um, a lot of work and then VMware comes along and says, Hey, let's put an abstraction layer on between the hardware and your virtualized with software will make the server look like whatever it needs to look like.

And now you can run Linux next to Windows. And you can run Solaris on top of that and, you know, all those other things. And what's going on in Identity today is a parallel to that, in that instead of servers, people are building applications on top of Identity providers. So you have IDPs and in Identity, it's the Octas of the world, it's the Microsofts of the world, it's the Pings of the world, the Oracles.

And what my company, Strata, has done is created an abstraction layer that sits on top of all of those different identity systems. And we turn each of those IDPs into a part of what we call an identity fabric. So, you can think about it as a way to abstract and normalize the identity systems. And why would you want to do that?

Well, a big reason is because people are wanting to move their applications to the cloud and not rewrite them because they're going off of Oracle in their data center and they want to use Microsoft in the cloud. Typically, you'd have to rewrite the application. Similar to how you'd have to port an application from one operating system to the other in the pre-virtualized world.

So what we've done is created this way that you no longer have to think about what identity provider you're using. And instead, you can orchestrate multiple identity systems. So that's useful if you're doing something like a multi-step transaction. Let's say that you're onboarding a new customer and you're a bank and you need to do a number of different things, including create an account for that user, collect basic information from them, but also to comply with regulations; you need to make sure that that's not a bot.

 So, you need to validate that it's a real identity. So in that example, you can orchestrate the user from the sign-up part of the process, take them over to an identity verification, like a One Cosmos or something, and then maybe the third step, issue them some pass keys or password list, and then fourth step send a confirmation email.

So when you need to orchestrate those different four examples that I shared, that's where orchestration software comes in, and that's what Strata built with our product. We call it Mavericks, and it's just a way to think about identity. That is useful for  Companies that are organizations that run on multiple clouds or that run some things in the cloud and some things on-premises.

Justin Beals: Yeah, there is. It feels like a very cyclical nature. We're fickle human beings, probably is the reason. But you know, we started out with identity being like, I just need to authenticate people then even managing the number of systems that people needed to be able to authenticate became a security risk unto itself.

So, we build IDPs and we use an IDP in our product development. It just, you know, I, I always hated that I had to spend the first, you know, four sprints of a new product on identity management. And I was like, Oh, you'll get me through that in three days. That seems much better for kicking off our project.

But now we have a resiliency issue. Right. Like I have the keys to the kingdom located in a single system. And we know that a monoculture of tech is a dangerous place, especially in the enterprise. Right. 

Eric Olden: Yeah, absolutely. And the more that we see well-publicized incidents like over the summer, who could forget the CrowdStrike outage that wasn't an identity outage, but what it did do is highlight when you're single-threaded, and you have a single point of failure. You really should be assuming it's not whether you have an outage. It's when is it going to happen? And what are you going to do when it does? And so from an identity standpoint, we've been looking at that for a number of years, and we actually built a capability into our software.

So that you can have failover and the orchestration software will monitor multiple identity providers. If it sees that there's distress or an outage on your primary, it can fail over to a secondary. Now that could be another cloud identity system, or if your connection to the cloud is offline, then you can fail over to an on-prem identity system.

So, it could be something like Active Directory. But the key is that you need to have your tier zero identity services always up and running. And as you know, with the tier zero, that's, you can't have your applications running if you can't secure them any more than you can run them without network or, you know, bandwidth and power.

So when you deal with the critical infrastructure, you really need to be thinking how do you eliminate any single point of failure in the software that runs that. But also the systems that you're supporting, so you have redundancy and resilience kind of in your DNA as you now can run, you don't worry about how to keep everything running because you've been able to compartmentalize and a lot of that has to do with, you know, design and going back to first principles and system thinking, right?  How do we keep this thing, whole thing, working when any individual part may fail? And that's a fun problem to solve. 

Justin Beals: Yeah, it's really intriguing. You know, one thing I was curious about is that we see, I think business, especially in the SaaS space, like IDPs move really quickly. So we have octas of the world, and you can pick them up If you're a developer.

I'm always curious, especially as we talk about standards is, Is there any systems that you think are valid for self-hosting? Like if I were running identity orchestration and I wanted to self-host some identity management in a colo facility as well as use a cloud type tool, you know,  tandem.

Is there IDP tooling that you can self-host that you think are good tools in the marketplace to look at? 

Eric Olden: Yeah, if you're if I understand your question being is there a kind of a starter kit to inexpensively stand up an Identity system in the cloud, if that's it, then absolutely some of the tools are really designed for that.

The kind of, I don't want to say low end because it sounds like the software doesn't work. It's just a lower-priced end of the spectrum. More on consumption pricing is Amazon. They've got a great product incognito. On the other hand, you can put up some open source software and tools like Keycloak and OpenLDAP are good tools that, depending on your technical depth, you could run that and just pay your hosting fee.

So, it kind of depends on what your use case is. You can also work with, I think Microsoft's got a great approach in that and off our octas off zero subsidiary does this as well is that you can start on a consumption basis really inexpensively. And if your site takes off and your application becomes able to afford it, well, then that's when you start to pay for it.

So kind of freemium that turns into pay as you go. That's another thing to look at, but there's so many great options in the IDP world today. It really kind of depends on what your preferences are and your aptitude, but there's a lot of options out there. 

Justin Beals: One thing you mentioned when you talk about identity orchestration, and I'm seeing it thematically, we're seeing it in our work, is that you kind of, I think in some ways are exposing almost a programming interface.

For your customers on top of your platform, or it may truly be, you know, like a Terraform type situation where there is a language to it. Do you guys think about that from your Mavericks product perspective? Is that part of the value proposition? 

Eric Olden: Yeah, absolutely. And there's really two areas that we do that in.

One, is we led the development of a new standard for policy definition. And we call that identity query language or IDQL. We built a reference implementation in open source that the cloud native computing foundations sponsors or, or hosts anyways. And, that Hexa tool is something that you can download.

And what it does is pretty simple. It can, you point it at. Say one of these cloud platforms like Amazon and what Hexa will do is it'll extract out of the cloud system. The policy that defines access to your applications and data, and it takes it from the proprietary format or syntax of, say, Amazon converts it into a human readable, a declarative representation called IDQL human readable.

You understand what the policy, how it's constructed and how it works. And then Hex, you say, look, I want to take what's in Amazon and clone it over in Microsoft. Well, Hexa will do that for you. It'll convert IDQL into the version of, say, the Microsoft policy representation and allow you to have portability between two different cloud platforms.

So, part of it in that example, Justin, is that you can use software to do the transformation of policy from proprietary to cloud. To standard and from standard to proprietary, no real coding involved in that. The second area is around automation or what we call service extensions. And if you think about using orchestration as a way to broker the seven A's of identity, authentication, Access control, authorization, attributes, administration, auditing, or governance and auditing and availability.

So you got all of these seven services.You can extend any one of those seven services or all of them in a low code way. Where you would want to do that is maybe you're having some kind of special way to present a landing page that will customize based on what language are you coming into, and one of our customers uses it to dynamically generate and context and they do it at the identity layer. 

So if you're coming from, say, Spain or Latin America, it's going to translate and send you to the Spanish content. If you're coming in from the U.S., It'll send you to, you know, English content. So that's an example of how you can use these extensibility points to create a really compelling experience for the end identity.

But under the covers, it's really made easy because you don't have to build all of that integration. Instead, you're just kind of doing it just in time where it fits as an extension of any one of those different orchestration points. So kind of a mouthful, but. To net it out extensibility at the service level and extensibility on the policy level.

Justin Beals: I think that's very powerful. I am using this phrase lately that I think a lot of us that consume software for enterprise use cases are looking for the ability to make a Goldilocks fit with the tooling that we're purchasing. And we're more and more open to investing time and energy into getting them to conform to how we want to operate.

I, I'm reminded of a really basic principle that you point out when you talk about the six a's a little bit, and that identity management is a broad topic, but ob every single time I hear it, I go to username and password, I love that you have your six a's down. A lot of environments where I've had to known our acronym like really well.

But I was curious, as I, I, you have a great book  on identity access management from your website. I was reading it. And I'm curious about one aspect, which of those A's do you think are the hardest for the enterprise to implement effectively? 

Eric Olden: That's a loaded question. I think they're; they're all easy for different reasons and all hard for the similar reasons, right? 

And what I mean by that, um, you know, I may be inadvertently quoting Tolstoy or somebody like that, but the grapes of wrath or something like that. My friend Topher would be. Roll in his eyes right now. So, but my point of it ultimately being is that if I had to choose the one that's the, most important, maybe I'll answer it that way.

The most important thing in my opinion is to get authentication, right? Because way too many people are thinking authentication is a password, and we've been creating so much technical debt as an industry that if you look at where the breaches happen, over 90 percent of them come through some form of compromised credentials.

And it's, it's easy to hack a weak website and play on the fact that humans are lazy and we use the same password in a lot of different places. And what a lot of humans don't put together is that, hey, if I have, and it's not my password, but one banana is my password at my bank. Odds are one banana is also the password at that.

Uh, tropical fish hobby portal that I signed into. Well, if the hacker wants to get into my bank, the bank's really hard to breach, but the little website that has passwords in there that you can find your way into is a lot easier. So take the password out of the low-hanging fruit and use it at the high-value target.

So that's just a very common thing where we see it time and again. I think where people are really ones that are doing it right, have moved past passwords, and they're using passwordless, which is a funny term in itself, but the way to think about a passwordless kind of implementation, I think the one that most people have is, is in their, their phone, right?

Your  Android or your iPhone and being able to use that, uh, biometric that's built into the device. That is infinitely more reliable for the transaction and it's infinitely more enjoyable than trying to remember your password and going through all of the hassle when you forget it. So I think that would be the most important place of all those A's to start.

I think the hardest to implement, I will say authorization, fine grain authorization is a real hard one. For people to get right, because you need to, in the first place, design your application so you can work with an externalized authorization rule engine. Right, right. That's a different paradigm than a lot of developers think about, right?

They think about 12-factor applications. Well, identity is a 13 factor in that if you don't put it into your app, you can call it from an external provider. So, some examples where I think tools that exist are free, OPA open policy agent is a great one on cloud native computing foundation. And. You feed that with one of the other A's, attributes.

So if you're going to do authorization, you also have to think about how you get the data to put it into the rule engine. So now you've got two things, two of the A's that you need to manage to do one of them. So you can start to see how it becomes a lot more convoluted than I think people initially think.

So, if you do it and you start from the beginning with an externalized authorization, it's incredibly powerful. You can change all sorts of things, you know, to retest and recompile or anything like that. It's just, um, a much more configuration-driven system. But you do have to do it in the beginning. So most important authentication, hardest to do authorization.

Justin Beals: Yeah. I, I find the password list thing. I mean, it's tough sometimes. I, I didn't do my entire career in the security space. I came from product development and I am translating some of the, the marketing and sales concepts. And I, when I first heard passwordless, I was like, wait, really? What does it mean? It took me a couple of clicks to get in.

But I see the kind of identity association requirement around it and how powerful it can be. I think it is a little unnerving because we're so inured to remembering what our password was. And now we've bought all these tools so that we use different passwords and different systems. But I certainly much more enjoy actually what I consider an old school way of multi-factor authentication with a key code value that's constantly being replaced. In my old days at BT, I had a little credit card. It'd give me a number every minute. And that's how I authenticated into sensitive systems. And I always knew where it was, and it was always different. And I, it was not a password. It was a rotating algorithm. Yeah. 

Eric Olden: Well, that was the crown jewel of security dynamics, which later changed their name after they acquired RSA. But the RSA token was originally just that rotating passkey or, I'm sorry, you know, one-time password. And that I think, got us as an industry a long way, but it also made people have to keep that with them at all times, right?

So you had to have your credit card, that form factor or the key chain and things of that type. And that's where I think the biometric stuff is even better, because you know, maybe you forget your phone, but you can't forget to bring your face. I mean, I guess in some weird world, parallel universe, maybe that's a good story. 

Justin Beals: But that's not good Hollywood movies about this problem, but I'm not sure if we've hit reality with it yet. Right? Yeah, 

Eric Olden: Exactly. They always have that spy thriller. Really? Yeah. Pops somebody's eye out and puts it on the scanner. Doesn't really work like that. So yeah, maybe go too far. 

Justin Beals: Well, Eric, first off, I'm really grateful.

A lot of the standards for identity management you've worked on have been in countless bits of software that I've used. And certainly, concepts you helped invent made me more efficient as the chief technology officer and a leader. And also really grateful for you spending time with us today on Secure Talk and just helping reveal both what you're working on from a future perspective and the nuances of identity management.

Thanks for joining us. 

Eric Olden: Yeah, well, I'm, I'm glad you had me on and you know, I don't take credit for all of SAML. Uh, we were there in the beginning, as I shared, it was born out of necessity. We wanted to keep our customer happy. So, but I'm so proud, of where it went. And then the new standards, right? The IDQL and the others that like the passwordless pass keys.That's another standard Fido too. 

So I love the fact that everybody, not everybody, but most people get the value of the standard. And I just think that's the a great thing that'll survive me. And by many years, so really proud of that. But the part I played is, help get it going. But the other part is, you know, keep it going, right?

Keep thinking about the next problem to solve and where can you do that and do that in an open way where we can solve it for everybody, not just for one product line, and I think that's been, you know, a way to, in a sense, give back to the industry that's been so, you know, generous to me. So one, one small bit of thank you, I guess, in that.

Justin Beals: That's wonderful. Yeah. Well, Eric, have a great day. Thanks for joining us. 

Eric Olden: Thank you, Justin. Take care.