The building of a new identity standard [webinar transcript]

On demand webinar: “The Building of a New Identity Standard: Why the Multi-Cloud World Needs IDQL and Hexa to Unify Policy.” 

Transcript 

[00:00:00] Mark Callahan: Hi, good morning, everybody. It’s great to have you join us or a good day, wherever you are in the world. We are excited to have you join us today. As we dig into a panel conversation talking about the building of a new identity. There was a lot of work that went into the creation of IDQL Hexa.

And what’s great is we have this handle of working group members joining us today to talk about what happened behind the scenes and what was the need for creating IDQL and Hexa and giving you a little bit of insight into what it takes to create that new standard. A few items of housekeeping that I’d like to take care of first are the fact that all of our attendees.

So that’s all of you in the audience are going to be muted right now. And so don’t worry about that. Second, we would like for you to ask questions at any time, you’ll see a button on your screen to submit those questions. In the interest of time, we have so much to cover today that we’re actually not going to do a live Q and A at the end, but we will be following up with an email with responses to all of your questions.

So please do feel free to submit those throughout our conversation. We’ll have some resources available at the end of this conversation to help point you in the direction of how do you get started with IDQL and Hexa. And then finally, there’ll be a follow-up email for everybody with a recording of today’s webinar.

Now, without further ado, I’d like to introduce myself, I’ll be your host today. I’m Mark Callahan. I’m the senior director of product marketing at Strata identity. And as we look ahead to the panelists that are joining us in this conversation.

I am joined by Eric Olden, who is the CEO and co-founder of Strada Identity. We have Gerry Gebel, who is the head of standards at Strata Identity. Bob Blakley is here with us from as an operating partner from Team8. Neil Danilowicz, who is a principal architect at Versa and a MEF member and editor. Mike Barinek, who’s the lead developer and co-founder of Initial Capacity. And last, but certainly not least, we have Tom Malta who is a global leader and IAM space.

So thank you all for joining us. You’re all been very involved with the working group today and excited to hear a little bit about your perspective and then thinking about perspective. I’d like to actually lead off with a little bit of a lay of the land.

Gerry, would you give us a little bit background on where we are in terms of this multi-cloud world?

[00:02:26] Gerry Gebel: Sure thing, Mark. Yeah. So let’s set a bit of context before we get into the rest of the program in the panel discussion here. So I think it’s pretty well understood these days that most organizations are dealing with a multicloud challenge.

That is when we talk to customers, they have some combination of Google and Microsoft and Amazon, maybe Okta or some, some other others as well. And of course, Within each of these systems and platforms, policies are configured differently. It’s all proprietary for each of those systems. And then that’s further compounded when you think of the north south axis.

So it’s not just about the applications, but the network, the data layer and the platform itself. So in each of those technology areas, you have, again, another array of different policies and different techniques for managing access. And then of course, we still have a fair amount on the legacy. That’s still on premises and hasn’t fully migrated to the cloud.

So it’s a very complex and fragmented environment that we’re dealing with. And that’s where IDQL comes in to be the policy model or format that can be used to orchestrate this very disparate and varied environment. So IDQL is a universal policy format of declarative policy format and that, and it works with the Hexa open source policy orchestration system.

So this is a reference implementation that brings IDQL to life or makes it operational. And the Hexa open source has three main functions. It’s built on a provider framework and we can have providers that connect to these different systems to first do discovery. So when I connect to that, that platform or that environment, I can see what resources and what policies are already defined. Pull them in. And then translate to IDQL. So I can do that for any number of target systems that I’m configured for. And now I can manage all of that access policy in IDQL . I just need to know one format. I can make my changes, make my modifications and send it back out through the translation step and then use orchestration to push that native policy settings back out to those target environments.

So that’s what IDQL and Hexa or all about. And that’s what we’re here to talk about today. So, Mark, I think that brief intro, I’ll turn it back over to you.

[00:05:10] Mark Callahan: Perfect. Well, thank you. And that is exactly why we’re here today to have this conversation, you know, it’s one of the questions that came out first and foremost from everyone that we’ve talked about it IDQL and Hexa is: why do we need another standard? And what’s the need, and so with that, I’m just going to lead with that, that very same question.

Eric, tell us a little bit about why we needed a new identity standard.

[00:05:30] Eric Olden: Yeah. Great question. And you know, I think what really, as Gerry alluded to. Multi-cloud and distributed architectures came on to the market really quickly.

And you know, a lot of it brought new challenges and problems where you had a lot of this fragmentation things didn’t work together. It was very difficult to find a way to make things consistent and manageable. And really how do we make the clouds interoperable from a security and identity and access standpoint?

And so, you know, we looked at the ways to solve that using the existing standards and a number of the standards that have been really helpful and foundational to get identity to the cloud today. Are still going to be around, right. IDQL doesn’t replace them, but it, it, it fills a gap that hadn’t been met before, specifically around policy.

So we have things like SAML, which has been really foundational to introduce this notion of distributed trust and things like single sign on and being able to share context between organizations and applications and sessions. And then we have things like, OAuth and XACML, which were great for authorization and terms of runtime and how do we allow or deny different things to happen.

