Identity Orchestration in Multi-Cloud Environments

Multi-cloud and how to deal with multiple identity systems

Jim: So, we’re here today to talk about identity in the multi-cloud environment. Now, for those of you who have already seen it and those of you who haven’t, a while back we did a session on identity in general and how it pertains to the cloud with Diana [Volere] from Netflix. If you haven’t seen it, please go back and watch it. There’s a lot of education in there. But today we’re going to be taking a completely different tack to the same problem. And so Eric, why don’t you really just start us off with what is the problem we have today.

Eric: Yeah, absolutely. So, I think the problem is that so many people now are moving workloads to the cloud.

The reality is that they’re using more than one cloud, and when they move, say from the private cloud on-premises, the classic data center, even when you go to one public cloud, whether it’s Amazon or Azure or anything else, now you’ve got two clouds to manage. So that becomes a multi-cloud problem. What we see a lot of organizations are doing is not stopping with one public cloud, but they’re using two, three, four different public clouds, and they have their private cloud.

The problem has really developed into multi-cloud at scale, where people are struggling now with how to make identity work when their applications and workloads are running in two, three, four, five different places and they’ve got two, three, four, five different identity systems to make work together. So put together, I think that’s the new era of multi-cloud and hybrid.

Jim: So, one of the things that I hear a lot of people talking about when we talk about multi-cloud is the concept of managing different identity stores in each cloud, right? We know that the way that Microsoft does it is completely different than the way that AWS does it, right? The concept of roles doesn’t even really exist in one versus the other.

So how do we start dealing with this identity in multi environments and orchestrating this amongst all these different environments? I’ll give you a real-world example. I’m Jim in one environment; I’m James in another. How do we deal with that?

Identity orchestration used to be based on “OR,” but today it’s “AND”

Eric: Yeah. There’s a lot of complexity, and I think when you net it out, we’re moving from a world where people used to think about “or,” and what I mean is, am I going to use Microsoft or Okta?

And today you have to think about as “and” because if you’re using these different clouds, it’s how do I use Microsoft and Okta and Oracle and all of these other systems. So, fundamentally it’s making that shift from a few to multiple or many. And to your question about where an identity of one individual is represented in more than one place, a lot of times the namespace gets conflated and fragmented.

And the way that you can resolve that namespace is through a notion of identity orchestration that, for instance, creates an abstraction layer that allows you to do a mapping. To say the user canonically is represented in system A as Jim and in system B as James, and you create a mapping at the identity orchestration layer that says it doesn’t matter if we’re querying directory one or directory two. We have a way to reconcile that Jim is in one and James is how he’s known in the other, you have this mapping capability, and it seems like a simple thing, but implementing that without an abstraction layer, without identity orchestration is really challenging. So, I think that’s one of the motivators that people are trying to find a new way to solve that it doesn’t have a lot of work involved.

What is identity abstraction?

Jim: Now, if I look back, I mean I’ve been, it sounds similar, and maybe I’m wrong, but isn’t that what I’ve done with LDAP proxies? And there’s lots of vendors that have made their living off of the concept that I have a bunch of different LDAPS —and yes, we will define what an LDAP is, and we have all these different LDAPs, and I use an LDAP proxy and consolidate them all into one, which is my master now identity provider. How does that differ than what you’re talking about? And maybe you can explain what an LDAP is and then explain the difference between what an LDAP and an LDAP proxy is to what you are talking about. Isn’t that what we’ve been doing for the last 20 years?

Eric: So, I think what you’re referring to when you talk about proxies and virtual directories is another name for an LDAP proxy. LDAP being the Lightweight Directory Access Protocol, which is the way that you speak to a directory. It’s like an HTTP server is just the protocol, the Hypertext Transport Protocol on a web server.

So, when people think collectively about directories, think about that as a database of users. Orchestration and a virtual directory can accomplish some of the same use cases for sure. Meaning if what you’re talking about with that initial example of namespace mapping, could you have done that with a virtual directory? Absolutely. Identity orchestration does more than that because when you start to think about abstraction, it’s much more than simply mapping the namespace. But also includes abstracting things like the representation of a role or a group and making that consistent across different technologies.

So, as we start to extract all of the differences, you wind up with a common layer, which is the orchestration layer. And then once you have that layer, then there’s all sorts of automation that you can do, that you can’t do in classic virtual directories. Virtual directories are fine — I think there’s a place for them, and they’re not going to disappear overnight. But one of the limitations is that it’s really hard to get all of those systems to reconcile.

And so within the virtual directory world, there’s different ways to do it. A meta-directory was an early approach to create just one massive or meta-repository for all of your users, but that breaks down as well as with virtual directories they break down with change and with scale. And so, orchestration was created as a new approach that would solve a lot of those namespace and consistency issues and give you the ability to do more things like automation.

