Identity at the Center is a weekly podcast all about identity security in the context of identity and access management (IAM). With a combined 30+ years of IAM experience, hosts Jim McDonald and Jeff Steadman bring you conversations with news, topics, and guests from the identity management industry.
Do you know who has access to what?
You’re listening to the Identity at the Center podcast. This is a show that talks about identity and access management and making sure you know who has access to what. Let’s get started.
Welcome to the Identity at the Center podcast. I’m Jeff, and that’s Jim.
Yes, we’ve talked about trying to do a live show or a live stream. That could get interesting, to try to launch doing something like that for the first time and be in a new territory — in other words, not knowing what the Wi-Fi situation is, and things like that — it might be too much new at once, but that’s something that we’ve gotten feedback from our listeners about in terms of “We’d like to see you guys do a live stream,” and the software we’re using now could enable that.
Yes, and that’s really the only in-person conference that I’ve really potentially looked out for — this year, anyway — but I’m definitely looking to get back on the circuit again next year.
Today, we’re going to get into identity, and I think one of the conversation topics that we’ll probably want to approach here is talking about identity fabrics and orchestration, and what the heck does that even mean, and trying to decipher how that works in the real world. We’ve invited Gerry Gebel from Strata.io, Strata Identity — he’s the head of standards — to help with this conversation. Welcome to the show, Gerry.
Jeff and Jim, thanks for that very much. Thanks for the intro and the invitation to be part of the Identity at the Center podcast series. It’s great to be here.
Yes. Thanks so much for joining us, and I think, as a first-timer on our show, we like to discover your background and how you got into the identity space. One of the theories that I have is that for the most part, most people didn’t choose identity, it chose them, and I’m curious if that’s the same for you. How did you get into the identity space?
It’s a bit of a long and winding story, I guess. I’m not sure if I was pushed or pulled into it — maybe a combination of the two. My time started in security before identity even was a thing in the industry, back when I was at Chase Bank in New York and had a great mentor there. I think a mentor has a big role in how our career is guided over time, and the opportunities that are presented and the ones that we take or not. I had a great mentor there, Bill Wan, who emphasized the need, the importance, of getting outside of your cubicle or office and seeing what’s happening in the world, and he really encouraged me to be part of some of the standards activities at that time — for example, at the Open Group. Then, I also was part of starting an organization on Wall Street that we called the Securities Industry Middleware Council, where I met another great mentor from that time period, Eliot Solomon.
That really expanded the horizons and got me introduced to a number of different people, including folks at the Burton Group, so that’s how I got connected with the Burton Group and joined them around 2000 as part of their consulting team. At the time, Burton had two services: One was directory and security, and the other was networking. What I was part of when I joined was, we split up directory and security, so we had a security practice, and then the directory side became identity and privacy. I guess that’s my intro into the identity industry, and from there I went on to join Axiomatics, focusing on dynamic authorization, and now here, of course, at Strata.
Cool background, Gerry, and one of the things that really popped out to me was the Burton Group. That was the analyst firm covering the IAM space as I got into the industry around the 2003 time frame. I’m wondering what it was like working at an analyst firm like the Burton Group and being the go-to for how we look at the space, how we develop our strategy, how you compare Product A to Product B, things like that.
It was an incredible experience. I have to say, the people I got to meet and work with there are just the who’s who list of people in the industry, many of the names we’d be familiar with. It was incredibly intellectually stimulating working with all of these smart people, and being the dumbest guy in the room and just soaking it all in, it was really, from that perspective, an amazing, amazing experience. The whole process of being a consultant or research analyst was quite a jump from being an individual practitioner within an IT department, but you just learn over time. You learn from your colleagues, and you take in all that guidance.
It was a big job. It was a huge responsibility to be part of that industry, because so many people, as customers of the research service, are looking to us for very important guidance. It definitely was a combination of a great work environment with an amazing group of people, but also that burden, or the responsibility, of, you really have to do your work, do your research, think about what you’re writing, what you’re presenting onstage, because it was so impactful for so many people. I think that was quite a combination.
Informally. I think there are small groups of us that still make the conference circuit, like you were talking about before — hopefully, starting to get back into the swing of that later this year or certainly into next year. There’s some informal expert alumni that will get together at the bar afterward and swap stories and so on, but nothing formal at the moment.
No, nothing like that.
I think one of things I always find interesting around the analyst consultant versus what I’ll call a “normal” consultant is having to be able to keep track of all the different products in the space. For better or for worse, a lot of organizations will take a look at analyst reports and say, “OK, this sounds good,” and then they might invite the person who actually wrote the report to talk to them directly: “Hey, so tell me what is exactly the difference between SailPoint and Saviynt? Why is one better than the other, or Ping and Okta or Microsoft?” or whatever it may be, and I would find that extremely challenging, I would think, to be able to stay on top of so many products in the space. With the way that the velocity of the industry has picked up, especially over the last couple of decades, how do you stay on top of all that stuff?
To your first point there, I will say, yes, it can be very uncomfortable. Sometimes, when a customer prints out one of your reports and they start going through it paragraph by paragraph — “What did you really mean here?” — that can be a little challenging, but I think to your later question, one person can't know everything. Look at Gartner today: How many thousands of analysts do they have? It’s an incredible number, and it shows you have to start to divide and specialize a little bit.
We did that at the Burton Group. We had across a team of analysts, they would focus on different areas, whether based on their experience or their background, and then, when you get a customer call — inquiry about a certain topic — if it wasn’t in your wheelhouse, then you had to defer it to someone else because you don’t want to go down the path of talking confidently about topics that you’re not really an expert in, because that’s where you’re in a danger zone.
Yes. Knowing when to engage and when to pull back and defer, I think, is important. One other thing that you mentioned about not being the smartest guy in the room, I think, everyone can relate to that, and I think it’s commonly referred to clinically as imposter syndrome. It’s like, “What the heck am I doing here? Why did they even pick me?” — those sorts of things — and I’m curious: Is that something that you can relate to from your role?
I know what you mean by the imposter syndrome. I don't think that that applies to my experience, but I think having reverence and respect for the other folks in the room and learning from them and over time gaining your own confidence level — I think that’s really what was a valuable part of that experience, is that everyone around us was so supportive, so that quickly led to having some confidence in your own research, in your own opinions and so on.
What was an important aspect of learning to be an analyst at the Burton Group was being able to defend your positions, and so you could take any wild, harebrained idea and throw it out there. That’s fine, but that was only part of the effort. You really had to back it up: “Why did you think this should be the way to go in this certain industry?” “Why do you think this technology is better than that one?” You can’t just throw wild statements around. You needed to back it up, and that was, I think, an important element of gaining that confidence level.
Yes. I think another thing that Gerry said is around learning from each other, and I’ve started to incorporate that and say that to clients — like, “Yes, you definitely brought us in as the experts, but we’re going to learn from each other.” Honestly, I think that’s how I’ve become a much better consultant. My past 10 years in consulting is learning from my clients, seeing how things are done in different places, because it’s not like I have another day job where I’m an IAM manager or program manager in a company anymore.
Now, what I’m doing is consulting and working with different clients and learning from them, learning what they’re doing that’s best practice, and obviously combining that with research that we do, but it’s a very important aspect. If you have the personality of being open-minded, that helps you in any aspect of life, but it’s a firm requirement when it comes to being in consulting and probably being an analyst as well. I’m sure, Gerry, that was your experience — learning a lot from your clients.
Absolutely. I think there is no limit on what you can learn or how much you can learn. It’s a lifelong experience. You’re absolutely right, Jim, that conversations with customers were very enlightening, and it goes back to what Jeff said earlier about “How can you know everything about everything?” You learn bits of information from every conversation that you have, whether it’s talking to a customer directly about a specific topic or question or getting briefings from vendors or seeing demonstrations or those fantastic one-on-one chats in the conference hallway or at the bar afterward. You learn every step of the way, so you try to bring all of that together as your combined experience and go forth from there.
In some of my past roles, I’ve had, say, one foot in the standards community, but back at the Burton Group, I authored a number of reports on things like SAML and WS-Federation and XACML and hosted a number of interoperability demonstrations at our annual Catalyst Conference. From that perspective, it’s half a foot in the standards community.
At Axiomatics, of course, technology was all built around the XACML standard, so pretty involved with it there, but now, with Strata, I think I’ve got both feet in the standards world, because part of what we’re trying to do here is build out a new standard around what we call Identity Query Language. It’s to help facilitate getting a common declarative form of access policy across a multicloud environment, and we can get deeper into identity fabrics and orchestration here in a moment, but it’s to publish a standard around this and a set of APIs so that not just Strata but also other organizations can take ahold of this standard and incorporate that to facilitate this multicloud, multi-identity world we are in today.
That’s fantastic, because that’s how these standards get started: Somebody takes a shot at drafting version one, and then it goes from there. You’re involved with some of the early standards development that today are very mature standards, correct?
That’s right. Also, some of the founders of Strata were also coauthors of some of those standards, like SAML — Security Assertion Markup Language — which is still heavily used today for federated single sign-on.
Gerry, you mentioned identity orchestration, and what I’ve seen on the Strata website is identity orchestration for multicloud. I’m wondering if you could put that more in layman’s terms, or help our listeners, people like me, understand: From a plain English perspective, what does that mean?
If you take a step back and you think about the precloud days of identity and access management, all enterprises had multiple what we called identity siloes. They were typically connected or hardwired to a specific set of applications for the line of business or maybe within a certain data center and things of that nature, but now, over the last several years, cloud computing has emerged as the preferred way to deploy and manage application workloads.
The promise of the cloud is cost savings, simplified operations, new capabilities that are available that are much better than the data center environments of the past: “OK, great. Now, everyone’s moving to the cloud, but, oh, by the way, we have all these new cloud identity systems.” Azure, Google, Amazon — they all have their own way of doing identity, and then part of the challenge is that organizations are not just going to a single cloud platform. They want to spread out that risk, or maybe there are different tools that are better for different applications across the organization and then, of course, you have all the different SaaS applications that we consume.
Now, we have this hybrid of some legacy identity clouds from the on-premises world, but now across all of these multiple cloud environments, so how do you manage that? That’s where we talk about an identity fabric to start with, because the fabric is the connectivity tissue. It’s how we connect to the legacy environments, to the cloud environments, and then you can begin to orchestrate or manage or facilitate that entire spectrum of technologies in a more single-pane-of-glass fashion, so I’ll stop there and pause.
It sounds to me like it’s the development of a Rosetta Stone as a translation layer between all of the disparate cloud languages that are out there. You mentioned Azure, Google, AWS — those sorts of things. Everyone does identity in different ways. The concepts and structures may be slightly different, but at the end of the day, it still boils down to who has access to what. That’s what identity gets down to, and with the disparate methods, it seems to me like this identity fabric and this identity orchestration is trying to come up with that common language to be able to say, “I want to give this user this thing” and then be able to translate it from whatever the common language is. It’s down to essentially the machine code for each of these different services. Is that an accurate depiction, at least in my brain, of how I see this working together?
Yes, Jeff, I think it is, because in the absence of having that fabric and that orchestration layer, you have to individually manage all those environments, and we know that can be expensive. You need staff to be experts in all of these different platforms, and then you have a pretty good chance of inconsistent settings across these environments, which, of course, exposes you to different kinds of risk. Yes, we’re looking to have a single way to manage all these access rules and policies and then, as you said, transform them into the native format of those target systems. We’re not doing enforcements in the Strata orchestration layer. Rather, we’re just managing the access policies in a uniform way.
You mentioned Identity Query Language. I think it’s what you referred to earlier as a new standard to pull that all together. Can you talk a little bit more about that, because I don't know if I’m too familiar with that standard, or maybe it’s so new that it’s probably not breaking news — not as familiar, maybe, for the people in the identity space? Where is that in a process perspective, who’s working on it and when do you think it might become something that’s out there that people might be able to start leveraging?
Yes. We think it’s important enough, the work we’re doing here across unifying the policy formats, to standardize that aspect of it, so that it can be put out into a standards organization, have open source code available to utilize, so you can call the APIs, you can use the policy language and have it work within your own environments. It’s still at a fairly nascent level, although we’ve been doing a lot of work behind the scenes. Right now, we’re organizing a working group to get started on outlining the specification, defining the APIs, building some of the open source code, and we’ll be doing that through the remainder of 2021. You’ll see the various announcements around this streaming out over the course of the rest of this year, and they’re hoping it’ll be more public by early 2022 and going into a standards organization and really busting it open for a wider audience.
It’s a fairly accelerated and aggressive timeline, but we want to get started on this right away and get a lot of important industry contributors behind that. We’ve been talking to a number of different folks in financial services, in insurance, in the networking world, in the data services world. What’s interesting is although we’re calling it Identity Query Language, or IDQL — it’s a new acronym you all need to learn — but we are also seeing a lot of interest not just from the application, the traditional web application layer, but also into the infrastructure of cloud platforms, the data layer and all the way to the networking. You can think of it as an east-west across multiple cloud environments, but north-south across stack from the application to the data, the infrastructure and right down to the networking level. It’s really quite an expanded horizon we’re talking about here.
Whenever I hear orchestration, I think of a conductor, and I would imagine in a scenario like we’re talking about here, the conductor might be some kind of common dashboard where I go and set my policies or configure the security settings — that then my system is going to out and reach out to my various cloud endpoints and enact those settings. Am I thinking about that in the right way?
Yes, you are. There’s a central control plane, if you will, where you can author and managed these access policies, these identity policies, and then there will be connectors that are gateways that will take this central policy definition and convert it or map it to the bespoke format, that target system, and so you could use, for example, APIs to do that. If the Amazon IAM API is available to do this manipulation, then great. We can just call that, or you can have the connector do that mapping, so there’s that functionality at different levels. You’re right, Jim. You have the central place where you define the policies, and then you have APIs available so that the connectors can call. You get the latest version of the policy for this data set or for this set of business apps and then do that mapping or conversion and load it into the target system.
That was a real fun presentation for me to put together. I have to give a shout-out to Steve Wilson, who really encouraged me to put that together. It’s something that had been boiling over many, many years — even going back as far as 2008, when I first wrote about “Bring your own identity.” I thought of this presentation as my own personal digital ID journey over time and how it impacts you on a personal level.
As an analyst or as a practitioner, you’re always thinking more from a corporate perspective or industry perspective, but that was some of my own personal thoughts about the impact of single sign-on: Is it really a good thing, the social login approach, which really is a formulation of bring your own identity? Because what I said was, “Well, I’ve already proved my identity to some level with this other internet property or environment. Why can't I reuse that? Why do I have to register at every single website that I visit?” Social login through Google or Apple or Facebook, that’s everywhere today, and I think I have a little bit of buyer’s remorse that this is great for some people, but for me, I am uncomfortable with that approach because of all of the connectivity behind the scenes and all of the ability to track everything I do, whether it’s through websites I visit or purchases I make or even the devices I use, they’re tracking data.
The one thought that I’ve been having is, there are so many websites out there that still are not using a social identity provider. As you’re creating a profile, you’re thinking, “OK, this site is definitely going to get breached at some point, and they’re going to take my data and dump it on the internet. I really don’t want to create a profile.”
There are some sites that I walk away from, and then there are some that — for example, I had to create an identity to sign my son up for Little League baseball, and it was a local organization of Little League. It wasn’t the international Little League organization. I’m thinking, “OK, there’s one more place that my private data is probably going to get breached from.” At the same time, I think at the early stages of “Bring your own identity,” some folks were thinking, “OK, this is going to be the way I log in to work, or the way I log in to my bank,” and it’s like, “I could never imagine trusting that using my Google Gmail login or my —” I don't have Facebook or Instagram or any of those, but I could not imagine trusting those to log in to my corporate assets or to my financial records. There’s still value in it, but I don't think it achieved 10, 15 years ago what we hoped it could.
Jeff, I did not think you were a trickle-down economics kind of guy.
Thanks for listening to the Identity at the Center podcast. If you like what you heard, don’t forget to subscribe, and visit us on the web at Identityatthecenter.com.