But nothing had been done so far when it comes to the rules or the policies. And if you look at the commonality between all these systems, they all had policies. But all of the policies were proprietary, understandably, because they weren’t ever designed to be interoperable. And so we looked at, Hey, if we’re going to solve the interoperability problem, why don’t we start with the policies and look to build a standard. So it’s not just some company’s product, but like other standards really expand the openness of economy or of the market and so forth. So that was really the spark that lit the effort here at Strata to create this ecosystem and to, you know, build all of the working group and to produce what we built so far. Anything you’d add to that?

[00:07:46] Mark Callahan: Yeah, Bob, there you are going to, you have to get thoughts about that. I definitely wanted to get your perspective as well. Bob is, is we’re thinking about what, why did we need a new standard?

[00:07:54] Bob Blakley: Sure. So when I think about this I think back to the early days of user provisioning in the enterprise, right?

And the reason you needed user provisioning was because you had a bunch of different systems, each of which had a notion of identity, and each of which had a notion of access control. And and you had a small group of administrators who needed to be able to create all of those policies and who needed them to be consistent because you had the same users being managed in all those systems.

And you were trying to give them the same set of permissions to a set of resources across the business. And so what happened in that instance was a bunch of different companies. Sun Oracle SailPoint all did the same thing. They all built a a universe of connectors to all of the backend systems.

And they then put a single user interface on top of all of those connectors in order to create a comprehensible environment for administrators. Well, that was fine. As long as you are going to be an Oracle customer or you were going to be a SalePoint. Or you are going to be a wave set customer or what have you, but it was enormously duplicative of effort because everybody was providing connectors.

And also it locked you in to a particular particular vendors administrative framework. So what IDQL a is really designed for is to provide one set of connectors via an open source projects and allow everybody who’s trying to create administrative function for enterprise at fo r a multi-cloud environments in their in their tool sets to right to the homogeneous interface of IDQL and create a great experience for administering things.

Coherently and consistently across all these platforms. And so fundamentally that’s the way I think about it. Right. IDQL is a framework layer in between the backend systems in the cloud providers that are doing the implementation of identity management and the set of tools on top that are presenting identity management to the users.

And this. Different set of toolsets to, to co-exist and still to have identical results across all cloud environments and across, you know, policy administration in general.

[00:10:31] Mark Callahan: Gotcha. Gotcha. And what I love it, you know, so you and Eric and Gerry, there’s several of you, Eric, you were even a cloth or of SAML, and there’s a lot of experience that went into building the standard, you know, across the board of the panel.

Where did we even think about starting, building IDQL and Hexa. What did the process look like for creating the standard Eric?

[00:10:52] Eric Olden: Yeah. Yeah. Well, I think we looked at a couple of things in terms of like, how do you go from zero to a standard? And, you know, I was one of the early people was SAML along with Bob and Gerry, a lot of other people that, you know, really created something out of nothing in the late nineties, early two thousands.

And you know, so there’s a lot of experience that we had to pull from. To say, Hey, what worked in, what could we do differently and make it better? But the, the order of operations, the sequence that we took was to initially start with a conceptual framework where we were trying to figure out and define the scope of the problem, and importantly, put boundaries around that scope.

So it wasn’t unbounded and something that would be maybe theoretically ideal, but practically impossible. So once we have this concept conceptual framework, We then we started to do a lot of customer development talking to as many people as we could to say, Hey, have you seen this problem before? What is it about the problem that you would like to prioritize and get the input from the market and really get outside the building to do that.

Then the next step was the intellectual property. Because with standards, it’s all about the IP. And what we needed to do is lay down a foundation to clarify the intellectual property that’s related to this so that we had something to contribute to the market and open market as an open standard and a free open source.

So we had to have a clear chain of title if you will, on the intellectual property. So that means a lot of time with lawyers and going through patent documentation, things like. So then once we have these in place, we started to look at formalizing the working group. And to that end, we knew that there’s a lot of great ideas and a lot of thought leadership that’s out in the market.

So we went out and we talk with as many of the types of people, not just in the application space where Strata has a lot of our focus, but we look through the stack and say, If we can make policy orchestration work at the application at the platform, at the data and at the network level, then its applicability is going to be exponentially more valuable.

So what we did is we talked to technology providers and standards organizations like the Metro Ethernet Forum. And and others to say, look, join it with us. Let’s do this together. We don’t want this to be a proprietary product of any one company, but let’s really put our best thinking together and create this working group.

So we did that. And then we look for an organization to contribute this to, and we’re really looking to reach these cloud native, the future. Where’s the market going. And we really believe. The organizations that are out there that the cloud native computing foundation, the CNCF made a lot of sense for organizations like Strata who are really building into the future.

And we said, look, let’s work backwards from that to make sure that we’ve got. Right strategy so that when we finish this, that we can reach the most people that are relevant for us. And that was really how we got the motion in place. And then day-to-day, I think maybe I’ll turn it to Gerry to talk a little bit more about how to, how we took that and brought us where we are today.

[00:14:22] Gerry Gebel: Sure thing, Eric, because we were, as part of this process, we were doing really two things, as I mentioned in the slide opening, you know, there’s IDQL, which is maybe more like a traditional spec, like SAML, you know, so there’s defining the specification, but we’re also building this open source implementation.