And the kind of use cases I’m talking about from an automation standpoint could be things like deploying passwordless authentication to an application without rewriting the application. Something a virtual directory wouldn’t know what to do with because it doesn’t see the traffic. But an orchestration approach would see that user traffic at runtime. And then orchestration means that you would, for instance, send that user to different steps along the way as they’re trying to access an application.

And when you think about those steps, they may be things like authenticate with a multifactor authentication system. Or maybe it’s, we’re doing a multi-step user registration, and we want to do a fraud check and we want to do a social identity onboarding. So, a lot of different use cases that orchestration was created to automate, that I think really creates a different category than the classic virtual directories or the meta-directories.

Different cloud providers have different definitions of roles. How do you manage that?

Jim: Okay. You brought up several things that I wrote down some notes that I want to bring up. The first thing you brought up is roles. Now, what’s really interesting is that let’s bring up the concept AWS has a complete concept of what roles are, right? And so I could, in theory, use an AWS infrastructure and orchestrate that as my role, authoritative source, whatever or however I want to do it. But when I get into, say for example, Azure doesn’t really have a concept of roles. How does this play into supporting a single authoritative source for roles? Did I get that right?

Eric: Yes, you did. And I think going into the semantics of roles versus groups I think is part of this situation. And a role is a specialized type of group of users that all share a common responsibility and authority, and a group is another way to do that. But often groups also bring together resources like applications and data so you can manage it and do that at scale. So roles and groups are similar, but different. And the vendors that you mentioned whether you’re dealing with roles within Amazon or groups within Azure, they’re doing some very similar things.

And so to get to that consistent application of scalable administration, that’s where you can use an orchestration layer to say, look, in the case of Amazon, we’ll look to see if a user is a member of a role, and if they are, we will allow these permissions. And in the case of Azure, we may look for if they have a role or a group membership, here’s what we’re going to do. The abstraction layer, the orchestration layer, that’s where you’re going to have that mapping. Roles here, groups and roles here. And when we create a policy that sits above those two identity providers, that’s a place where you have an opportunity to reconcile those two similar but different systems and approaches.

In the end, it’s all in service of making the management of access and permissions more scalable. So, I think there’s a lot more in common than is different.

Jim: Yeah. I like that. I always talk about, when I talk about groups versus roles, if you think about it as a job, right? You’re a member of a group. I’m a member of, I don’t know, architecture team, but within the architecture team, we all have our own roles within the group. So as a group, we all get rights to X, but each individual has some more granular, finite roles, and that’s where everybody becomes a snowflake. And then identity snowflakes are scary because that means no two snowflakes are alike. So it’s not uncommon sometimes when you get crazy, you could have actually more roles than people. Please don’t do that folks — don’t go that route. Groups are great and if you can manage it through groups, even better. When you get into individual roles that can get issues.

The other thing you brought up, is you brought up MFA. We need to talk about multifactor authentication. And you brought up the idea of using an Okta or a Ping or an RSA or, who else am I missing? Duo. We gotta give everybody equal credit. All right. But the idea is, huh?

Eric: HYPR is a good one.

MFA redundancy in hybrid-cloud environments

Jim: Yeah. So, the reality is we have a lot of identity providers, IDPs out there. And so what I want to go with is, how do I consolidate or reconcile the fact that I may have a MFA brand A for this cloud MFA brand B for this, and, oh by the way, for on-prem I use MFA brand C. How do I deal with that in this orchestration layer? How do I solve for that?

Eric: Yeah, it’s a tricky challenge and it happens more often than you would think because mergers and acquisitions are a really common place where this happens, right? Where the acquiring company may use vendor A, but they acquire a new company that uses vendor B. And now they’ve got two multi-factor systems to deal with, and we see it all the time. The other place that we see it is when people are modernizing their multi-factor, where they may be going from the classic hardware token to a mobile one-time password or passkeys, for instance.

So, there are a lot of circumstances where you’re going to have this fragmentation. I think some of the use cases that come up that you need to think about is for instance, what if you leave your key, your keys to your car at your office, or you leave your phone in your car and you need to log in. It’s really having redundancy of strong authentication choices. What I mean is hey, I forgot one. What do I have that is an alternative? But you don’t want to go to a password-based system because then that would defeat the whole purpose of the multifactor in the first place. So using a password is not a viable alternative to “I forgot my token in the car,” or something like that.

So, when I’m talking about redundancy on multifactor, it’s with different multifactor authentication systems and to the way that you would solve that. With orchestration, you can give users a choice when they’re authenticating to say, do you want to authenticate with your phone, or do you want to authenticate with your token, or do you want to authenticate with your pass key? Where you can give multiple options that are not password-based.

