Eric Olden talks with host Giovanni Asproni about identity orchestration, a software approach for managing distributed identity and access management (IAM) and integrating multiple identity systems or providers (IDPs) to make them look like a single system from a user perspective. The episode starts with a refresher in identity and access management, then introduces identity orchestration and some of the challenges it helps to address, such as integrating disparate identity management systems after company mergers or acquisitions; managing identities in situations where some of the IAM systems are unreachable; and implementing more secure identity management in legacy applications. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
- SE Radio 578: Ori Mankali on Secrets Management using Distributed Fragments Cryptography
- SE Radio 571: Jeroen Mulder on Multi-Cloud Governance
- SE Radio 547: Nicholas Manson on Identity Management for Cloud Applications
- SE Radio 376: Justin Richer on API Security with OAuth2
Links
- What is Identity Orchestration?
- What is an Identity Fabric?
- Cloud Native Computing Foundation
- Hexa and IDQL
- OpenID
- OAuth 2.0
- Book: “Learning Digital Identity”
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Giovanni Asproni 00:00:18 Welcome to Software Engineering Radio. I’m your host, Giovanni Asproni. And today we’ll be discussing Identity Orchestration with Eric Olden. Eric founded and scaled Secure and Clear Trust and Simplified. Simplified was the first identity as a service company. He served as a senior vice president and general manager at Oracle where he ran the identity and security business worldwide and he was also a coauthor of the SAML standard. He created the first pre-integrated single sign on platform and identity fabric. Eric, welcome to Software Engineering Radio. Is there anything I missed that you’d like to add?
Eric Olden 00:00:55 No, that was a great introduction Giovanni. Thanks for having me.
Giovanni Asproni 00:00:58 Let’s start with a refresher about identity management. So today we’ll be talking about identity orchestration, which is about identity management. So it is a good idea to start with a refresher about what identity orchestration is and maybe give also an example, a practical example. So how our listeners will have a good mental model in their heads.
Eric Olden 00:01:18 So when you think about identity management first, and it’s a simple concept of how do you manage what users can access and what they can do inside of an application. And that is the gist of identity management. Now, when you go further into the details, there’s a good model I think of – the six As. So the first one is authentication. So how do you manage how you know a user is who they represent themselves? Are they using passwords or tokens? The second one is access control, and this determines whether a user can get to an application or to data that they’re trying to. And the third one is authorization. And most often this is for instance, within an application, can a user do a transaction? Can they do a transaction for a certain amount of money or something like that? A fourth one is the attributes, and the attributes about a user that are used in these policy decisions is sensitive.
Eric Olden 00:02:25 So you need to make sure that those attributes are secure. The fifth one is administration or governance and how you manage those user accounts, who has membership in various groups and so forth. And then the last one or the sixth one is audit. And so you need to be able to see a log of what users did over time. And so taken together, these six As represent identity management. So now the question of what is identity orchestration? And identity orchestration is a new way to think about identity. If you have multiple clouds, if you have multiple environments and you’re running in a distributed world. And so what we do with orchestration is similar to what the infrastructure world has done for some time. For instance, like using Terraform to automate and go do things in a particular sequence or Kubernetes, which is another way to orchestrate your compute. So what we did with identity orchestration was say, well, why don’t we apply some of those same concepts of abstraction and automation to the identity so we can make these distributed multi-vendor, multi-cloud worlds work in a more seamless way. So some people talk about identity orchestration as Kubernetes or Terraform for identity. So that might be a good way to think about what identity orchestration can do.
Giovanni Asproni 00:03:59 So here we are talking about situations where we have different identity management systems and identity orchestration is a way of actually making all these disparate identity management systems as if they were one somehow.
Eric Olden 00:04:12 That’s exactly right. And that we do through abstraction. So absolutely normalize the different APIs that the identity systems, the IDPs or the identity providers that they expose created a layer that integrates across all of those so that when you build a new application, it doesn’t have to be tightly coupled to any one of those identity systems. Instead it talks to the abstraction layer and through the decoupling of the application from the identity provider, it allows you to switch out different providers without changing the application. So you can go from an old to a new identity system behind the abstraction layer and not have to refactor or do anything to your application.
Giovanni Asproni 00:05:03 Okay. From a business point of view, what are the key challenges that identity orchestration helps to address? So from a non-technical perspective, more of a business perspective?
Eric Olden 00:05:15 Yeah, I think one of the most common two use cases for orchestration is modernization. So taking your applications and moving them to the cloud. And in that world you need to switch the legacy on-premises identity system with a cloud-based one. So modernization is a big important use case because in the absence of an abstraction layer, you’re gonna have to rewrite your application and that’s very expensive, takes a lot of time. The second maybe business scenario is with mergers and acquisitions. So when you think about one company acquiring another one, very often you’ll find one company has a different technology stack than the other. And so you need to have a way to have these two worlds coexist. For instance, you may have one company that’s a Microsoft shop, they use everything from Azure including the Entra identity provider, and then they acquire a company that has been using Okta for years.
Eric Olden 00:06:20 And so now you have a situation where you need to make Microsoft and Okta coexist. As you probably know, those companies are very competitive and they don’t like to play well with the other. Their answer is, throw them out and put everything on us. But that’s not practical for a lot of reasons, right? So from a business standpoint, the ability to be able to merge the applications and the different identity system allows you to handle these coexistence use cases a lot more seamlessly. And then the last use case I would suggest is when people are trying to get rid of passwords and legacy applications often rely on password authentication, that’s problematic because of phishing and breaches that come out of that weak credential. So a lot of great solutions on the market like pass keys and multi-factor authentication and tokens and all these really effective ways to eliminate the use of passwords. But the problem is you’ve got this new technology and you need to make it work on your old applications. And so in that case you can use an abstraction layer to link up modern authentication with a legacy application. And so that allows you to increase the security very quickly and meet compliance from a business standpoint and eliminate the exposure to credential compromise that passwords have. So whether it’s mergers and acquisitions, modernization or getting rid of passwords, orchestration’s been a very universal kind of tool.
Giovanni Asproni 00:08:01 Okay. So basically if when we talk about mergers and acquisitions is the situation where maybe you have employees that need to access systems of what was the other company before, but you don’t want to give them a different set of credentials?
Eric Olden 00:08:16 Yeah, absolutely. And it’s as practical and simple as, if in the merger and acquisitions case you have the new company and the old company, they have two different email addresses. Right before the merger, they were different companies. So you may have someone like myself, I could have an account at Eric at Oldco, but I want to access the new applications and I don’t have the Eric at NewCo email address. And so what the orchestration layer can do is say, well, I know you’re Eric at Oldco and I’m gonna map that to a different identity user ID in the cloud identity system so that when that user logs in, they get to the applications but they use the old email instead of the new one and it goes the other direction. So the new company has, their emails will then work as an identifier for the legacy application. So namespace mapping is a very common, very hard to do problem if you don’t have an abstraction layer that you can use to do that mapping. And so that is a really powerful use case for orchestration.
Giovanni Asproni 00:09:29 Okay. And it’s clear. And what are the main differences between systems that are on cloud and on premises? I mean, are there any key differences when we talk about them in the context of identity management and orchestration?
Eric Olden 00:09:44 I would say in 2023, there’s a lot of good options for different capabilities in the cloud. There’s fewer options for systems that are running on-premises because all the vendors have focused on going to the cloud. So you’ll see more capabilities in your cloud identity systems than you will on-premises in the legacy. Some of the, the key things that I think people get when you go to the cloud is someone else manages all of this infrastructure and identity is one of the most mission critical parts of any infrastructure. If your security and identity goes down, your applications are offline. So you think about all of the redundancy and the resilience that you need to think about. I think the cloud-based identity systems have done a great job and they have a really strong position in resiliency, but it’s not always there. So another way to think about how to leverage the best of both of those worlds is you could use orchestration to primarily use the cloud identity system, but if there’s a outage on the network, if a storm comes through and breaks the network connection to the outside cloud, then orchestration can fail that application over to an on-premises identity provider and go into more of a backup mode until your network services are reestablished because you want to keep your applications up and running.
Eric Olden 00:11:21 So a lot of capability in the cloud, but now you’ve got a dependency on that the cloud is available in the network. And so I think the way to mitigate those risks is to be thinking about continuity both at the application data and the identity layer.
Giovanni Asproni 00:11:38 Okay. Have you worked on any of these systems with a mix on the cloud and on premises where you had to solve these kinds of problems?
Eric Olden 00:11:45 Yeah, we do it actually all the time. Some interesting use cases too. I think the most interesting one I found was in naval situations. So cruise ships, which was a news to me, are floating data centers and they go out and all of the kind of entertainment that you sign up for and you want to watch a show or you want to get a reservation for dinner and all of that, that’s all done now on your phone and the identity system of all of these thousands of passengers who come on for a cruise and they get off, you have a lot of churn, thousands of users that come in and leave every maybe a week or so. And the challenge is that when you’re at sea, you don’t have access to the cloud in a reliable way, right? They’re nowhere near a fiber optic connection.
Eric Olden 00:12:37 ’cause naturally, you know, they have to use satellites and things of that type. So that was a really interesting use case because they said, well look, when we have the ship import, we can get all this really fat pipe data that we can synchronize things and do all of that. And as soon as we push off we go to like 99% smaller bandwidth. And so that was a really interesting use case. When I was at Oracle, we did a lot of work with the military and submarines have that same problem because when they’re underwater, by definition they don’t have communication anywhere. And so thinking about identity that works in both modes connected and disconnected, it’s kind of interesting in this new distributed multi-cloud world.
Giovanni Asproni 00:13:23 Must be also quite challenging.
Eric Olden 00:13:25 Very challenging.
Giovanni Asproni 00:13:25 And that’s, I know also sometimes the systems have software that is not necessarily the most modern stuff. You know, it’s like if you see entertainment things in the airplanes, they look like iPads. But from the 1950s maybe ,
Eric Olden 00:13:42 You’re right.
Giovanni Asproni 00:13:42 So that might add an additional challenge to actually manage identity properly. I would imagine.
Eric Olden 00:13:48 It is, you’re right. And I think people get accustomed to how fast technology changes in the consumer world, right? Your phone updating the apps constantly and the websites, they’re always updated. But that’s not the case in the enterprise. You go in the enterprise, these are applications. I’ve seen some that have been there for 20 years and people don’t know who built it well, they left the company a long time ago. So they don’t want to touch it, they don’t wanna have anything go wrong. So they say, look, just don’t touch that application, but we need to move it to the cloud. How are we gonna do that? Imagine you want to watch a streaming thing on Netflix, but then the only adapter on the back of the television is the RCA jacks and I’m dating myself here, Giovanni, but you know how it used used to be, you know, plug it in the red, the white and yellow.
Giovanni Asproni 00:14:42 You know, I’m of the same generation and exactly , , yes.
Eric Olden 00:14:48 Oh I just want it to work. And actually that’s a good metaphor for orchestration, right? You think about a travel adapter and the way that you’re in Europe right now. I’m in the United States and if I were to bring my laptop to London, I would have to have the British power adapter, which by the way is just not very efficient at all my personal opinion. But I guess that’s the American bias here, . But so what do I do? I don’t wanna buy a new laptop that I bring to Europe that wouldn’t make any sense. So instead I find an abstraction layer of travel adapter and that becomes the thing that I plug in the American plug into one side and then I have various adapters on the other and I’ll stick it into the appropriate unit in wherever I’m going. And that’s in essence what identity orchestration is able to do is you can plug the new stuff into the old stuff without changing it because all of that mapping is done at the adapter or the abstraction layer.
Giovanni Asproni 00:15:50 It seems to be a good analogy. Which actually brings me to a question that I had in mind that is, are there any characteristics of the identity management systems that need to be orchestrated that make them more amenable to orchestration?
Eric Olden 00:16:05 I think if I were looking for an identity provider that is going to serve me the best, the one thing I would look for Giovanni more than anything is standards support. Because it is the lack of standards based integration that’s caused so much of the headache. And so the standards, most of them all are supported nowadays, but the things that I’d be looking for are, does this provide SAML capability to do federated single sign-on? Does this identity provider use open ID connect? Does this identity provider support passkeys in FIDO2? If the answer is yes, then that’s a lot easier to deploy and to switch because everything’s based on standards. It’s really, I think when people are dealing with old and new, that’s where a lot of the challenges because when we were building these applications 10 years ago, I mean SAML has been around for 20 plus years now, but in the very beginning it existed but it wasn’t widely deployed.
Eric Olden 00:17:15 And so it meant that people were using what they had and that means cookies and proprietary authentication systems and sessions. And the only way you could pass data from the IDP into the app would be through HTTP headers. So you have to think about how do you bridge that old world with the new and when you do it in modern time, you’d be able to use like SAML is really well defined standard and it handles all of the attributes and claims in a very secure way. So OpenID Connect, very similar derivative in a sense, works really well. You mentioned APIs and I think of the other key thing, not the first, but maybe the second or the third would be the API availability and modern ones today support restful interfaces more than the old days there was a lot of soap and that just was a lot more overhead to do this very simple thing.
Eric Olden 00:18:23 You had to do a lot of complex stuff. So look for restful interfaces that are also standards based. So what I mean in that example would be there’s a standard for managing identity data called SCIM – Simple Cloud Identity Management is the acronym and that works with rest. And so I think look for a standard, look for modern implementation and you’ll be in really good shape if you don’t, maybe you inherited something that predated that availability, then use orchestration and that’ll get you to where you need to be. It’ll basically bring standards to the legacy stuff and I think that’s really helpful.
Giovanni Asproni 00:19:06 How does this work? In the case of systems actually and also not so old systems, also some being created now where people actually create their own identity management specific for the system. You know, they create a login, password, their roles and everything, which usually lives in the same database as the rest of the data. So if you have systems like this to bring them under an identity orchestration umbrella, what do we need to do? Is there are some development work necessary there?
Eric Olden 00:19:37 Yeah, so very often people have to build their own and it usually starts like, oh it’s no big deal. We’re building a trading application and someone has to handle the user table. And so they say, okay, let’s just put a table in there and put our users in there and let’s give ’em passwords because we want to focus on the trading application. That’s really interesting. So they wind up rolling their own and it generally doesn’t have all of the capabilities that you would get from a third party. So I think one thing to do would be stop doing that because you’re not really saving all that much and you’re building a lot of technical debt that gets really expensive to replace. And so I think Auth0 has done a lot for developers who just wanna solve that login problem but don’t wanna spend much time doing it.
Eric Olden 00:20:32 You can get all the great capabilities from these identity as a service companies. Auth0 is a good one. There are others as well that are developer focused and new startups that are coming out. But let’s say that the ship has already sailed and we’ve gotta work with that embedded user table, then what I think one of the most important things would be to get rid of the dependence on the password. And the reason that is so important is that close to 90% of security breaches that lead to whether it’s ransomware or other kind of privacy laws come from a phishing attack that compromised a password. And there’s a whole host of reasons why that is so weak in terms of protection. But suffice to say that we want to replace that where we can with something that is more robust, like a multi-factor authentication like the QR codes or the authenticator apps.
Eric Olden 00:21:32 So when you’ve got that situation, what you can do is use the abstraction layer to basically deploy software so that the multi-factor authentication is what the user experiences. They go through, they’re redirected to an authentication process that says something like, check the authenticator app on your phone or look at this QR code or use your passkey that’s built into your, your laptop, right? So there’s any number of ways that you do that. So that is the secure thing. Now we need to link that trusted session with this legacy user table, right? And so at that point what we want to do is look at that user ID in that user table and we can ignore the password for a moment. So you look at the user ID and you map that to the user ID that is used for the multifactor authentication and at that point you can pass that session from the authentication flow into the application using the user ID as the common link between the two.
Eric Olden 00:22:41 And so you can ignore the password because the way that you deploy the orchestration software is in the same memory space as the application. So there’s no way for someone to get in there and to put in a fake authentication saying, oh I really did pass authentication. There’s no way to do that because of encryption and trust and a lot of the gory details that you don’t have to worry about if you’re using the orchestration layer because all of that is built into it. Sso the facade handles all of that.
Giovanni Asproni 00:23:15 This also means that there may be the need for some development effort of some sorts to be able to link the orchestration with this old ad hoc mechanism.
Eric Olden 00:23:26 Generally not when you use orchestration software, right? Because that software has the ability to do the mapping and the account linking and so it is kind of built into that layer. Now if you didn’t have orchestration software and you wanted to do that on your own, absolutely.
Giovanni Asproni 00:23:43 You’re right. Yeah, I’m talking about having orchestration software in this case. Okay.
Eric Olden 00:23:46 Yeah. Using software helps you avoid custom code.
Giovanni Asproni 00:23:50 Okay. And now something slightly different. So how does identity orchestration affect the user experience?
Eric Olden 00:23:56 Well, in the best of cases, the end user doesn’t know that this is happening at all. It’s the same experience before and after the deployment because the orchestration software is transparent, you drop it in front of your application, it works as a proxy or as an identity service provider kind of interface. So the end user, they go to the same place that they log in and let’s say originally they use a password, they go to a portal log in, all of that is unchanged. What’s happening under the covers or behind the scenes is that the orchestration software is saying, okay, I’m not gonna go to the old system. I’m gonna go to the new system to authenticate this user and to get attributes and check permissions and all of that. So transparent to the end user. And on the other hand, if you are changing the authentication experience because you want to bring in something like passwordless authentication, now you need to roll that experience out in a very thoughtful way because if a user who’s used to logging in seeing a username and password all of a sudden has a different experience, we’ve been training our users about hey, if the login page changes, you’re getting phished and don’t put your information in there.
Eric Olden 00:25:21 And so you get into the situation where you wanna be mindful on how to roll that out. And so I think there’s a couple of ways that you want to communicate a change like strong authentication or two factor authentication is coming to our application, tell people it’s coming so they know when they log in that at some point they’ll be given that option. And then you wanna give them the ability to do both, use your user ID and password or you can use your passwordless token. And over time they start to see those two and then they go, well maybe they need to, I don’t know, just take a chance and try this new two-factor thing and now all of a sudden they can start to use that one moving forward. So I think it’s just getting around that conditioning of how you treat the end user. With employees, it’s easier ‘because you can force it with customers, it’s a little bit more, you want to incent them. So say for instance, tired of forgetting your password now just use your phone and it’s more secure and more convenient. So you can incent people to try the more secure mechanism. But it is something you want to be very mindful of because you can get people, especially customers to say, ah, I’m confused. I’m not gonna log in to this bank application because I don’t want to lose my money. And I understand that. But if you educate people, I think there’s a lot you can do to get them used to it.
Giovanni Asproni 00:26:55 Okay. What about the case where we are integrating, say a system that already has multifactor authentication but you have more than one, you have 2, 3, 4 because of a merger and acquisition or something and then you end up with systems that pretty much do the same thing but maybe slightly different ways?
Eric Olden 00:27:15 Yeah, that’s a very common problem Giovanni. And it happens because human nature. I’ll give a great example. We are all passwordless at my company, we don’t have any passwords. All of our applications use two-factor authentication. And so for instance, and I fly a lot, so if I’m on a plane and I need to access something, I need to have a fallback authentication mechanism in the event that I can’t use a network based one, right? And so I don’t have my keys right here, but I have a FIDO token on my keychain. Normally I like to use the authenticator app that will go talk to the cloud and say hey, here’s a code that changes over time. And that’s really easy, especially if I have my phone, which is generally all the time, but then I’m on an airplane, I can’t get to the network. So it would be, you know, really useful if we can fall back to another multifactor authentication mechanism like my token that I plug into my laptop. What you don’t want to do is say, oh I can’t find my strong authentication system, so I’ll use my password.
Giovanni Asproni 00:28:37 Go right of the authentication system in the first.
Eric Olden 00:28:40 So you can’t do that. It’s like locking your convertible but having the top down doesn’t make any sense, right? But orchestration in that situation can be the capability of the OR. Use this mechanism OR this other one where both of these are strong authentication mechanisms. One could be an app, the other one could be a hardware token. But that is really important because people forget things, people go on airplanes. And so when you’re thinking about how do we make sure that we have multiple ways that are still secure for a user to authenticate, that’s where orchestration can really help you in addition to the merger and acquisition use case that you talked about.
Giovanni Asproni 00:29:21 So you end up with a situation where instead of having the situation say, we have redundancy and it is a mess, you end up say, luckily we have redundancy. So we actually have a way of avoiding disasters in case things happen.
Eric Olden 00:29:36 That’s exactly right.
Giovanni Asproni 00:29:37 So you can actually exploit that as an advantage.
Eric Olden 00:29:40 Yes, you’re right. multiple is helpful in some cases.
Giovanni Asproni 00:29:46 Are there any differences in how orchestration works in the case of services instead of humans? You know, when we have any kind of services connected to the network that in some level of authentication authorization because of the way they’re done. Is there any impact?
Eric Olden 00:30:03 Yes, there is. I think when you’re talking about a service account or API, someone was joking saying APIs are people too, I don’t know if I say that, but , they have entities behind that, right? It’s a user who’s accessing an application that makes a transaction on that user’s behalf. So what you have in that situation is a need for continuity of the user identity from the browser through to the backend hitting an API that could be wherever and making sure that you can’t do something at the API level that you couldn’t do at the browser level for instance. And so being able to have a way to basically move from the browser, have that session that then can be handed to the API layer, that’s a capability that the orchestration layer can do. So that way you keep the consistency of the entity even as it moves from a browser to an API call.
Eric Olden 00:31:05 Another common thing is, well what about just the API that’s doing server to server request and at that point the orchestration layer acts as a proxy and enforces the authentication and authorization at the API layer. And so even without having a browser involved, you can still have the orchestration layer intercept, basically the API calls and apply logic like authentication when you’re dealing with server to server, hopefully you’re not using passwords because that’s really bad security, but certificates are a lot more common when you’re dealing with backend entities, systems to system. And so at that point, instead of using end user authentication, you’re gonna be relying on certificates. You could have some API keys, but that’s just another word for a password. And so I recommend people avoid that anywhere, whether you call it a password or an API key and instead use certificates and that still applies in this world.
Giovanni Asproni 00:32:13 What would you do if you find the situation where you have used a password for a service account, because I’ve seen systems in the past where basically service to service but still you needed to create a user for a service. A service is a person, two kinds of things seems to be. So username and parcel. So I would expect some of those systems to be still out there. Maybe not the most modern ones, but as we know, systems tend to live long lives if they’re useful. So in those situations, how does orchestration affect service to service interaction?
Eric Olden 00:32:47 So I think in those cases, if I came into an environment and they had a lot of legacy poorly architected because they’re using passwords, one of the first things I would do is to replace the on file system for the password with something like a vault and a key vault, a secrets manager that’s less about orchestration, it’s just more about how you store secure secrets and technologies. All of the cloud platforms have ’em, you know, key management systems on Azure, HashiCorp makes a really strong offering there. So I guess the reason I would start there is that you could, without changing a lot of the relying application, handle those sensitive data in a more secure way. So that would be the triage approach would be let’s get this to be better than vulnerable as putting it on the file system or in some database or some user table. When you talk about orchestration, I think that also is a place where orchestration software can talk with those secrets managers and get those credentials for the service to service authentication. And so that’s the second step, right? Put the vault in place, secrets manager and then you get the orchestration to use that as well and then you can extrapolate and go take those credentials and use them further afield. But you’ve gotta get rid of the vulnerability as much as you can where it’s most susceptible in the file system.
Giovanni Asproni 00:34:23 I know something different about identity lifecycle management. So when we put a identity orchestration system in place, how do we manage the lifecycle of the identity, you know, adding things like onboarding, offboarding employees?
Eric Olden 00:34:40 So I think the way the use case you’re bringing up illustrates the dichotomy in identity, which is on one hand you have runtime systems, so when someone is logging in, how do you authenticate them? If they’re clicking on something, how do you verify access and so forth. And all of that’s done at runtime. The other side of the dichotomy is in the administration side, if you go back to the five A’s that’s I think number five and in the administrative side that happens out of band. So typically a user will sign up or you’ll do a batch process and move a bunch of user accounts and do things like that. So those administrative side and the runtime side are decoupled by and large. And so you can use orchestration in both worlds, but you’re gonna be doing it in different ways. So runtime identity orchestration is going to handle the five a’s that happen as people are using things.
Eric Olden 00:35:43 And then on the governance or the administrative side, you’re gonna be using the automation capabilities of orchestration. So for instance, you may have a situation where we’re onboarding a new user and here’s where these two things come together. So we have a fictional bank and the bank needs to verify information about the user so that the person can create a fraudulent account and that may involve checking a driver’s license in addition to some other information. And so you have this multi-step process or a user journey to sign up and get a new account. And we want to do this so that the user gets access to the account and to become a customer. So we don’t want them to do it and then three days later have to come back and say, hey, your account is ready. We need to do this in near real time or just in time, the JIT approach.
Eric Olden 00:36:42 So what you could do is use orchestration to combine that user experience. They come in, they have a progressive profiling, a little bit of information, tell us your username, tell us what company you’re a part of, tell us what state you live in or country you live in. And then as we start to get that information that goes into the orchestration decision tree. And so for instance, based on that information that we collected, the first step we may say, you’re a European customer so therefore I’m going to have you provide a valid European driver’s license or a whatever’s appropriate, take a picture of that, upload it, and then the orchestration software will take that image and then send it to an identity verification service as an example. Wait to see if that checks out. And let’s say that it does, then the orchestration system will get a response back from the verification system saying yes, this is Eric and I can say that that worked.
Eric Olden 00:37:49 So the third step now is to issue a credential so that this new customer never gets a password in the first place. So at that point we may in step three enroll the user in a multifactor passwordless credential. So for instance, hey take a picture of this QR code and then do something on your phone and we’ll link that all together with this one transaction. So at the end of this three step flow, now the user has an account, they have been verified for compliance purposes for know your customer and they have a passwordless authentication credential issued to them all in a very seamless transparent thing that should take maybe two or three minutes. And that is an example of where we’re doing administration tasks at runtime, but being able to do them in a very specific sequence and orchestrated sequence, that’s an example of kind of runtime meets administrative. So you can do it all in a seamless way.
Giovanni Asproni 00:39:01 Okay. So the automation aspects actually help in taking care of what the values identity management systems and their own specific needs because I guess the systems connected to those specific identity management systems need some part of the attributes or the information associated with the user but not the rest.
Eric Olden 00:39:21 That’s right.
Giovanni Asproni 00:39:22 And the orchestration knows where to look for all these bits due to the automation implemented.
Eric Olden 00:39:27 That’s right. And the way we think about those identity services like the authentication system and the identity verification system and some others. So all of these are a company’s identity services and they’re all fragmented. They are provided by different vendors, they run in different places. And so part of what the abstraction layer is doing is creating what we call an identity fabric. So all of your identity systems, they’re aggregated behind a common abstraction layer so that when it comes time to authenticate this user with this identity provider, create an account in this identity provider issue, a credential in this identity provider, the orchestration system is already integrated with all of those identity providers. So they can do the crud functions, the change, read, update, delete on those identity providers through this orchestration layer. So it’s a really kind of powerful notion to combine the abstraction layer with all of these infrastructure components it’s integrated with and deliver it at runtime.
Giovanni Asproni 00:40:37 Okay. So now I was thinking a couple of questions. So one is the automation here when we refer to automation in the context of identity orchestration. It is mainly about the administration bits, I would imagine also some of the other ways as well depending on how you have to deal with the various APIs and things. But I guess the administration part is a big chunk of it.
Eric Olden 00:41:00 Yeah, absolutely. And the typical use cases in user identity are creating new users and deleting users. So onboarding and offboarding, those are very essential. That’s like the main two scenarios and how you onboard a user, there’s various steps and often you have more than one system that needs to be managed. So that kind of orchestrating multi-step user journeys is really part of both the onboarding and the offboarding scenarios.
Giovanni Asproni 00:41:34 Yeah, because I can imagine that is where you really need a lot of automation if you have disparate systems to somehow synchronize to an extent to each other. I have a question related to security here. Now, am I correct in thinking that having this orchestration layer that deals with different identity systems might actually help segregate information about the users? I mean, I don’t if I’m right or wrong, so you correct me if I’m wrong, but I’ve got in my head that if we had a single identity provider for a disparate set set of systems, each of them with its own specific needs and requirements for the data they need, this seems to be a big kind of a central point where pretty much everything about the user is collected potentially a security risk in a way or a privacy risk as well. But if we are orchestrating different identity providers, each of them connected to some systems, this somehow might actually help in segregating bits of information for the user in a way that makes it less likely to abuse, privacy or security. Am I correct in thinking this?
Eric Olden 00:42:45 Yeah, absolutely Giovanni, and I think here’s a thing that a lot of developers are surprised to find out is that even if you’re working with a company that thinks of themself as, for instance, an American company, there are a lot of potential European customers that come into this application and an American company is subject to the European privacy directive, right? And so now all of a sudden people in America think, well why do I care about European privacy directive? Like we’re run this in United States, I’m a American company. Well, it’s because of the notion of cross border access. And so when you think about this, it can be very expensive from a fine standpoint. I think the EU privacy, I just read this week about a social media company that had gotten a $370 million fine because they didn’t keep the European data in Europe and instead it went to America and then to China reportedly.
Eric Olden 00:44:02 So what do you do in that situation? Well, what you could do with orchestration is say, look, we have users that are European users, we’re gonna hold them in an identity provider that’s entirely based in Europe and not in America. And then American identities will be stored in the US. We’ll keep it simple, just those two places. So now that could be two different vendors, it could be the same vendor, but now you’ve got two identity providers that you want to access the same application but maintain respect for the geography where those user and the data privacies rules apply. And so orchestration would allow you to link those two at runtime and not make you move and replicate data of European users into America and vice versa. So you keep it partitioned, that’s gonna save you a lot in overhead because of these European privacy directives. GDPR is a whole lot of reasons why that can become a problem very quickly. But orchestration allows you to choose what you want and use what you have wherever it runs. And so you can kind of have your cake and eat it at the same time.
Giovanni Asproni 00:45:19 And I guess this is possible because there is no need for the orchestration system to actually say that I have some systems for the, my orchestration deployed in the cloud somewhere in Europe. But to read data from the US is, well, the orchestration can simply ask questions about the user of things, receive back response. There is no need to use data in transit. And so kind of read the data from the US and bring it to Europe. Where the cables are potentially causing all sorts of privacy issues or maybe legal issues.
Eric Olden 00:45:55 Exactly. And I think the main thing is that the orchestration layer does not persist. It is not an identity provider itself. It’s like in virtualization there’s the hypervisor and that runs on something else. It’s not the server. It looks like the server, but it’s not the server, right? It’s a facade of the server itself. And what we do with orchestration is similar in that we’re not persisting the user record from Europe in America. Because that’s why the storage of data is a lot of the problem, right? If you’re replicating user data or someone says, Hey, I don’t want to have all of my citizens’ data in a potentially foreign world. So that’s where we number one, never persist that data. And then the other part is that you can ensure encryption in motion and through that transaction all the way through so that when that user is coming, we can tokenize that user’s data.
Eric Olden 00:47:00 We don’t have to use the data itself. And so a lot of ways to keep that information from moving from one geography to the other and orchestration is right in the middle making all of that happen. It’s the connective tissue designed to do that very thing. And we’ve got a lot of our customers are multinational and they have run into this all the time. And it’s really interesting how some of them have even used the same vendor but have multiple instances where they’ve got the European instance of Okta and the American instance of Okta. They can’t have the identities even though it’s the same identity system, they have to be in different places. And they use orchestration to say, sure, you will be able to link these, deliver that user into an application, but not violate the data sovereignty that is needed in that example.
Giovanni Asproni 00:47:56 Okay. And now a question about another A, the auditing. So when you put 10 orchestration systems in place, what happens to the auditing abilities? Because we had several identity providers, maybe each of those providing their own auditing mechanisms. What happens when you put orchestration in place?
Eric Olden 00:48:16 Auditing gets a whole lot better. So the first thing is it’s non-destructive, meaning all the auditing of the change logs and things like that that exist before you deploy orchestration, those don’t go away, right? All of those things continue to run the way that they always have. Now when you bring an orchestration, you’ve got another layer where you can add more context and this layer is gonna show you the activity across identity providers. So it also means that you can see application access across different clouds. So why is that important? It’s because you’ve got more of a single pane of glass now that you can look at all of these different systems and see how the information of the transaction could start on one cloud and end up on the other. And you can have continuity of which user account was used even though it went to multiple identity systems in multiple clouds.
Eric Olden 00:49:21 So auditing gets a whole lot better. I think there’s a really interesting opportunity for having a single view of all of your user access across your clouds and between your cloud and on-premises environments. And that’s what you get with orchestration because it creates a whole new layer of how you can manage all of these different systems, put it all into one place. And that breaks a lot of the problems of fragmentation that have been an issue where, I see what’s happening in this cloud, I see what’s happening with this system, but I can’t see the forest because of all these trees. Where orchestration allows you to see is both the forest and the trees because it is managing all of it.
Giovanni Asproni 00:50:10 When we put identity orchestration in place, aren’t we creating a bit more complexity in the system? I mean we are putting more services on top of what was already there.
Eric Olden 00:50:21 I think there’s a good parallel between virtualization and orchestration. So it’s true, right? You’re adding software. And so now we’ve got a new thing, orchestration, that we need to manage, but what it is itself is a management system. And so similar to the concerns that people had with virtualization saying, well, you know, we have all of these servers that we need to manage and if we put ’em onto a hypervisor, we still have to manage those servers and the hypervisor. But what we found was that the hypervisor is the place to do all of the management. And so you actually have a built in way to make things consistent. And that’s similar to what we’re doing with identity orchestration is we don’t replace the identity providers. We create a new way to link them all together. And by doing that, we make it consistent. For instance, policy can be made consistent across these different fragmented systems using policy orchestration.
Eric Olden 00:51:27 And we help build a standard for that called IDQL. And that’s a way to use software for free, by the way, it’s all open source. You can get the cloud native computing foundation. It’s not a sales pitch, it’s just like a developer tool for those who want to build cloud native apps. Here’s a way to make your policies and all your clouds work consistent. And you couldn’t do that without orchestration. What you would be doing otherwise is managing it in five different places. And with orchestration you can manage it once and the orchestration then propagates that change wherever it needs to go through. So you can reduce your management significantly by putting in a new piece of management software, the abstraction layer.
Giovanni Asproni 00:52:10 Okay, let’s move to implementation. Just to have an idea of the work involved. Let’s put things this way. So first of all, what are the typical components of an identity orchestration solution? So we have been talking in the abstract identity orchestration, but in practice, what is it when we have to deploy something, what we get to deploy or or to integrate?
Eric Olden 00:52:30 So our approach to it, I could share that. I think there’s, there’s other approaches that people have taken, but the one that we found after building these kind of systems for, you know, exascale cloud platforms that, like we did at Oracle to the biggest enterprises in various companies, was to decouple the control plane and the management plane. And when I say that is the control plane is where you set your rules and your policies. And so these are the things that define how you authenticate, define what access control and so forth. And then on the runtime side of the enforcement identity plane, depending on what terminology you want to use, we think of it as the identity enforcement plane. That’s what happens at runtime. So the management structure in our approach is to use the cloud to configure your rules and then use a piece of new kind of software called an orchestrator that runs in various distributed places close to your applications.
Eric Olden 00:53:40 And this orchestrator is a multifunctional thing. It will act as a proxy, but it does more than proxy. It can act as a translation layer for, uh, translating different protocols into other protocols. For instance, changing an SAML protocol into an open ID connect protocol, right? So it’s a translation server, if you will. You can act as a service provider like Open ID or a SAML SP, so it’s this multifunctional piece of software, but the simplest way to think of it is a proxy. And you can put this in proximity to your application so that any traffic going into the application has to go through the orchestrator. Once that traffic comes through the orchestrator, it looks at the policy that it was given from the cloud, the control plane. And so it can read it without having to call home. That’s the key thing. Distributed architecture is you don’t want them all calling home because you lose the benefit of spreading things around.
Giovanni Asproni 00:54:48 And in this way with a control plane, you can also change the way the orchestrators work without having to shut down the system or restart anything basically. So it’s a dynamic thing. So you can change policies or whatever you need to change without too much effort.
Eric Olden 00:55:06 That’s right. You change your policy and you publish that policy and through the distributed architecture, that policy finds its way to all of the orchestrators that use that. And there’s an air gap between the orchestrator and the control plane. That’s important because if you’re having to call home for every decision, that’s not a distributed system, that’s a centralized system. And you wouldn’t be able to call home on a cruise ship.
Giovanni Asproni 00:55:35 So the orchestrator is a piece of software that is actually installed on the customer side, say be it in the cloud or on premises.
Eric Olden 00:55:45 Yeah, the orchestrators are distributed. In our world, the software that we’ve built, they’re very high performance and they’re very small. So you can run them on a cell phone. The whole distribution is not even 50 megabytes. So it’s really intended to be very high performance. You run them in a series if you use Kubernetes. So you never have a single point of failure and you can push them into these new form factors. I won’t say this for sure, but don’t be surprised if you see orchestrators in automobiles because cars are becoming even smarter. And another situation where you don’t want to have to call home to a network to see if you’re going to allow someone to have a local service to a music service or something like that. So if you have the right architecture, you can push a very small enforcement component out to all these millions of cars, to the 5G network towers to mobile phones even. So it’s all intended to solve identity in these highly distributed multi-cloud worlds. And you have to do it securely and you have to make sure that the performance and latency don’t become issues. And that’s why we took the air gap approach in our case.
Giovanni Asproni 00:57:02 How long does it take typically for a company to implement an identity orchestration solution?
Eric Olden 00:57:07 Our record is less than 10 minutes to use our cloud service to get up and running and to protect a real live application. So we can do that using one identity provider and one application, start from zero and you can be up and running in 10 minutes. That’s our record. When you look at a big enterprise, their mindset is, well we want to think how do we do this for five identity providers and 200 applications? And so in that world, we call, our approach anyways is called live in five, which means five days. And then you’re production ready. So typically in the beginning you’re going to say, let’s plan our deployment. What identity systems are we going to integrate with and what applications are we going to secure? The integration is plug and play. It’s all visual, it’s all you choose basically out of the fabric options, what you use. And so that’s like a click operation. And then on the applications, what you need to do is provide basically four fields. What is the URL when people log in, what is the URL when they log out? What’s an error page? And are there any areas in the web application you want to treat differently from a policy standpoint like a dashboard versus login?
Giovanni Asproni 00:58:31 It’s pretty quick. Now a last question about emerging trends or technologies. You know, in the field of identity orchestration, what is happening? Are there emerging trends, directions, things, exciting things that are happening or going to happen at some point?
Eric Olden 00:58:48 There’s a lot of really interesting things that are happening. I think the biggest is that people are understanding that identity orchestration is possible. When we first started this company in 2019, people said, there’s no way you could do that. That’s not possible. And we’d have to just let them use the software and say, well you’re and all these other customers are doing it. So it exists, it works. But that was a lot of convincing that we had to do in every individual case. Now I think what’s happened is that we’ve been able to make the software all self-service so people can just try it on their own. So that nice ability to give developers their own control over things, instead of having to talk to a company, they can go do it themselves. We think that’s really interesting, the whole self-service notion. And then I think the broader thing that I’m excited about over the next couple years is using the capability of the orchestration data, all of that audit data we were talking about earlier, to aggregate that all in a common data lake.
Eric Olden 00:59:58 And what would you wanna do with that? You’d want to train it to do some AI. And I know everyone’s talking about AI, we’ve been very pragmatic in how we’re thinking about it because for us it’s a way to take our automation to the next level. We want to train it on what we do that no one else does. And that’s to deal with this data that comes out of these fabrics that we create. And so I think in the not too distant future, you’ll be able to have an AI powered copilot to watch what’s happening across your orchestration world. All of these different clouds, all of these different applications, see when something weird is happening and do something about it automatically using orchestration. So we are kind of merging or converging the sensor and the enforcement and the integration all in one platform. And I think that’s gonna be the future because the reality is, Giovanni, you know this, the bad guys are using AI and they’re trying to get in.
Eric Olden 01:01:02 And so we are looking at how they’re using it and most of what we’re seeing right now is they’re using it to write better phishing emails. So we really are trying to encourage our customers, get rid of passwords. If there’s anything I could leave your audience with is come up with a password elimination plan as soon as you can. Because if you don’t, these bad actors are using Hey chat GPT, write a really convincing phishing email. I think they probably won’t write it in those exact words, but you get the idea, right? And all of a sudden we’ve got all sorts of new attacks that are coming in, we have got to get ahead of it. So being able to, to do something about it, detect it, and mitigate it, that’s really where I’m excited with orchestration.
Giovanni Asproni 01:01:52 Okay, thank you Eric. I think we did a quite a good job in introducing identity orchestration. I certainly learned a lot during this interview. How can people get in touch with you to find out more?
Eric Olden 01:02:04 Well, we have our websites. Probably the best place to go is strata.io
Giovanni Asproni 01:02:13 We’ll put that in the interview links.
Eric Olden 01:02:14 Yeah, that’d be great. And then the other place would be the Cloud Native Computing Foundation for the standards around identity QL. I think that’s the other place I would point your audience. cncf.org. Look for IDQL.
Giovanni Asproni 01:02:30 We’ll add all those links to the interview page.
Eric Olden 01:02:33 Wonderful.
Giovanni Asproni 01:02:34 Thank you for coming to the interview, Eric. It’s been a real pleasure. And this is Giovanni Asproni for Software Engineering Radio. Thank you for listening.
[End of Audio]