So we treated that, like we were building a product and so went through, we use an agile process where we went through a lot of research and brainstorming at first to further, you know, re flesh out those initial concepts and ideas. And then we started doing you know, deeper research and just a lot of prototyping.

And I think my guilty we’ll talk more about this later, but we just iterated through that process. You went focused on one platform at a time. So I would work what didn’t and just kept moving, moving forward and, and iterating over and over again to finally get to working code and then, you know, add additional platforms as we went along.

So that was really treating it, like building a product and then, you know, putting it out into a GitHub as an open source repository. Right. Along the way as we’re building the product, then also working to provide or collect in construct all the material that we needed for the submission to CNCF.

So that was you know, that’s been a really an interesting phase of this project, you know, that was sort of hidden from public, you know, over the last, you know, six to eight months or so, and now we’re so happy to bring it to light.

[00:15:58] Mark Callahan: That’s awesome. And because we think about this, there was mentioned again, or that the, the east-west sort of access as we think about that cross platform, cross cloud platform, consistency and policy, but it was also mentioned in the north south. Neil, you were an early member of the working group from, from the Vesa side.

What can you tell us a little bit about what it means to have consistent policy up and down the tech stack?

[00:16:22] Neil Danilowicz: Well, you know, just as we were describing that, you know, you have all these clouds that have the different policy and the customers have to worry about, you know, doing policy in one cloud and then doing policy in the other cloud and working with all of that.

Checks and balances in order to, just to make it consistent. Right. That was becoming a problem, right. From on-premise to the cloud, the same set, but that’s just in one layer, right? A lot of the same type of stuff that you want to do at the, at the, at the host level or the platform level, and then at the network level and at the data level.

Those are a lot of the same type of information needs to be shared in order to do that. Right. If we’re going to do zero trust at the network edge, then I need to make sure that everybody connecting actually is authenticated and authorized. Well. The same type of information that I’m using in that policy is a lot of the same information that is being used at the application layer to identify and authenticate the user actually has access that application and is authorized to do the individual commands that they want to do in the application. And what we were seeing is a lot of people were saying, yeah, so I’ve got the. Funny thing over here that I’m doing in the application layer. And then I got this funny thing that I’m doing over here in the network layer, and they’re not the same.

And now it’s just that cloud issue over again, where it’s, I’ve got to define it all over here. I got to define it all over here and I got to keep it consistent. You know, experience from the user perspective, right? Cause you don’t want to have one decision being made at the network level. That’s contrary to being what’s made at the application layer, right?

You need that consistent set and people are saying, I need one model. I need one way of putting my policy in that says, I need Neil to access. And that has to permeate to all the layers of the OSI model. Right. And if I want to do it in five different points, I need that consistency. And that’s why Versa really got on board in this.

Cause this is where we see this going is, you know, you want to give that single pane of policy glass, if you will, to the customer. And if they want to do it at the application layer, or if they want to do it at the network layer, let them do it and let them reuse that definition. As they see fit through a common language.

[00:18:38] Mark Callahan: Awesome. Well, you know, I was thinking through some of the research several of you had mentioned on that Eric you’d actually touched on the customer research, but there was also from an audience perspective, wasn’t there an application developer research that we were doing as well as trying to under.

What did this mean? What were the challenges? You know, and as we think about that and Mike, the contributions, both as someone who’s worked on creating hundreds of apps yourself, but also in helping us bring Hexa to light the source software. Any thoughts on the perspective there? What were the challenges perhaps developed?

[00:19:12] Mike Barinek: Yeah, I think maybe it helps a little bit of my background to talk about. So was that a company, Pivotal Labs for more than a decade. And we truly built hundreds of apps for startups enterprises. And it was interesting along the way. You know, at the beginning of a new app that we might create, there was this moment where we had a few weeks where we had to think about things like single sign-on, OAuth or SAML.

And it was interesting, you know, over the years put a lot of code, right. Kind of deep into the applications that we built you know, specifically, you know, around who’s able to be what, and that decision. And I think for me, from the app side being able to pull that outside, you know, both the decision as well as then orchestrating policy around who could what.

It’s really amazing. So every time I fire up a suite of boot apps, for example, and I could go into the Hexa admin that we baked into the open source, and I could change access for Gerry across that whole suite of apps. It’s still kind of, you know, it makes me laugh a little bit like, oh my gosh, we’re really onto something here.

So yeah, I, you know, from day one, Know, probably sitting on a chair, lift with Eric have been super excited to have the opportunity to work on this. So, you know, thanks to the Strata crew for sure. And with respect to maybe the open source, I think I had for awhile been wanting to dive a bit more into the open source side of things and especially, you know, getting into IDQL, right.

The language itself, thinking about that side of the house, maybe. I think for me putting all this together there was a lot of heavy research and coming from Pivotal Labs background, right. Where we’re heavy on the execution side. Right. That was fairly interesting for me. So I was wearing both, you know, dev hat as a bit and a bit of a TPM hat at the time.