And in practical implementation, the way you would accomplish that would be to plug those three different providers into the abstraction layer, into the orchestration layer, and then create a policy within orchestration that says, present these three choices to the user and when they log in, and if they have an account in all three, then the orchestration layer will validate that. It’ll point the user to the authentication flow, for instance, with a passkey, and if the user doesn’t have a passkey, then they’ll fail that authentication. Then you can have the orchestration say that didn’t work out, do you want to try your phone token instead? And then have an alternative flow to do that.

So, it’s really that orchestration’s job is to send the user at runtime to different places within the identity environment or the identity fabric. So whether it’s optional in case you lost it or if you’re an employee of the original company, we want you to use this system. If you’re part of the new acquired company, use that system. There’s a lot of end-user choice that gets put into the equation.

Jim: And it sounds like by using orchestration, I may have MFA from both options, both vendors you know, company A, company B, and I can choose which one I want to use because the orchestration abstracts that away from me. And so that’s something that’s really intuitive for companies that are making the transition, companies that are merging companies that are doing this. It gives you the ability to be less finite on your rules that says you have, you’re a company A, you have to use MFA this, or company B, you have to, either one, we can abstract that away and either one will work.

Managing resource access with authorization

Jim: Now the other thing you brought up, since you brought up this mergers and acquisitions and you brought up company and company B, because we see that a lot, is the authoritative source problem, right? If I’m an employee of company A, you’re an employee of company B, but now we work together, but I’m in this HR system, you’re in this HR system. We traditionally have to had to make one authoritative. How do I deal with them? Deal with a multi-authoritative source, because I actually now may be in both. How do I deal with that?

Eric: Yeah, the way that you deal with it with orchestration is to plug both systems into the abstraction layer, and then you create a policy that stipulates which one is authoritative. And the question then from a Boolean standpoint, you may have an OR that gets worked into the policy. And what I mean by that is challenge the user with the default of system A and if that doesn’t work, then we can also accept OR from system B. And that then starts to give that bifurcation that users may need and that guidance when they’re logging in. because they may not even know that, for instance, if it’s the new company that got acquired, they may not know all of the systems and technologies and tools that the acquiring company even has.

So, you have that moment of confusion where they’re like, I don’t know what, I don’t have one of those tokens, so I can use what I do have. Then they’re going to be able to select that as an option when they log in. And that starts to, over time, you tag the user with an indicator to the orchestration layer that, for instance, you can say, “Hey, the next time Eric comes in, I’m not going to show him the option A, because he’s not in organization A. I’m going to send him in B.” So, the second, third, and fourth and so on. All of those go with that selection already made, and that makes it easier over time.

Jim: And it sounds to me like it’s not an OR, It sounds to me like it also could be an AND. Because I may exist in both entities. Let’s say I worked for company A, we acquired company B. They added an identity for me in company B. Now I’m in both, and my roles and my rights are going to be different. So we need to consolidate that and come up with these aggregate permissions across or least rights privilege or whatever the ruling is based upon potential other flags. So I think that’s really cool.

Managing multiple identities for the same person

Jim: I did want to bring up the persona thing, though. Because we log in, we tend to log in with a persona. And if I log in with an admin persona, that’s great if I’m doing admin stuff, but what if I have a mortal persona and a privileged persona. How do we deal with that in this orchestration world?

Eric: Let me ask a clarifying question. Are you talking about human identities versus machine identities?

Jim: Actually, I was talking human first and then I was going to, you knew where I was going to go with it, which is non-carbon-based unit, which is the machine identities.

But let’s start with human. Typically, and in this real world, I have a mortal account I use for day-to-day, and then I have a privileged account, which I use for admin-related stuffs. In this orchestration world where I live in all different clouds, that becomes even more muddy.

Eric: Yeah. So, on that human side of it where you have two different personas, I think the way to approach that is to attach your policy not to the persona but attach it to the resource. What I mean by that is, for instance, if you’re in your world of the “mortal,” like your day-to-day user, the generic non-privileged user, when that person comes into access the common applications that you’re thinking about, then the policy is actually centered on the application and the data, and it would read something like, to access this application or this data, the user must be authenticated in this way and be a member of this role, or be in this group or have these attributes.

So the policy is centered around the resource. Because when you do it that way, so resource-centric policy, when you do it that way, then when the user needs to come into a privileged infrastructure, for instance, where you don’t want to have a password ever allowed, you can attach a policy to your infrastructure as a service, your IaaS resources that says, require that the user authenticate in this way, have this role membership and this group, and have these attributes. So it’s this very similar pattern, right? So that makes it easy to govern, but it’s very capable of differentiating between the different authentication and authorization types of that end user.

So flip the equation around and attach your policies not to your users, but to your resources. That’s a common way to address that situation where you may have more than one persona accessing different types of applications.

Machine-based identity orchestration

Jim: Now you brought up, I’m going to stay with it, which was the, I always say the “non-carbon-based life form.” I’m a nerd, can’t help it, so that machine-based identity. How are we dealing with machine-based identities in this new orchestration fabric?

