This is identity at the center. Welcome to the Identity at the
Center podcast. I'm Jeff, and that's Jim.
Hey, Jim. Hey, Jeff, how are you?
I'm pretty good yourself. Good.
So many ways I thought that we could start this Episode 1 was
Happy New Year, but I think I'd be far in violation of saying
Happy New Year since this episode goes live in February.
But I thought I'd start with a pun because it's been so cold on
the East Coast of the US. But you know what?
It's hot right now. Authorization.
So hot right now. I think we need like the was it
the oh, what's the movie? It's I'm blanking on it now.
Zoolander, right? It's so hot right now.
Author is authorization. Well, I think we should dive
right into it because we've got a fantastic guest today.
Yeah, we've got a sponsor spotlight today.
So these are the folks that helped make this podcast
available for so many people around the world and definitely
appreciate that. So it's a fully sponsored
episode. We're going to get into it today
with Plain ID and really learn more about their solution.
I've known Gal, our guests here for at least a couple years now,
kind of way back 20/15/2016. I feel like maybe it was
somewhere around that time frame, but a kind of a routine
mainstay on the identity circuit.
So if people want to learn more about Plane ID, you can go to
the website planeid.com/I DAC. That's PLAIN id.com/I DAC.
So welcome to the show Gal Holimsky, the Co founder and CTO
of Plane ID. Thank you and it's very nice to
be here again. Yeah, the last time you're with
us was way back in episode 218. I thought it was last year, but
you corrected me in your toy, right?
It was a couple years ago. We recorded live from Ideniverse
in one of the many conference rooms.
And I think I don't know if that was like Mandalay or if it was
one of the other, you know, one of the hotels that we were kind
of out there. But we had a great conversation
around back BAC something based access control, I think I called
it like star back. So thank you for being part of
this as well and coming back. So I got to ask your first
questions like, all right, so why are you back?
Why are we doing this episode? OK, excellent question to start
with. So first of all, because I want
to say that today authorization is a security decision.
If in the past we struggled with which method to implement and
even to even if to implement at all, that's no longer the case.
Today, authorization is a security decision.
Either you're secured or not and we'll see why is that.
I mean, that's a pretty simple, simple statement, but it carries
so many repercussions, right? It's like, OK, authorization is
really the crux of what identity and access management is built
around. You got to get it right.
So tell me a little more about plane ID.
For people who aren't familiar out there and the, you know,
billions of listeners and watchers that we have, what is
plane ID? OK, sure.
So Plain ID is the authorization company.
We are focused primarily on authorization, controlling
authorization, managing authorization, providing
authorizations. We have been focused in the
space for quite some time and we work with large enterprises that
trust our technology to manage and control their authorization
solution. That is, that's Plain ID.
And yeah, we'll learn more as we speak.
We're definitely going to learn more about it, especially sort
of like how does look in in sort of the real world and how it
works like architecturally right within an environment.
I got to ask though, how'd you come up with the name Plane ID?
OK, so you know how in identity and access management there are
so many aspects and it starts with maybe something simpler and
get so complicated. Authorization traditionally is
considered the most complicated area.
We wanted to simplify that and therefore plain IDAYID.
That's a different question, but still we wanted to resonate
something which is simpler, solving a complex problem in a
simpler way. Hello, it's a noble 'cause it's
a hard one to address because I think authorizations get super
complex sometimes, especially some applications.
What is it that you think makes plain ID separate itself from
others that are in the market? Because I know there's a lot of
different kind of vendors right in the authorization space.
You guys have been around for a long time at this point.
What is it that makes your solution unique?
As I put my jaded see so hat on like all right, create another
tool in the stack that I have to think about.
Yeah. So I believe it's the
completeness of the solution and I'll explain again.
Authorization, like I said, is the security decision, which
means it's not a developer's decision, it's eventually a CSO
decision. The authorization is meant to
represent what can be done within our technology space,
which basically translate into what data can be accessed, what
tools, what APIs, what services can be used, who's making those
decisions. Someone needs to make them,
someone needs to govern them, and that's typically
responsibility of the security. Plain ID places a lot of focus
on managing and providing visibility into those
authorization policies as well as enforcing them, providing the
tools, the means to enforce them across the technology.
I would say this is one of our major differentiators, our
ability to see, to capture that whole scope of authorizations,
not just one side of that challenge space.
So authorization stretches beyond just people, all right?
It gets into other things. So I'm curious, this is plain ID
addressing both, like customer identity, access management, use
cases, is it workforce? Is it both?
And then how does it get into non humans or maybe agentic and
things like that? Yeah, absolutely.
So first of all, the answer is all of them.
Why? Because they're all identities
that need access. That's the bottom line.
And eventually when you want to walk within your application
space, data APIs, it doesn't really matter to the data if
it's an end user, a human who's trying to access, or an
application user or even an agent user.
It's a user, an identity that tries to access the data or
tries to consume the API or whatever.
So an identity is an identity, by the way.
It's the responsibility of, you know, all those Ibps to make
sure the identity is there and it's authenticated and all of
that. But then what happens
afterwards? Afterwards those identities need
the right access for whatever they're doing.
And in some cases, maybe the combination of identities like
in the identity earlier there's the agent identity and the end
user identity. So you know very shortly all
identities count, all identities need to be authorized.
Hey, gal. I was so intrigued by what you
said about authorization having an important role in the
security stack. I was wondering if maybe you
could talk a bit little bit more about that and what what it is
that you're talking about? Yes, absolutely and thank you
for that question. So you know the market has been
investing a lot around managing identities whether human, non
human authenticating identities. So we have all those controls in
place. So our users are accessing the
applications or you know all of our technology stack after they
have gone through multiple multi factor authentications.
But then what? What?
How can we control what they can do, what they can see?
That's where authorization comes in.
It's like the last line of defence before accessing data
and accessing all those tools and services.
And why is it such an important topic now?
Because the change in the market towards identic flows.
That's when explosion of explosion of data usage, tool
usage, API usage happens and no longer traditional controls are
sufficient. We cannot rely just on having an
identity or having the identity authenticated.
Controls must be implemented in the right way.
So the need for those controls are tripled even then they were
before. That's why I'm saying it's a
security decision. Every organization is evolving,
evolving towards newer technologies, more specifically
the identic space and authorization is a crucial
component to secure that. So, Gal, you brought up an
interesting topic there, Just authentication, right?
And I realized that maybe we jumped right in because I think
this is a topic that, you know, authentication, authorization,
people get confounded sometimes or lump them together.
And I think you see it even with some of the protocols where like
the authorization data will get lumped in with the passing of
the token. You got open ID, you've got
Oauth. They're different, but unless
you kind of are an expert in those areas, you might get them
lumped together. Why is it that you think people
are? Maybe you could just kind of
start with the separation of the two, and then why do people get
them lumped together? Yes, absolutely.
So first of all, they should be lumped together because it's a
continuous process, basically authentication, right, Defines
who you are. But then authorization comes and
says what can you do? Now if we rely just on
authentication, it means who I am also carries what I do.
So I'm walking around with a bag of privileges, which basically
beats the purpose, right? We are now talking about 0
standing privileges, which means who I am is just who I am.
It doesn't mean what I can do. As I walk through in the
application, as I try to access data, as I try to consume
services, that's when I need to determine if that is is approved
for me in the context which I'm working in, right?
So there must be a very distinct separation between
authentication, who you are, and then the continuous process of
authorization. What can you do?
But what can you do in a specific context which you're
currently operating? It cannot be predefined, cannot
be predetermined. How, if it makes sense?
Yeah, perfect, perfect. Thank you.
And you know, Jeff and I often say, and not just because you're
here, right, is that authorization is having a stay
in the sun. You know, you see the Austin
Working Group, part of the Open ID Foundation, You see just so
many more authorization vendors and focus at the identity
conferences. I see you guys are still the
lead in terms of kind of like pushing this boundary.
But I guess my question is, why is it that it's so hot right
now? And I say that because you guys
have been around for decades, right?
I mean, we didn't really get into what year you founded the
company, but I feel like you guys have been around for most
of my 20 years in the space. And why is it that right now
it's getting this special attention?
Yeah. Well, first of all, maybe not
decades, but we do like to speak a lot, so we make a lot of
noise. But thank you.
I think the reason for the importance of now, why now is
the moment. It's because the shift in
technology authorization has always been the challenging part
of identity and access management.
And when it comes to traditional technology, it's complex, but
when we are starting to look at a newer technology, APIs, micro
services and now the identic space that when it becomes
easier to implement more advanced controls.
So that's the reason it's a hot topic now.
Additionally, has the technology progress as we see again, I'm
back to AI agents all the time because that's the hot topic
now, yes. So as we see AI agent operates,
what does it mean from technology perspective?
It means a whole lot of little steps that are combined together
to make something happen. And that means each and every
one of those small steps in the process need to be authorized,
not just authenticated, but needs to be authorized.
And static standing permissions cannot address that.
That's why the need for a true authorization system dynamic
context aware is is very very much relevant for this time,
which we are. So I think people are probably
pretty familiar with authorization, at least the
concept, especially when you start talking about humans.
I want to get specifically into like agentic AI because that is
the other thing that's so hot right now, right?
It's is there are this explosion of agents that are running
around sometimes amok inside of an organization with poorly
scoped permissions or whatever it may be.
Can you talk about authorization specifically in the context of a
Gentek AI and sort of how does plane ID help me address that
government, solve for it, things like that?
Yes, absolutely. So there are several aspects to
consider. First of all, who are we
authorizing when it comes to the agentic process?
We need to remember there are several identity types.
I would say first of all, there is the agent, of course the
agent, the agent identity, but there was also the end user
identity always at least, well sometimes just one, but there
can be two identities to consider.
So when we are authorizing an action or access to something,
we need to be able to evaluate both identities.
Plain idea of course can do that.
Second, when do we need to apply controls?
Looking at the full identic flow, we have multiple control
points to consider. It starts with a prompt.
So every process starts with a prompt.
The first control point is at that point.
Exactly. Can whoever is asking the
question or whoever is initiating the prompt actually
do that? According to the security
controls, in many cases people are talking about guardless.
Guardless tend to be very operational in nature, but think
about security guard. Those would be your
authorization decisions. So again, one the prompt second
data, an identic flow retrieves data whether it's via RAG or
whatever other means, right data feeds into that flow.
What data can be fed in the context of the end user identity
and the agent identity? Then based on the question, the
prompt, and the data, at least a process is generated.
The LLM is suggesting all of that, and then the LLM might
reach out to tools. You've probably heard of MCP,
the standard for utilizing tools in the identic space.
So again, the question is, can the agent at this point of time
use those set of tools or which tools they can use?
So we want to put some controls on tools as well.
And the last part of that is the response and response is being
generated. Maybe some of that response can
expose data it shouldn't. So we want to consider masking
the response plane ID today has the capability to control what
questions can be asked, filter out the data which is fed into
the process, control the usage of MCP tools and mask the
response that is sent back to the user.
So end to end control throughout the identic flow, and that's
part of what an advanced authorization solution needs to
do, cannot be done by just static permissions, needs to be
governed by policies. So you mentioned the, the, the
word guardrails and I've heard this a lot.
And I wonder because is it guardrails or is it more of a
railroad track? Because guardrails is kind of
like, all right, it could be a 2 lane highway, it could be a one
lane highway, it could be A8 lane highway with a lot of, you
know, swerve in between all that.
And I wonder do you have, you know, a, a, a different
definition or distinction between something maybe that is
from an authorization standpoint is OK, Is it guardrails or is it
like a railroad track or maybe a roller coaster track, depending
on you want to perceive that? Yeah.
I think, I think it's a term is that the market has started
using it's, it tends to be a more of a technical thing.
It is very common to implement guardrails for prompt control,
for output control. So we are, you know, we are
aligning ourselves with the way the market is currently
speaking. Basically it's a way to place
controls. So controls are placed in the
form of guardrails and they can be placed on the process that
throughout the process input output data and tools.
But I agree with the you know, the the the picture you draw
absolutely. Well, I think, you know, when
you have guardrails, especially when we're talking about agentic
and generative AI, you, you almost need some leeway, right?
Otherwise you kind of lose the benefits of having something
that's generating that. So I just kind of brought it up
because I was like, OK, well, I can see some people think out
there like, OK, well, shouldn't authorization be like a single
track or you can only do this one thing?
But I, I guess my, my next question is, is there a right
way to provide agentic authorization?
Because you talked about, you know, the question is, can the
person who is invoking the agent do the thing that you're asking
it to do? So if I write an agent, does the
agent mirror my permissions? Should it have its own set of
permissions? What happens if the agent
creates its own agent? And now you've got like this
domino effect of agents creating agents, creating agents.
How do you track permissions throughout that?
And is there a right way in your mind of kind of how to control
that? Yeah.
So yeah, I think you asked me just, I don't know, four or five
questions, but I'll try to answer.
I'm great at that. Yeah, absolutely.
OK. So first of all, you need to
consider all identities involved in the context of the operation.
So if there is an end user identity and an agent identity
that is currently doing whatever operation in the decisioning
process, both should be considered.
You can't consider just one of them.
Yes, an agent identity has authorization tied to it.
Yes, an end user identity has different set of authorization
tied to it. You need to consider that they
both have more than just what is needed for that specific
operation. And you know what that leads me
to? What is the right method to
control it all all and to manage it all?
You know how the IEM market likes to create new acronyms
every year, So we have a new one.
It's called Intent Based access control.
No, truly, this is a good. This is an important one to
remember eventually to do the right authorization in process.
You need to understand intent, and that means there is a
specific agent designed for a specific purpose.
Now, there might be a human who's using that agent or
another agent who's initiating that agent.
That's part of the intent. The second part is what are they
trying to do? And then the last part is why
are they doing that now? So in order to truly enforce is
0 standing privileges, truly enforce security controls in the
identic flow, you need to consider all of those facts, the
aspects you need and to understand the intent of the
operation and enforce accordingly.
So gal, you, I want to come back to intent based access control
because I think it's a fascinating topic, but I want to
key on something you said to, you know, to Jeff's question.
So first kind of the basis of my thought is a year ago we were
talking about I am for AI and essentially what it boiled down
to was like authentication to your AI.
And I was like, that's not very exciting.
But what you just said there was like, I was like, that's the
hard part. I mean, that is the really hard
part where you start talking about controlling what questions
people can ask. And maybe this kind of blurs
into the intent. But I figured the way I'd ask
the question is this is because you've talked about addressing
it with policy. And I'm wondering, you know, as
you talk about the solution with customers or potential
customers, are they presenting the same use cases?
Are you seeing the same use cases or are people each client
giving you kind of a a different set of use cases that hey, they
need to solve and policy solves that?
Yeah, So really excellent question.
First of all, I want to say this is across the board, every
customer I'm speaking with same challenges, they all want to
adopt agents. They want to enable the
organization to adopt agents. But then they need to do that in
a secured way and they need a way to govern all those agents.
I would even say many considered agent as a new type of
employees. Remember how I don't know how
many years ago we had to take care of our human employees?
And I am struggled around that and we build a lot of
technologies to solve that. And the, the thing about human
employees, they do follow some, you know, rebuild controls,
right? If we see a locked room, we are
part of an organization. We wouldn't just walk in there.
That's not the case with agents. That's that's really important
to understand. Agents are your new type of
employees, but they're very excited.
They are like junior excited and employees that are meant to
please. They are designed to provide you
with a solution. They will do whatever they can,
whatever is available to them, they would utilize in order to
provide a solution. And that means if they have,
they have more privileges they they should use, they can access
more data than they should use. They will do that.
And that would lead to either misuse of capabilities or data
explosion exposure. Eventually that's that would be
the reality. So that's why you need to treat
those AI agent as a new type of employees and apply controls on
top of them. But also understand that your
traditional solutions are not sufficient.
You need to apply the right controls here.
And back to your question, yes, this is something I'm hearing
across the board and speaking with a lot of organization, both
from current customers and potential new customers.
And they all have the same challenge.
How do I control all those AI agents?
How do I control what they do? How do I control what they
expose? Because data exposure is
certainly one of the biggest risk in this space.
Can you, I, I don't want to put you on the spot here, but could
you give me kind of a, a real world use case where you know,
people are finding like, oh, you know, applying these policies or
something I can really do to enhance the security of my AI
agents? Yeah, absolutely.
So, you know, let's start with very simple policy.
First of all, let's prevent exposure of PII data.
Just start with that. Any, I don't know, Social
Security number or numbers you don't want to be exposed or
whatever. Just start with applying that as
a general rule, mask all PII data from your AI agents.
Simple. OK, but other controls that I
see I see being implemented controls such as cross-border
controls. You want your AI agents to to
serve your all of your employees in your companies or your
partners or your customers, right?
But you want to restrict access to data from different
locations. Again, cross-border control.
This is one of the top compliance requirements in many
organizations. There's so much relevant here as
well because the same data exposure that you could have
gotten with previous technologies without a gentic
are still very much relevant to you.
If you have like, I don't know, MNPI data, again, exposure of
data. Don't expose data.
Take your most critical compliance policies.
Apply them at the beginning of your identic journey.
So you mentioned the intent based access control.
I'm not. I mean it kind of sounded a
little bit like it could be what you're talking about now or that
it could be something different. Which is it?
Yeah. So I think intent eventually is
a way to achieve that that target.
It's a way to achieve 0 standing privileges.
So we I spoke before about 0 standing privileges.
It basically means you enter the operation with nothing and then
at each step it is determined what you can do right?
That's zero standing privileges. How do you apply to 0 standing
privileges? With intent based access
control? Which is basically a nice name
of saying consider everything when you give an access
permission or reject that access permission.
Which means they consider the identity, both end user
identity, agent identity, consider what?
What they're trying to do, what they're trying to access.
Why are they doing that Now in this context, that's intent
based access control. So achieving 0 standing
privileges with intent based access control.
Yeah, and it feels like everybody is trying to achieve 0
standing privileges, right? Because when you have standing
privileges, if accounts get compromised, it could be very
destructive in your environment. My concern was your standing
privileges has always been how scalable is it?
Do you just kind of go after 0 standing privileges for your key
applications, maybe for your most critical apps or your most
critical accounts within those apps?
What? What do you have to say about
that? Yeah, I think that's a very true
question as the, you know, every organization considers because I
mean, you wouldn't want to change everything.
So yes, prioritize what you want to start with and then implement
a call, you know, implement accordingly.
That's why new technologies are a good place to start.
I mean, if you, we know we have done in the past bad
implementations, we didn't implement the sufficient
controls well, they needed to be right.
But now we have a chance with new technologies to do that,
right. So consider implementing as part
of the development process, as part of the adoption of new
technologies, meaning identity AI.
Deploy that with the right controls in place.
Don't do the mistakes, don't repeat the mistakes we have been
doing over and over and over again, which means let's deploy
our identic AI and then let's go back to security and figure out
how to fix it. Now let's not do that.
We know what we need to do. We have the market has a lot of
experience. We know we need authentication.
We know we need authorization. Going back to it is a security
decision. Let's make those decisions now
and start from scratch the right way.
Yeah, I think you made a great point there.
So if I was to put it into my own words, it would essentially
be you might the scalability part really or it's the effort
to go and do it for everything you've done the wrong way.
And not because we're we're dumb or anything, but sometimes the
technology wasn't there. Look, it's evolving quickly and
we all are under. But if we get that
infrastructure, if we get it right now and build it in bacon
as part of the deployment process and our our standard
security footprint, at least we'll get it right going
forward. So I think that's a great way to
look at it. You know, the other conversation
that often kind of accompanies 0 standing privileges was around
continuous identity, continuous authentication.
I wanted to get your thoughts on that.
Yeah. So I think the way I see that
and the way the market typically speaks about that continuous
authentication, continuous identity represents the process,
the identity. Any identity goes through a in
its digital journey, which means it always starts with a defined
identity, authentication and then authorization, right?
That's continuous because it doesn't end with authentication.
It's not sufficient to know who you are.
You also need to know what can you do?
Can you see this piece of data? Can you access that tool of API
right? Those are questions being asked
throughout the process and that's what makes the process
continuous. It starts with authentication,
it proceeds with authorization and and you know, that's
eventually what makes the full process secured.
I'd like to take this from theory to reality.
What does it look like when I set up plane ID in my
environment? Like what does this look like
architecturally? Is this an app that I run?
Is it SAS? Is it something on Prem?
How does this connect to my other stuff?
Like let's start with OK you've got me hooked gal, let's try
this out. Like what's next?
Well, first of all, I'm happy to speak with you.
Next step, we are a full SAS solution.
We do have hybrid components. Many of our customers prefer the
decisioning engine and you know access to data to be localized.
So those would typically be implemented as hybrid component
micro services, the design to scale design to for performance
and security. So setting up the tenant,
getting all those hybrid components in place and then you
go for a process of discovery. Once you have discovery done,
you can see all your ready to use policy elements.
What would those be? Well, maybe your database
tables. If it's vector databases, then
it's all the categories that define the documents.
If it's MCP or the MCP tools already categorized by the way,
so it would be easy to authorize them all your identities, of
course. And then it's just a matter of
connecting between the two, which are the policies.
Eventually policies connection between identities to what
identities can access and adding some conditions on top.
So you talked about this being a hybrid approach.
The let's start with the on Prem stuff.
You mentioned some things that that I have to install in my
environment to connect. Pretty common, I think for most
identity tools to have like some sort of proxy tool or
connectivity sort of server that they can use.
How does that work? Is it a virtual appliance?
I set it up and then it's scanning my internal environment
or permissions. Do I connect it to things like
SAP? Like how does that work?
Can't even learn more behind the scenes.
Yeah. So it's a containerized by the
way, it's an optional component, right?
You can do full sauce and it works perfectly, but you can
also choose that localized component.
It's a container basically micro service deployed however you
want, wherever you want, how many you want, by the way.
And it has the function of a discovery.
So it kind of scans whatever you want it to scan to fetch the
elements. We call them assets.
So those would be all protected assets, feeds them into the
policy platform and then it supports enforcement and
enforces data that would typically, and again, this is a
bit of a technical jargon, so excuse me, but it includes APDP
policy decision point, VIP policy information point that
that's the component that connects to the data sources.
And in the enforcement components, we call them again
in the regular jargon, PEP policy enforcement point, but we
like to call them authorizers. And those are components per
technology. So for API gateways, the cycle
for your service mesh, whatever library for your development
platform and so on, we have many of those available.
So how does this work from like a real time scanning or you
know, set up right permissions change all the time.
Are you detecting changes at the of permissions within
applications and then pulling those into plane ID and then the
PDP or PEP? And now you're speaking
language, right? Policy based access controls,
right? Those different terms.
We've got a technical audience, right?
They're probably flying along, but how do you stay on top of
things that might be changing an environment?
Is this scanning at real time or is it like once a day, once a
week? Or is it like on demand?
It's, it's on request actually. So we have the PIP component I
mentioned before. It has the ability to connect to
data sources. So let's say it connects to your
IGA platform or maybe to your HR repository or maybe to
certification system or to all, all of the above, right.
It pulls data in the real time at the time of access.
So let's say you're trying to access an application or
database or whatever, right? So we can see that now you are
defined as an employee in this department and you know in this
region and make the decision accordingly.
So it's true real time decisioning process according to
a set of attributes which are out there.
We are not replicating any data, not only for caching purposes,
but that's on the technical discussion.
So we are just pulling data when the data is needed to make the
decision. So if I think about this from
like a, a UML diagram, right, with things bouncing back and
forth, I'm doing the authentication against my IDP
and then I pull it back and it's like, OK, now where does the
policy based authorization component come in?
Is it as soon as I try to authenticate or is it when I try
to reach reach a specific application?
How does that chain of events occur?
OK, so there are multiple patterns to to follow the first
pattern. I'll try to quickly review some
of them. So the first pattern is yes
during authentication process. So when the IDP creates the
authentication token, it is possible to reach out to the
policy decision point to get a list of authorization values
like claim keys, claim values and so on.
This would be enriching the token.
That is typically called a token enrichment pattern and it is
part of login time authorization.
So one pattern. Second pattern would be at your
let's say API Gateway. So whenever there is a
transaction through the API Gateway, the transaction is been
is been evaluated against the policy with the addition of
attributes as much as needed and then the transaction is either
allowed to proceed or blocked. Another pattern would be an
application trying to access a database.
So the application sends a query, let's say it sends select
all form table, no boundaries at all, no controls.
We capture that and we add those controls according to the
policy. So select all from table, but
where location equals user location or whatever you see
that's an example. Dynamic authorization can be
positioned in all of those different locations.
And there are other patterns as well.
Didn't mention mention all of them, but we start with very
coarse grained plug in time to be governed by policy to provide
decisions dynamically and we go all the way to very fine grained
at the data level. So low level filtering and
column masking. I was reading your body language
there, gal, when when Jeff was asking that question and you're
like, oh, you want to go deep? And that was a great question.
I'm sitting here enjoying the whole thing.
My question is a little less technical, which is kind of from
what you see with a typical customer approach.
Is it they want to start off with one application or kind of
how do they look at like I want to kind of test this and proof
of concept or you know, I want to get my feet wet before I dive
completely And so how do people start?
Yes. So yes, typically with one
application, maybe 2, but you want to start, you know, small
because you want to see value as quick as possible.
Let's say you want to start with an API use case.
So just get your Swagger file, open API spec, whatever, send it
over, it automatically maps to the policy elements and start
enforcing policies. This is, by the way, with no
change of code. It's so simple to implement.
And there you go, you have your final.
Controls at the business logic level, not just at the API
level. Let's say you want to do the
same with the data control. So it's a matter of discovering
data structure, leading that into the policy, what we call
policy building blocks and start building your policies.
Obviously some implementation processes are more complex than
other. No magic in technology.
I wish they were, but no, that's not the case.
But we are trying to make it as simple as possible.
So back to our company name, plain ID.
We are trying to make authorization as simple as
possible so they will truly be implemented where they needed to
be. So can can plain ID replace or
centralized authorizations similar to how a lot of a lot of
organizations might use like Active Directory groups, right
as how they authenticate or I'm sorry, authorize into
applications. Can plain ID act as that role?
Or is it more on the policy side and relies on authorizations
existing within an app? Can I shortcut essentially and
say, OK people stop building your own authorization and let
me centralized that and manage that for you as part of my IM
program? Does that make sense?
It actually makes sense. And yes, I do want to repeat
that people, stop building your own authorizations.
There are authorization solutions such as plane ID,
Start using them. You don't need to build it by
yourselves. However, it's not an Active
Directory on it. And try the replacement, because
what you, the example which you gave is providing users with
roles or with group that is always still needed.
Policies, authorization. In general, they do not replace
roles. They do reduce the need the
amount of them, but they do not replace them.
Think of the role as an addition attribute on the identity, more
information. Typically the information which
identity holds is limited to, I don't know, job title,
department, location and that's it.
It's not sufficient when it comes to making decisions on
which data you can access or whatever, right?
So that's where roles would come in or other ways of enriching
user data. So those would be all fits to
the policy. So how do your customers
typically measure that they're getting what they paid for out
of this right? How do they measure success with
the solution? I would assume faster, more
streamlined, more secure authenticate authorizations.
But are there other RO is that people look for when they say,
OK, we've got plenty of D? Here's how we justified the
spend. Yes, absolutely.
So there are multiple metrics we can share.
But you know I want to show one example.
We have a customer which is a global bank and they implemented
the whole like online back banking controls with plain ID.
They used us at the API Gateway level, several API gateways and
initially, you know, like every new technology, there is some
resistance, don't know if that's the right solution and so on.
Today they're at the point where the developer team, the
application team, they are excited to, you know, send the
APIs to the security team. Here you go.
We want to deploy this API just logging to your policy and
that's it. So it really reduced time to
market for them. Every new API doesn't need to
consider who the identity is. Does this identity can see this
data? Whatever.
No, they will focus on business logic they had to develop and
all the enforcement was done by plane ID together with their API
gateway in a very simplified way and it really helps them in
provide faster value to their business.
Well, actually kind of let off the episode, right?
Authorization is so hot right now.
So I feel like we need the Zoolander memes, you know, in
full force here. This has been a great
conversation and I would definitely encourage people go
check out planeid.com/IDC, right?
And check out what is going on there.
I think you wrote a blog on the intent based access control.
And so I think that'll be on that page of people check out.
You know, there's, there's so much to unpack here, but
hopefully this gives people kind of a sense of what they should
be thinking about. So I want to end the episode on
a little bit of a lighter note. We actually started to nerd out
very, very slightly before we hit record when you mentioned
that you're into science fiction and reading and things like
that. And I am as well more on the
listening side, the reading side.
And so I want to ask you for either a recommendation for me
or other people. I know there's a lot of sci-fi
readers out there. What's the best sci-fi book that
you've read within the last year or so that people should be
checking out if they haven't already?
OK, we'll continue that discussions for sure.
So I want to recommend an old book, Isaac Asimov.
So years ago I really enjoyed reading those books.
I read them in cycle and everything that's happening now
with the identic stuff made me go back to this to those books.
The the one I just completed is Cave Caves of Steel, the first
in the Robert series, I believe. I really recommend reading it
again and the full series by the way, because it's really nice.
You know, he saw something that's happening now.
He saw that years ago. A lot of the stuff that he was
writing about, I mean, people that are not familiar with us in
all would probably say this is not sci-fi, what are you talking
about? But it is, it's truly is.
It was written like, I don't know, 40 years ago, something
like that, maybe more. So it's really interesting to
see the way he thought and how he thought technology would
evolve, and especially what truly happened.
And maybe, well, things did not happen as he predicted.
And by the way, you know what's so intriguing about Tasimov?
When he wrote the robot series, he actually placed the the free
robot robot robot rules, right? So he actually defined robots
with guardrails. By definition, that cannot be
overcome. Obviously, as it evolved,
another rule was added. But still, it's really nice to
to go back to those books. So you mentioned Asimov and I
and I feel like anything can be science fiction if you put your
mind to it. But the Foundation series is one
that I've always enjoyed and and now Apple TV has a series on it
which I think is great. Not sure if you've checked that
out yet, but Foundation is is definitely a good one too.
Have you ever read the Bob Averse series of books?
Not sure. OK.
So this is one of my favorite series I think of of all time in
science fiction. And it kind of follows the story
of essentially an agentic AI and space exploration and humanity
and all kinds of stuff. So if you like that sort of
thing, I'm going to recommend the Bob verse.
Shout out to my friend Aspen. I know he he's read it as well
and I think there's like 6-6 books in the series and it's
really kind of a really cool, I don't know, interesting
approach. I just really like, I know I've
talked about before on this show and other episodes, but Bob
Averse, BOBIVERSE, Bob Averse are the ones that that I would
check out. Jim, how into sci-fi are you?
Because I don't I, I feel like you're not so much into the
sci-fi side of things. Not really I, I feel like I'm, I
feel like I live in sci-fi or that, you know, in the next few
years with everything that's happening with AI, how quickly
it's going, moving toward AGI, everything that's happening with
robots and self driving cars. Think about it.
I mean, we're of the generation where we grew up and we actually
would watch black and white TV sometimes or we had color TV,
but most people didn't have like color TV's in every room with a
flat screen. And you know, so I already kind
of feel like we're living a sci-fi a little bit.
Now. I do want to send a shout out to
one thing. So it's not a book that I've
been reading, but are you guys familiar with Simulation Theory?
That the fact that we might be living in a simulation.
Yeah, exactly. I mean, that, like, makes me
wonder, like, OK, well, things can't be that bad if we're just
living in a simulation. Well, I mean, it depends on
simulation. The entire story of the Matrix
is essentially about living in a simulation.
And if you follow the Matrix closely, which I do right, there
were many versions of the Matrix.
The first was, you know, ideally a utopia, and everyone was
supposed to get along and the human mind rejected it, so they
went the other way. So who knows?
Are we there? I went out for a walk last night
and there's somebody who has like a bunch of jeeps and stuff
and they have all these Star Wars stickers and one says Sith
security. I'm like, I know that Star Wars,
but I have no idea what it is. And I kind of thought at the
time it might come up in the podcast today.
So I just wanted to let you know, like, I'm not into sci-fi.
I've never seen a Harry Potter movie.
I've never seen any any of those things.
Well, first, we're only. Only a SIF deals and absolutes.
So that's your first mistake right there.
But shout out to that that bumper sticker.
I think that's a great one is I'm getting the sense, Jim, that
like us recording this podcast virtually is about as sci-fi as
you get that fair. I mean, that's pretty sci-fi,
right? I mean, could you imagine having
done that when you were, like, a kid?
We used to, like, record into tapes and splice it.
Or you'd sit there and you'd listen to the radio station and
hit record. When a new song was coming on.
If it was one that you wanted, you keep recording.
If it wasn't wasn't, you'd rewind and try to get right to
the point on the tape. I mean, think about that to
where we are today. I mean, yeah, we're living in
sci-fi. Demure and old man, you're
talking about black and white TV's.
You're talking about making mixtapes on the stereo.
Gal, I don't even know where to take like the rest of this
conversation. Any comments for you gal before
we close out? No, it's, it was an excellent
discussion. I'm happy to catch up on that
sci-fi book recommendation. You know, next time we'll meet.
But thank you for hosting me in this episode.
Absolutely enjoyable. Well, we appreciate, Yeah, thank
you so much for sponsoring and definitely get the get out on
the website show support for Plane ID, who's showing support
for us here, planeid.com/IDAC. We'll have links in our show
notes for that as well as gal to your LinkedIn profile.
So people who can reach out either with sci-fi book
recommendations or questions around anything BAC or maybe
even AC access control at this point.
Certainly appreciate it. So for that, we'll go ahead and
meet it for this week. Thanks everyone for watching or
listening. You can find us on the web
idacpodcast.com and we'll talk with you all in the next one.
You've been listening to Identity at the Center.
We hope you've enjoyed the show. Make sure to like, rate and
review, and we'll be back soon. But in the meantime, hit the
website at identity@thecenter.com.
See you next time on Identity at the Center.