And I think one thing I learned is, you know, not be fearful to throw things away. So there were a lot of attempts, you know, kind of. Version one version, two of kind of a reference architecture implementation that you know, we threw up, we replaced as we learned along the way. And I think the code base that you’re looking at now in the open source might be the third or fourth row of that research and I think we landed on a really good place in a really good place.

I also think just the ruthless refactoring is interesting and maybe how we talk about the stories and you know, how things get interpreted by the community has been an interesting thing for me as well. So yeah, that’s a little bit on the dev side.

I guess I’m looking forward to, as Mark mentioned at the beginning, a continuation, you know, deep dive on the tech side in a follow-up webinar potentially.

[00:21:57] Mark Callahan: Absolutely. I mean, we realized in doing the rehearsal for this, that we didn’t, we had so much good stuff that we wanted to talk about that we weren’t going to have as much time to actually work with the software.

So in the follow-up email for everybody in the audience we’ll let you know, we will be scheduling a developer workshop to really get into all of this and go into the demos. And we want to encourage everybody to work with Hexa and bring those questions to us. So we can meet up and hear the stories and hear the experience, you know.

And Neil, you know, back to you, as we’re thinking about that, the network and the application layer, thoughts on, you know, from an app developer perspective or the.

[00:22:31] Neil Danilowicz: So from the, from the network layer, you know, one of the things that versus always prided itself on is trying to do everything as much as we can. Standards-based right. You know, I think Bob said it perfectly, there were proprietary solutions that you could do that would sort of build these connectors and solve this for you, but you got locked into that.

Right. And at the network, you know, one of the things that you talk about is just the tech X plus and all that type of stuff that you could do at the network layer that didn’t necessarily translate to the application layer, right. They had their way of solving it and it gave you a lot of the context and you could build a lot of that policy.

The problem was, it was only for the network layer. I couldn’t go into it. And as a network company that is doing, you know, software defined wide area network and software defined security, we needed to be able to go to the level of, you know, doing layer seven. Right. Really understanding the applications. So now we needed a way of bridging that gap.

And what we’ve learned is anytime that we can do this in a standards-based method. It drives a better adoption for our company and for the customers, because it gives the customer a sense of that. You know, this has been looked at, it’s been, it has been tried and true. The community has, has validated it. And then what they’re doing here. You know, again, the say they use versa. What they’re doing with versa. It’s not just thrown away when they decide, Hey, versus no longer the company I want to use. I want to go and use it for someone else. They haven’t lost all of that development work. Right. It is now re-usable. And you know, I know that there’s a lot of companies out there who don’t necessarily like that kind of interrupt.

But from what, from my experience, driving that interrupt and having that capability of doing that interrupt actually drives your, your, your customer sales higher, because now your customer knows that you’re willing and able to do a lot of things. And so I think the, this standard of having to do the, find the policy now, how do use authentication, how do you use authorization?

How do you use context and putting that all together and being. To do this in a common language across the whole stack is really is what’s going to drive this. And so now you can see how a networking company would use it and allow their customers to go all the way down to the application stack. So what they’re defining for the network is not disparate from what they find that the application layer.

Right. And so then it permeates all of the environments and I, I think that’s what we learned. And so when we started to talk about the east-west, then we also talked about the north south, right. Because a lot of companies have different business units and they have different things within the business unit.

So it’s not just east west in the. In the clouds, but it’s also, east-west within the company. Right. And you have to be put onto the right segment.

[00:25:23] Mark Callahan:  So it’s an early thing we heard as well in talking with you. And there’s actually like a skills gap too, that brought this about in terms of, as we’re thinking about from an HR perspective, like how who’s that unicorn developer, who is all of these languages and syntaxes, and they know who they are and they know their work and they’re incredibly expensive.

And they’re few and far between. There’s this aspect of like, what if you didn’t have to worry about that as well, and you have this,

[00:25:49] Neil Danilowicz: It gives, it gives a place for the people to pull the stuff from it’s a positive. It’s almostlike a, a, a lean NFV type of a deployment where you put the stuff there and then you use it appropriately so that it fits very nicely.

[00:26:03] Mark Callahan: Absolutely. Well, as we think about the standards, I actually do want to get back to just a little bit of what we’ve maybe had learned, you know, from past experience, I wasn’t actually involved in the early SAML days, but you know, we’re lucky enough to have a few people who were, you know, Eric and Bob, as you think about what were some of the lessons in creating SAML that you knew that we needed to do differently with IDQL and Hexa.

[00:26:24] Bob Blakley: Well, I’ll start by saying, all right. So SAML was in many ways a remarkable achievement. But what we achieved was a specification, not an implementation. Right. And so after we reached consensus on the specification we went to the providers of IDPs, right. Identity providers and and worked with them to implement the SAML spec and to test their implementations, to see if they actually interoperated in the wild.

So that’s a little bit like having two space programs independently built. You know, modules for space and then sending them up there and then having both sides kind of go out with their toolboxes on a spacewalk and and, you know, modify the airlocks in real time to allow them to dock, right.

It’s not a super efficient mechanism for achieving interoperability and. What the IDQL team has done with Hexa is to basically build an airlock module that if you want to build a space capsule, you can incorporate into your space capsule, and it’s already been tested. So the two of them fit together.