Eric: In the same way. What I’m saying is, attach a policy to your resources and those resources in a non-human base, they tend to be service accounts accessing APIs. And you can still have that same kind of policy, but instead of dealing with a carbon-based user, you’re dealing with a machine, an identifier, a process, or something like that. But you can attach rules to that machine, to that process. For instance, only accept connections from these types of groups like these users, and how you can access these different systems based on criteria about the process. So, processes, APIs, servers, networks, and things like that. They all have attributes and can be in a group. Less common to have a role, but groups and attributes tend to be more common when you’re dealing with non-human-based things.

But it’s the same kind of pattern, which means focus on a policy on what it is you’re trying to secure and then create a rule at the orchestration layer that is applied at runtime to your non-human-based life form.

Identity Query Language and Hexa

Jim: All right, so there’s this new IDQL thing. Talk about that. What is it, how does it impact it? What does it have to do with orchestration in the hybrid world?

Eric: Absolutely. So, IDQL stands for Identity Query Language, and it’s a new standard that my company, Strata, has been supporting and spearheading.

Jim: Marketing warning! Marketing warning! Go ahead. No, I’m kidding. I’m kidding. It’s a standard folks. It’s not marketing, but go ahead.

Eric: Yeah, absolutely. And just that we’ve been creating this in a community of practitioners, and, enterprises and vendors, and what we’re trying to do with this standard is to create a consistent representation of policy in different systems.

Why would you want to do that? Let’s look at policy. I think it’s one of the last of the frontiers of things that have yet to be standardized and the consequence of that. Is that you have policies, for instance, in Amazon Web Services, AWS, and you have policies on Azure for Microsoft’s cloud platform.

And these policies, as we were talking about earlier may be in a role format syntax in one case, and they may be using roles in groups in another. But the problem is if you’re trying to do any kind of governance and you want to know how are these rules implemented and how are they enforced and what are they — very difficult because you would need to understand the proprietary design of those systems, and they typically are expressed through a programming interface called an API. And in order to understand what that means, you gotta understand the data model and the syntax and all of that complexity, which people will do, but it makes it very difficult to know that in both places.

Metaphorically, it’s like you’ve got one platform that is developed in English and another one that’s developed in Japanese. They both do what they need to do, but if you need to know how things are done in both places, you need to speak English and Japanese.

So what if there was a way that you didn’t need to know English or Japanese, but you have this even more simplified way to represent policy in a generic way? That’s what IDQL is. It is this generic representation of policy that is able to normalize the same rule in different places. And that means that you can, for instance, if you want to have the same policy for who can access certain applications enforced consistently on two clouds, where you run your applications on two different places, then you can use IDQL to do a couple things.

And there’s an open-source, free, downloadable tool from the Cloud Native Computing Foundation, the CNCF, called Hexa, which is an open-source reference implementation of IDQL. So, you can take this tool and point it at one cloud and say, extract all of the policies that are in there so I know from a discovery standpoint what exists, and translate it from proprietary AWS into generic IDQL.

So that’s great, your auditors will like that because IDQL is human readable, it’s declarative. You don’t need to know an API, you don’t need to understand how anything was done, it’s there in name value pairs. So that’s a big win right there, you understand what’s going on. And if you say, I want to take the policies that are in Amazon and put them into Azure, then you can have Hexa translate it from generic IDQL into proprietary Azure policy, and then orchestrate the policy into Azure to create that same rule set. So that means that you can have one overarching policy that’s implemented consistently in two different target systems. And the reason you’d want to do that is to better understand your access permissions and to have flexibility to move your workloads from one platform to the other without rewriting thousands and thousands of policies.

Jim: That sounds great. All right, one more time. Where do the folks go if they want to read more about Hexa? Where do they go?

Eric: Yeah, just Google “HEXA policy orchestration.” There’s a website on the Cloud Native Computing Foundation, the CNCF, I think it’s cncf.org. It’s where Kubernetes is hosted, where things like OPA, Open Policy Agent, are hosted. And now you can get the Hexa policy orchestration for IDQL, and it’s all free open source. It’s Apache. And we don’t make any money off it. What we’re trying to do is to help the industry move to standards because that, I think, at the end of the day, is the most powerful way for organizations to break vendor lock in and to say, Hey, we’ve got choice now. So take a look, it’s pretty fascinating.

Jim: That’s great. Eric, I want to thank you very much for all the information we gained today. And folks, if you have any questions, feel free to reach out. The contact information will be as part of the podcast if you have questions for me if you have questions for Eric.

Also, if you have any suggestions for future podcast, please give us feedback. 

Eric, once again, thank you for attending today.

Eric: It’s my pleasure. Thanks for having me, Jim.

Jim: Thanks. Bye, everybody.