You know, when you try it. And so we avoid. You know, like five or 10 years worth of of interrupts that we did in the SAML days at Catalyst and that you know, digital ID world and other forums to get things to work together after the fact, according to the specification, by providing a reference implementation, which in print, which, you know, in principle had to inter-operate cause it was implementation. So I think that was a big lesson, Mark.

[00:28:12] Eric Olden: Yeah, absolutely. And to build on that, I think the a couple of things that we also saw was the importance of keeping things simple, because if you have too much of a scope, you can’t build anything. And so. We really looked at being very ruthless in scoping this down.

And it was a constant conversation about how do we make this practically implementable. And so one way that we did that was by looking at the systems that we were looking to orchestrate policies within and work backwards and say, for instance, can we do this repeatably reliably through an API? And if we couldn’t, then it was out of scope.

So we really set our, our guard rails around things that we could practically implement using API APIs, using existing policy syntax and structures. And what came out of that was a lowest common denominator, which was, was something that we could actually implement. And we learned a whole lot in the process of doing the implementation.

And I think Mike alluded to that. You know, a lot of this refactoring saying, okay, well, we got it. We have two out of three systems, but when we do the third system, it changed our assumptions. So we need to go back refactor for systems one and two and three. Now they all work together. And that was an iterative process.

And by doing that in an implementation of Hexa, we were able to do that very quickly and, you know, sure. We had multiple constituents from different organizations working on that project. We were still very focused on who had their hand on the keyboard so that we could have that speed and the velocity.

So I thought that was really helpful. And then, you know, I think the idea of saying, look, we don’t need to wait for clouds to adopt this. We can jumpstart that adoption by giving away the Hexa implementation, because that’s as Bob describes it as an airlock that you can use with like preset Lego configuration.

That was really the idea is to get the core foundation. For the main clouds and a reference implementation through the North-west, or I’m sorry, the north south of the stack so that anyone who’s coming in here, isn’t starting from scratch. And if you’re, for instance, looking to build a connector for another cloud to do application level work. Well, you’ve got a source code that you can look at. You can build derivative components very quickly. If you want me to do it on the network, You can also, you know, start from jogging or running start. So it’s really kind of seeing how do we jumpstart adoption by pre-building as much of this as we could on the smallest scope as we could.

[00:31:09] Mark Callahan: The visual metaphors in this session are awesome. I love it. Airlock, the jumpstart, the run. Gerry, did you have something on that?

[00:31:17] Gerry Gebel: Yeah, I think what, what I’m Eric and Bob described here is a way to get to adoption much faster, because when you think about, you know, the lead time from going from, you know, SAML spec defined to, you know, the network effect of having enough identity providers and relying parties using that spec you, and that was what, 10 years or longer, you know?

So it was really quite a lead time because we had to go through. The product management backlog for all of those companies and vendors, right. To get the spec into the backlog and actually get implemented and then make it interoperable along the way. So what we’ve done here is taken from that experience.

And like Eric said, using the available public API APIs of these platforms. We can bring the standard to those platforms. You know, we don’t have to wait for their product owners within the cloud platforms to adopt IDQL. We can bring it to them with, with Hexa. So that’s a huge game changer for this effort compared to other standards.

[00:32:23] Mark Callahan:  Absolutely. And that actually got me thinking about adoption from a business practitioner perspective and very much was thinking about, okay, so we’ve talked about where this has value in inside of the, the business or the enterprise and the value that this has to an app developer. But as we think about like the business, the core business value and we look at where this has real, real impact and rage. Tom, you know, in your experience, I mean, you’ve, you’ve led identity and security organizations for some of the world’s biggest financial services orgs. Are there any examples or things that you’ve thought about as you’ve been working with us on the working group for this project.

[00:33:00] Tom Malta: Yeah. First, let me just say, I mean, I love being here today, cause this is a, as you guys know, I’ve been talking about multicloud and challenges now for a long time, having lived through a lot of that and it’s just great to see it all kind of come to fruition, you know, with IDQL and Hexa of being born.

I think when we, when we look back in the industry as a whole. You know, the days of, you know, a single cloud provider are kind of gone, right. People are now thinking multi-cloud and multi-cloud has a bunch of different meanings to it, right? It may also include private cloud on prem end points, legacy stuff that you might have in your environment.

If you, as you guys have talked about already on the panel, I think when you look at just the three CSPs, the big ones right across the three of them over 40,000 permissions, right? Between groups, roles, and policies that need to be set. And each of them have their own unique identity management system.

And that was by design, going back into, you know, the original birth of them, thinking that. Whatever comes to us, you know, we want to have our own proprietary format. Well, in reality, in practice within business initiatives and in CEOs and technology organization, this is a nightmare, right? Like trying to manage multiple different CSPs which essentially is, as you guys know my favorite analogy, you know, the apples, oranges and bananas.

Right. And you know, we’ve got problems today in each of these cloud environments. Over permission services or identities that are running now. And why is that? Well, because people don’t understand, app developers don’t understand how these proprietary systems work, so they tend to gravitate towards over permissioning them.

Instead of really trying to understand how to operate effectively. Well, if you break that down and you say, well, how would we solve that prior to Hexa? And prior to me, IDQL, well, it really comes into now, you know, I have to have multiple teams support. These individual cloud environments, right? I have to go out and get a AWS developer, a second Google developers and so forth.

And the reasons for why this is doing that are many fold, right? You might have a marketing department that loves Google because of its analytical capability. Whereas your IT department loves AWS because its ability to grant permissions at the finest grain resources. But the problem also becomes when you start thinking about your, your pipelines into the cloud, You might want to use it for other reasons, maybe BCP reasons, or to even make sure you can have the ability to fall back.

For instance, I’ll give you an example. And one of my prior roles, we were big Microsoft shop and they had a small outage that didn’t really affect us. Right. But suddenly it got the CTO and CIO thinking about. Hey, Tom, you know, what we do if that was down for any extended period of time and like, how would we really manage that?

And so we started thinking about, you know, how would we solve as well? You know, we’re going to need to bring up. You know, on the other side of developers now to start thinking about the composing, our applications and bringing in those groups, roles and policies of that other cloud provider, so that we can start to bake them into our pipelines and be able to deploy them simultaneously.

That’s a tremendous challenge, right? In terms of being able to understand how am I setting permissions, you know, at a baseline level, across each of these. So, you know what I’m really encouraged about and excited, and to both of you, part of it now for the last couple of years, you know, we’re introducing a way where one organizations who don’t even know what policies they have running in these environments, you have through policy discovery, you can pull them down to transformation, right?

Bringing it back into, you know, a common IDQL, declarative language. You can manage it centrally in one place. This is huge, right? I don’t need to have. Individual and multiple teams out there. I don’t need to have quality control around how are my pipelines being moved into different cloud systems and, oh, by the way, while they’re running, I have to monitor to make sure their permissioning is level set. I don’t need to do that anymore.

If I can do it in a centralized place. Right. And be able to then translate it back to an apple orange or banana through orchestration. Right. So I’m tremendously excited. I think this has a great place in the industry and, you know, being an identity fan my whole career you know, which is exciting to see something like this coming to the market. Couldn’t be could it be happy? Couldn’t be happier.

[00:37:33] Mark Callahan: Awesome. Awesome. No, I appreciate that. And you know, and, and I think, you know, Eric you’ve touched on it a little bit was how easy the, the being able to take a running start, this isn’t something where people like, you know, is this going to be a really onerous effort for people to implement in their own applications or in their own businesses, you know, is there, is it, is it worth the effort, but it sounds like it’s actually quite easy to get up and going, you know, as, as you know, maybe you are Bob thoughts about this, you know, with legacy systems and interoperability.

[00:38:04] Eric Olden: Yeah. Well, from my standpoint, I think the interoperability we’ve been starting with. The forward look and saying, look, we can, at some point look more at the legacy, but let’s not build something for yesterday. Let’s build it for the future. And so a lot of the initial use cases and target platforms are all of these cloud native systems.

And I think we’ve got a fair amount of scope ahead of us to really make all of that work. You know, develop ecosystem as well. I’m sure as my own day to day experience in the Strata and the Maverics universe around identity orchestration has shown is that there’s a need in the market to have a foot in the future and a foot in the present. And some aspect of, you know, the shadow of the past continues forward. I think really creates an opportunity to say, look, we don’t have to abandon everything we’ve done in the past. Now we have a way to take IDQL and Hexa and have connectors built for legacy systems. And. The way that we’ve structured, this is to really invite the community to do this.

So that imagine if you’re a developer and your project is app modernization. And as a result, you’ve got to work with three of the CSPs, but also the on-prem and the legacy world. Well, the same principles will apply when you point the Hexa app the IP APIs of software below 5, 10, even 20 years ago. And so that’s the whole, is that, you know, we can spread this around so that people they’re not out on an island doing one-off work, that they don’t want to maintain and deal with.

But instead, imagine being able to have a community that you could build a connector, you think it’s maybe a one off. But there’s someone else in the ecosystem that says, oh, I have that same target system I had to work with. Let me work on a connector with you. And hopefully we use the open source community as a way to create and foster collaboration so that we can build a generic connector for a common legacy system that will solve a whole lot of people’s problems. So while the focus is on the future, the applicability is for the present and the past as well.

[00:40:34] Mark Callahan: Gotcha.

[00:40:35] Bob Blakley: So, so I guess I would follow up on that by saying referring back to something that Eric said or. You know, I think there was a lot of emphasis in IDQL as there was in SAML. We did this very intentionally in the, in the SAML days on minimality. Right. And so solving multi-cloud identity management. Is already a relatively big problem and you, and you want to keep the solution to the sort of simplest feasible solution for at least version one of the standard.

Solving multi-cloud plus all of the legacy on premises administration issues is a much bigger problem and it would have cut against the minimality goal to try to bundle all of that into the spec. And I think you know, it’s also important to understand that there are two types of activities here, right? So. Multi-cloud identity management is a coexistence and interoperability task, primarily because people don’t think that they’re going to migrate from Azure to AWS or vice versa.

They think they’re going to use all of those platforms in parallel going forward. And so the capability to administer them at the same time, it has to exist. Maybe not in perpetuity, but for the foreseeable future. Right? On the other hand moving from an on-premise identity infrastructure to a cloud identity infrastructure is at least in principle, a migration exercise, not a coexistence exercise.

Obviously there will be a long period of time in some enterprises where these things will exist side by side, but nobody wants to keep the legacy on premises. Forever. Right. They want eventually to migrate that into the cloud. So it may be that what you have, you know, you know that in an ideal world, you would essentially do an ETL from on premises stuff to IDQL in order to get into the future environment.

And you wouldn’t really want to build into the Hexa implementation. And ability to administer everything in the legacy environment, because that would just be dragging the anchor through the muck on the bottom of the ocean, you know, and, and slowing you down in getting to the future. Now, in, in practical terms, in big enterprises, you are going to have that legacy coexistence for awhile, but you know, it would be nice to hope that the migration eventually concludes and that you don’t have to spend a lot of time maintaining you know, vest, digital organs in the Hexa code base for systems that hopefully will cease to exist at some point.

[00:43:28] Gerry Gebel: Yeah, that’s, that’s a good point about the scope. And we always were trying to refine the scope and, you know, stand back from the scope creep that seems to infect every project. But we, I think we. It’s still a lot of discipline around that. But Mark, you would add, you were asking a moment ago about how to get started and certainly people can get to the Hexa repo today.

You know, we have a mantra here at Strata about being able to do something in 10 minutes or less. So that was definitely our, the bar we were looking to, you know, get code in someone’s hands and get them a, a workable experience that quickly. And so Mike and team really did a fantastic job. And being able to set up a fully contained local environment where you can have fewer running Hexa policy administration component and a target sample application to work with.

So it’s, it’s really belies the complexity behind what we’ve done so far that, you know you could actually download bill that and install it that quickly, sometimes even in five minutes or less.

Sure beats that 10 or 15 year wait that we saw with some of the earlier experiences. I mean, that’s and the open source aspect of this allows, you know, Eric as you mentioned the, the intention is to allow others to build on top of it.

The, the core functionality was built for today and tomorrow, but should somebody want to do that? They there’s absolutely every opportunity to build those connectors with what’s been open source. So, you know I guess at this point, Any last closing thoughts? I didn’t know if there was, we, we covered a lot of topics, you know, obviously we were looking at why did we create IDQL and Hexa.

We, we looked at some of the challenges that presented themselves and we weren’t just born right. This, this wasn’t that we had empty cycles or like, what can we go do? And let’s just create a new identity standard or is that. It’s very demonstrated need from a broad audience needing this. As we think to, you know, any, any closing thoughts as we want to share with the audience, we have people joining us who are identity practitioners, app developers from other standards, any, any closing thoughts that folks might have, and I’m just sort of open flooring it for the last few minutes here. Eric. I don’t want to put you on the spot here.

[00:45:45] Eric Olden: Yeah. No problem. I do have a thought I’d like to share with the audience, which is please get involved. You know, we did this, not with an intention to do anything other than create this interoperability to free you from a lot of the proprietary walk in and so forth.

Right? So the intent here is. Really foster openness and agility and all of these other aspects. And we made this investment in a standard and the open source to really facilitate that. And we would love all the great input that we’ve gotten from, from Neil, from Bob, from Mike, from Tom and many others that are not on the panel today, but great ideas become stronger with more contribution.

And I think really to communicate, our expectation is let’s make this a thing for all of us, not any one of us. And so getting involved with the working group, you know, we are, it’s a very active process. Gerry is, is very diligent and running it day to day. And we’re really excited about now bringing this to the public so that we can get more people on board.

And we really hope that you do. We’re happy to help facilitate ramping up and, and maybe, you know, doing more content as we will shortly in the future for a deep dive with the developers, but we really want to do this for the community and are asking for everybody to get involved. If you could.

[00:47:24] Mark Callahan: Terrific. Anybody else? Any closing thoughts? I know we had a lot of branch topics. Are there any other thoughts that anybody might have for, for the audience?

[00:47:38] Neil Danilowicz: Yeah, I think you’re on mute.

[00:47:42] Tom Malta: Can you hear me now? Yes. Sorry. Double click the mic. It’s double click problem. So no, I think Eric summed it up really, really well. And I think hopefully the audience out there this is resonating with many of you in terms of the need. We definitely also need you to participate, right.

Become part of that working group. I think that from a business technology standpoint, I know a lot of you are out there right now are going through transformations in your own organization, much to what Bob and Eric and others, you know, summed up today around some of that legacy stuff that might be in need of modernization.

And you’re trying to figure out, you know, how do I effectively move. Not just to a primary cloud provider, but to have the ability to move to multiple cloud providers simultaneously or cross stack or geography, whatever the reason might be. Please take a look at this, cause I think it’s a good place for you to ground yourselves on, in terms of the architecture and also from a cost perspective, risk, perspective, deployment perspective.

The benefits to the business and the IP organization are enormous, right? Not to mention, it’s going to drive down your cost across many different aspects so.

[00:48:57] Mark Callahan: For sure.

[00:48:59] Bob Blakley: So I guess I’ll say something maybe a little broader than the conversation we’re having here today which is, you know, those of you listening. If you, you may be thinking. Well, okay. IDQL sounds a little bit like the multi-cloud SAML. And if that’s the case, where is the multi-cloud XACML and where is the multi-cloud audit login and log search API.

And, you know, do we need those things too? And the answer is yes, of course we do, right? Because multi-cloud environments are going to have to be administered. According to every piece of functionality that they offer. And so you know, I, I guess my advice is that if you feel the need for some of those things, because of the lack of them is getting in the way of a job that you’re trying to do in a multi-cloud.

Maybe maybe you know, if you look to your left and look to your right and don’t see anybody doing it, you’re the, you’re the guy or you’re the gal. Right? So you can certainly you know, make use of people who have you know, been in activities like this before and get in touch with the, you know, the people on the call for advice on how these systems work.

But I expect that there is. You know, that there are more multi-cloud administration APIs that are going to come down the pipe. And if you see the lack of one it would be a welcome service to the community. If you were to maybe start up an effort to provide it.

[00:50:28] Neil Danilowicz: And I’d like to call out to everybody, even the managed service providers and the service providers themselves, right?

This whole spec is not just solving an enterprise’s set. It’s solving even a service provider side where you have to do this integration. Your customers are coming to you and asking you to build. Very complex systems. And you’re trying to figure out how to do a standard policy definition across that whole complex set.

This is exactly what you need is, is this common language and you know, the Metro Ethernet Forum (MEF) is behind this because they see that this is a need in that service providers/ space to actually deal with identity management, across many different platforms, to the point, whether it’s on-premise legacy or whether it’s in the future of cloud, cloud models.

We need something here. That’ll allow the, the the end user to create these policies in a standard way, such that when the, the CISO says, Hey, are we covered? He’s not saying, Hey, are we covered here? Are we covered? There? Are we. No, are we covered? Yes. I went to the standard thing and the standard policy is applied at all the different endpoints.

[00:51:39] Mark Callahan: Oh, excuse me, love losing my voice there. Well, with that, I think we are just at time. Gerry, would you share some thoughts about what’s next and where are we headed to now that so that the specs of the open source software has been available since earlier this year on GitHub, there was a big announcement this past week, you know, many news organizations pick up the story cause there’s a lot of interest here. What’s next for IDQL and Hexa?

[00:52:05] Gerry Gebel: Yeah, well, I guess the next big milestone, Mark, is waiting on approval from CNCF to be a formal sandbox project. So, you know, the next meeting is happening next month and we’re certainly looking forward to, to that.

But meanwhile yeah, since the announcement we’ve had quite a tremendous response from people wanting to get involved. You know, people from vendors, from a systems integrators from enterprise organization. So my calendar is filling up to talk to those folks about how to get involved. And as Eric just mentioned, we really are looking to broaden the participation here so we can get more perspectives, get more use cases and requirements. So, you know, please do reach out there’s contact information.

You can see the GitHub repo as well. So there’s two actual repositories, one for IDQL, it’s called policy and one for Hexa that’s called policy orchestration. So you can go out and take a look at what we’ve been up to. And there again, you can contribute issues. You can contribute code make a pull request. And so on Thursday. An explanation of how to get involved with there on the GitHub, GitHub repo as well.

We also touched on this a developer workshop that we are thinking about hosting in the very near future. So Mike can give us a deeper tour. Into the code itself. Go through some examples, run through the demo where I do feel like a unicorn, Mark, where I can manage policies in these different environments. And I don’t know how to do that natively. So it’s really an amazing feeling running through those demonstrations and even beyond. What was that sorry?

[00:53:47] Mark Callahan: It was super power. It’s kind of fun. Yes. That unicorn ability that just gives you.

[00:53:52] Gerry Gebel: Absolutely. Absolutely. And then even further down the road, you were talking with the MEF about setting up an incubation project sometime later this year. So we can get to work on what Neil was describing. You know, how do we, how do we tie this iDQL and Hexa to the sassy world and, and all the, the great standards around zero trust that MEF is building.

So lots of different, exciting activities here going forward. So please do join us and jumped into the ring with us.

[00:54:21] Mark Callahan: Well, I thank you everybody for joining us. I wasn’t kidding. When we said we had a, a full hour of content, but hopefully we answered those questions that we set out to do at the beginning where people were really interested in.

Why did we do this? What were the challenges? How does this compliment existing standards that are out there today? Where does this fit in the identity ecosystem and how do we get involved? And so I just want to do a quick thank you to everybody for taking your time to join us today, our speakers, but also our audience. I know this was a valuable hour of time.

Hopefully you all found it really interesting as, as I did, we’ll be sharing a recording of this session via email afterwards, along with responses and be sure to also check your inbox for invitations to the developer workshop. We’d love to get our hands dirty and really start playing with this together. So with that, I’d like to thank everyone and wish you all a great day. Take care. Thank you.

Protect your sensitive data in the cloud

We’re in a multi-cloud world that presents new opportunities as well as new security risks to your sensitive data. Consistent identities and policies are the key to protecting your cloud-resident data. And that’s where Strata’s Identity Orchestration platform comes into play.