You're listening to the identity of the center podcast, this is
the 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 of the
center podcast I'm Jeff. And that's Jim.
Hey Jim hey Jeff, how are you? Oh not so bad yourself.
I'm doing good. I've been super busy lately but
I look forward to this time each week where we get the just talk
about identity and access management.
But yeah lately I've been working on you know preparing
for a lot of upcoming events. I'm helping out Mike angle over
at one Cosmos with webinar. It's To be on what?
What happened to MFA? I don't they tried to fix
passwords. How do we fix MFA?
And so it's like kind of one of those topics that is getting a
lot of headlines lately, especially with some of the
things that have happened in the news.
So anybody who's interested in attending that webinar, it's
going to be on September, the 22nd at 1 p.m. eastern time USC.
I'm I should say and you can just go to one Cosmos.com to
register for that event. And like I said, it'll be Mike
angle CEO of one Cosmos on myself and on top of that, we've
got the authenticate conference which is the Fido Alliance
conference coming up in October and then the OCTA octane
conference which will be in November.
So, hopefully will be blessing through a bunch of additional
podcast episodes during those conversations.
Such as well, but I'm also hoping to be able to actually
sit in on some of the sessions because if you check out the
agendas of the conference's, it looks like a lot of good
content. Yeah.
I have not holding my breath especially because we're going
to be at we will be authentic 8, 20, 22, and we'll be doing
podcasting and you're a total slave driver when it comes to
booking guests. So I end up sitting in a room
somewhere recording and editing while you're out gallivanting
with the identi Rowdy but I am hopeful that I will have some
free time from my podcast Overlord here, to get to, you
know, take in some of the sessions at least it.
Jeff. I think this would be a good
time to tell the story about authenticate 2021 because again,
I pretty much tried to do the same thing to you again.
Yeah, well I mean the story is is it's a story as old as time,
right? Jim volunteers to give a
presentation at a Pattaya at a conference.
I'm like, yeah, I don't want to do it.
I will go and support you and you know, help with the content
and kind of stuff like that. And go cheer you on flash
forward to the day that we're flying out.
Jim Jim calls me sick. He's like, yeah, like you
probably shouldn't go. This is the height of the height
of the pandemic, right? If you're coughing, you probably
have covid or at least, that's what ever is going to assume.
So I was like, all right, well, I guess I'm given given the
given the, the talk at the conference which I did and you
totally left me high and dry and I will never let you live it
down. And you continue to volunteer
for for speaking engagements, and my fear is that I end up
having to do it by myself around or something like that.
Yeah, well hey, I was just appointed to because I had
gotten upgraded to first class it was the day before and then I
guess you're most concerned about was that was what was just
worried about. Not the fact that you had to do
the presentation by yourself and by the way I did submit a
question for you to answer. Yeah.
What is I? What is I am?
That's a running joke. We always have whatever company
we have to be working with. Yeah, so we got a bunch of
different things going on. We've got, you got the one
Cosmos webinar you'll be doing. I'll put a link in the show
notes so people can you know if you if you support the podcast
go support Jim I can't make it I'll be on a flight so I'll be
probably listening to it either on the flight or catching it
afterwards but you can register I'm sure they'll be a replay for
that will be assigned a Kate's 2022 in Seattle in October so
hopefully I will get to meet some folks there as well and
then we'll be at the Tain conference at least that's what
we're planning on in San Francisco in November
potentially doing some more podcasting and talking with
interesting folks in the identity world and sort of kind
of covering that event and ya doing that kind of thing.
So I think that's a great segue to lead into our guest, who is
from OCTA. We'll get to that.
His name is Andreas. I gr he's the product and
Engineering leader with OCTA. Welcome to the show Andreas.
Thank you, chef and Jean. Very happy to be here with you
today. Hopefully, I didn't butcher your
last name, too bad. I tried to try to try to get as
right as I can. But you're also joining us from
a country. We have not yet.
Spoken least. I haven't ordered way.
So thank you for joining us from the the southern hemisphere as
well. One of the things that we like
to get into when we have a guest on.
For the first time is to really kind of learn the origin story.
How do people get into identity kind of helped set the context
of kind of your perspective? And And how you approach things.
So I think that maybe to kick off this conversation before we
get to our main topic, which is going to be around fine, grains,
authorizations or fga. Tell us a little bit about your
identity back story. How did you get into its into
this field? Is it something that you chose
or did the identity World? Choose?
You okay. Yeah.
So I mainly work in companies that build developer tools to
become a pro products in the past and so that's my main
background and they always work in.
Those kind of companies and the and five years ago, I had the
opportunity to join dog's ear. I knew both co-founders one
information Tina, which is very close to your work, both from
Argentina, but one of them was working with us and then I have
a chance and I'll see you had that interesting blend of being
a company that Target developers, but also working,
but identity. So I kind of got to identity by
the development tools are the relevant product.
World and and I quickly got into the core of zero.
So building the log in and MFA flows as a product manager.
So I had to get up to speed pretty quickly.
I've been working this domain for almost six years already.
So yeah, that's my journey to Italy, and in the last few
months, I moved to work on the authorization side.
And that is what campus brings us here today and I dress, I
have to give a shout out to My pastor, who is your colleague
from actor and by the way, for anybody who's listening, he's is
a great follow on LinkedIn, and he'd be more than happy.
I think to connect with just about anybody, but he introduces
to you and introduce this idea of something that you're working
on, F G, A fine-grained access. Our fine-grained authorization,
and authorization is such a big topic and identity and access
management. Judgment.
And it's something that people tend to get into as they are
further along in their Journey. So what I thought we could
basically start out with was kind of a 101, you know, talking
about what is authorization. And then one is fine, grained,
authorization, sounds good. So it's basically going to use
authentication and authorization.
So let's start by talking about both authentication.
In general, is to tries to prove that you are.
Specific person right in general.
They kind of, you kind of prove that you are specific person by
logging into a site. But basically, what you're
proving is that the convention that you still have access to
the same credentials that you use when you register for that
site, right? So if I had a phone number a
password email I still have it and I can still provide it as a
proof that I'm the sick person who logged in the encourages to
the site. So authentication authorization
of the other side is More. What are the things that you can
do once you login to that site, right?
So the permissions the actions that I can perform can I perform
this specific actionable specific page or resource or
document that is more about authorization.
The permissions you have your system.
The, for example, that now Twitter, you some people can
reply to specifically, right? So depending of how you treat,
you can say, all the people who are mentioned can reply to the
street when I login. To Twitter and we authorized or
not to reply to a tweet depending on those authorization
policies that Twitter specify in their application with find a
notarization. It's in general, when you or the
initial ways, we implemented authorization in the industry.
Where course training, mainly role-based Access Control, when
you basically decide that. Yeah, this is specific.
We can perform these actions and the actions are very generic.
Like, for example, post a tweet or deleted, tweet, right?
And but it was not posses not possible with role-based access
to specify things like a only. The people who were mentioned in
the Tweet. Can we fight between?
Because it's not enough to say the role you have to order to
decide if you can perform the action or not, right?
So depending on how groundwater the permissions that you need to
specify in your system, you You might need to implement
fine-grained authorization model or a coarse grater.
Authorization model like role-based Access Control.
Yeah, now that's a great introduction.
One of the things that I find is that, you know, sometimes people
get tripped up on, you know, how to use a term.
So, the term rolls gets used by so differently by so many
different folks, and so many different contacts.
Sometimes this product specific sometimes is You know, the
generic term of roles. So you know, using that one term
differently. But then there are other
situations where you have two different terms but they get
confused or used in place of one another.
And for me that's the term authorization and entitlements
and I'm wondering if you kind of help us differentiate between
those two terms. Actually this interesting
because you mentioned this question in our previous
conversations and I say it's hard to explain, right?
So I was trying to try to think a little about how to explain it
and the because at the end of the day it's they are very
related. So entitlements are the things
that the traits of the properties that the user has and
based on that, you defined, if the user is authorized to the
perform an action or not, right? For example, the fact that I
belong to a role is an entitlement.
The fact that From a user, can perform this actually they
belong to that role that is authorized and authorization
code, right? And in general, entitlements can
come from two places. One of a kind of?
Yeah, the themes that you are allowed to roles is an
entitlement, but can only be can also be like a, you are, you're
using a B2B sus product, you're using like the basic tier, the
basic tier can only use some features, okay.
That's also an entitlement, right?
The features that I can use as a users of the Product.
So, there's a lot of things that can that feel like they fit the
profile of that user, that are properties of the use of that
can be, then used for making authorization decisions.
Yeah, here we have a similar question that we did an episode
on similar in style which was what's the difference between
digital identity and identity and access management?
And it's like you know it's actually a deeper answer and
everybody answers it a little bit.
Ali and for me with the entitlements, in the
authorizations, like entitlements are the data and
authorization is the enactment of that data and you know, I
made up that term enactment and then what I realized was you
know, the terms are very important and I kind of thought
back when was thinking about authorization to the exact Kamal
standard, right? I mean that was like that.
Was it for authorization back. In the day and everybody thought
like okay that's the shift that's going to take place.
I wonder really what ever happened with exact Moses still
important are people still you know, does it have a future?
So that's my first question. My second question is, you know
what I liked about exact Mo was that it defined certain roles
within authorization. So you had your policy decision
Point, your policy enforcement point, So, if you think about
it, those are are very important.
Like we're, we're in the chain, are you deciding whether or not
an authorization should succeed? Where are you enforcing that?
Do you want to do that from a central location or within the
application? For example, policy
Administration point. So all of those different roles
have, you know, exact definitions.
I'm wondering when it comes to like the fine-grained
authorization or An authorization in general.
Are those roll names even relevant anymore?
And then, you know, I know, I'm asking a lot of questions.
All combined into one question here, but, you know, I think we
just need to know about this. Like the I am practitioner level
like, what do I actually need to know?
This isn't really like the developer podcast but like, if
I'm somebody who's implementing, I am systems.
What is it about these Concepts that are still relevant today.
But the so I will Sandeep. Into identity when accessible
happens. So I don't know what are the how
it began to become a think I can.
It fair based on the context. So the moment most of the
industry was building XML based specifications for everything,
right? And and, and certainly helps to
Define specification for doing attribute based access control.
That was it, something still very relevant right doing
achieving Basics control, and there wasn't a standard way of
doing it. So excitable specification, try
to feel that boys, and I think that's why it's important to to
Define standard that he had killed people amend this in a
way that is interoperable and, and that companies can use
consistently across different vendors in.
I haven't seen picking it up a lot of steam.
So there's there's a few companies that implemented that,
but if they didn't become Real standard that is widely adopted
by. It is a regular standard but
it's dot divided of industry and the.
And, and right now, for example, in 0dr, we are implementing
motorization products that are not using such as a way to
specify permissions and the industry they're having other
approaches. There's a product called open
policy, Asian that is very successful in managing
permissions for for infrastructure things, right?
Yes, that That defines policies in a different way and it has
become like a de facto standard for defining.
Authorization policy is not context and the, and it's not
using exactly, right? So, so from that perspective, I
think it's is that was an interesting attempt by the
industry, but we didn't pick up enough or they have enough spare
an option to to be significantly less relevant.
Today, that's my personal opinion, the in the Like, the
different enforcement different enforcement Point decision
points that exactly Define those concepts are still relevant.
So, there's a place where you need to enforce your physician
policy and it can be in the application can be in an API
Gateway, and then, whatever you decide you can be in an API
proxy. So it'll be a different places
where you can decide where you want to call the code.
That is going to enforce the policy.
Right based on to decide if the user can log in or not, right?
So you have elected enforcement point, which is, yeah, if I'm
building application in the chat with just with code, I will be
at the beginning of my API implementation, right?
That is the case. I will be checked if the
provision in the users permission to perform the action
about, then you have the decision point, which will be
okay if I'm using an external eyes for Lizzie.
And Jane, I will call at that moment, a different service that
is going to tell me. That is the use of company from
the actual amount that will be the only decision point for him
and that if I'm building an application with without an
externalized addition policy Engine with vision point is
going to be also in cold right? I wanted right myself like after
in the same routine that I'm checking the user can perform an
action, I'm going to ask you to use a positive role, right?
And that will be the decision party will be in code so it can
be different places depending on how you want to architect your
And other Concepts, they are our Administration.
There, only thing ministration point.
If you are using a product that policies are not in cold, you
need a way to manage those. Right?
That's still the case, right? If you using any service to
manage to manage your voltage protection policies, you need a
way to meet and to manage them right before we see a nutrition
point, and then you have the policy information point, you
need data to make those decisions, all right?
Who's going to get that data? Okay, that's to all of those
Concepts still exist in a simple app.
They can be all in the code, right?
But in more sophisticated architecture where you want to
decouple those things. Yes, those are going to be in
the in different services that can manage sometimes all of them
together, sometimes one for each of these points, right?
You may have a tool to - fall into the nailer to do to handle
the data and another to handle the decision and, and the so
yeah. DB still relevant and useful.
To reason about how authorization is implemented on
a protected in the system. Yeah.
So when you're putting together that architecture diagram of how
you're doing authorization those terms and kind of identifying,
those points are so important. Yeah, have a kind of a long
history in the access management side if I and kind of thinking
about how a lot of access management systems Worked, you
know, pre-op. Today's right.
So, it was that were coals and site minders.
And the most commonly used integration pattern was you
would install an agent. A filter on your web server,
your Java server or your is server for example and it would
filter requests every HTTP request and those systems became
good at Kind of coarse-grained authentication which was that
the level of you know, this subdirectory or you know,
basically using your L filtering like you either have access to
it or you don't which kind of led me to my next question,
right? Because that's not the way
applications are built today at, all right, through there,
primarily using open ID, connect or summer, using sam'l, but it's
still ultimately. Order to get to that that level
of fine-grained authentication or authorization.
I should say, is generally, passing data to the application.
And the enforcement point is that the application Level, I'm
wondering with fine-grained authorization, you know, is it
dependent on any of the specific authentication Technologies or,
you know, like sam'l or Nid connect like is f, g, a
required, requiring one or one of those standards to ride on
top of and then ultimately is the data that's coming from fga
taking over any of the like decision point or enforcement
point, or is it still coming back to the application to
enforce? Okay, this person has access to
this button, I'm going to show them the button.
Cetera. Okay, so when we talk about ABC,
a there are kind of two main ways of implementing a ga one is
called a buck attribute based access control.
And the other one is called agree.
Back relationship based at this control and in both cases, what
you end up relying to is on an identifier that you get from
whatever way you ended up knowing the into the application
if you are using On ivp. Who do I?
DC, you're going to get subject from the ID token or the access
token, and you want to use that as the user ID, right?
And then you're going to, for example, if you use a back, a
bike is activates as a control and you're going to probably
required data from your database to decide if the user can
perform an action. So let's say you want to
approve. You have an endpoint that you
want to approve if a user can verify for you.
So kind of An expense report, right?
So the usage standpoint is approved to support.
You need to check that the user has permission to do that.
You will need to know if the user can directly see if expense
report, not any extension cord to do that.
You need data, are you need to know?
For example, is the, the person who submitted the expense report
is, is a direct report of the person, who is approving.
So that could be a huge skate, right?
So I can only approve expense reports from my direct reports.
Need to check if the in the submitted of that expense report
is a direct report from the user that is submitted, I've proven
it. So the to do that, I go to the
database, I get the data and the and then I decide if I want to
let the user approve, the expense or not, you know, that I
get the user ID that I got from the ID token.
And I go to my bed, I use and find if that user ID is the
manager of the submitter of the report.
And if that's the case, then I let him go.
So from that perspective is I'm you doing fighting for position
and relying on whatever user ID was provided to me, that's fine.
There are other ways to implementing regulation with
like relationship based Access Control those.
The, their active products try to do that today and mostly
inspired the implementation by Google called Google design
similar. So, Google's published a paper,
how they did their internal authorization service which was
called groups and simmer. The We got works, is you
specified relationship between different entities.
So you can say this user is the manager of this under user, this
user it was the submitter of this country port and their use
the user ID is that were provided by your IDP, right?
So in any case you are bound to specific authentication method,
you can use any way to authenticate and still do fine
game creation with a vac or with relation babe.
Three back, right? So both work does the
application development need to be developed with fga in mind,
or can you take an application that was developed previously
and integrated into an f g? A based framework, if you think,
especially as a generic term then and let's say you are you
have an application built with role-based Access Control,
right? And then you have this is an
area where you want to approve the expense on If the user
disapproving, it is the manager of Gregor submitted a report.
The you can just do an extra query in that method, right?
And and then then you're going to have funding for Education,
okay? So find Reference Station is
kind of, I don't rely just on role-based data.
I I need to know data about the specific resource.
I'm Changing or an actin on to make a decision.
So from that perspective, it can be usually most role-based
interpretations today, end up doing some kind of a back
because at some moment, they need to make a decision about
the specific resource of the Pacific record that the user can
access, okay? So from that perspective, is
there's nothing to change and it's it's a way to gradually go
from role-based access to attribute based access by adding
more queries on your product. Now, if you want to build a more
sophisticated instrumentation of attribute based access control
and you want to do, for example, a policy based Access Control
where the definition of that access policy is subsiding
product at some of the code then, yes, you would need to
architect your application differently.
The find operation policy somewhere else in an external
tool or product, right? And then from your code, call
those policies that implies. Yeah.
You can do that gradually. But it's a Change on your
application. And that, if you are using a
product that is relationship based access control, the weight
loss product works, is that they need the data of how users are
related between themselves and with the different entities to
make a decision. So, you know, so you need to put
all push all the data from your existing systems into those FCA
stores, so then they can make the decision, right?
If you that, and that is that also, Quite see ya thinking with
that way because requires a lot of work to get all the data in
that system, to then be able to call it and that we low latency
from your endpoints, right? I think that's where it's so
data. Dependent sounds like to me and
you can feel free to educate me on this, but I think of things
like our back P. Back a back.
We talked with K back, knowledge base with indication you
mentioned reback, relationship based authentication, which
maybe is the same sort of thing. We settled on a acronym for it,
but the underlying pinning for all this is the quality of the
data and the amount of data to be able to make those sorts of
decisions. Judging by the name
fine-grained, you know, authorization, I'm assuming that
we need to have a lot of, you know, metadata to be able to
make these sorts of decisions. You mentioned the ability to
make these decisions and more real-time format, which I think
is kind of where the direction of a back typically goes.
We know about, A lot of struggles that organizations
have with our back and trying to get roles implemented from your
perspective. Where do you see f g a kind of
fitting into that world of you know, organizations.
They say they want to be role-based Access Control.
Okay, great. And then they realize how hard
it is and they sort of like stumble through it in the maybe
they settle on attribute based access control is fga.
Basically taking attribute based Access Control to the next level
by having just more. To be able to make those
decisions. Or does it fit somewhere else
within that sort of that ecosphere, of different
authorization models? Yeah, so just to clarify their
interview. So attribute based access
control is at GA, okay? So, because it's not coarse
grain in the sentence of all only talking about the roles
you. When you talk about an
attribute, then the ultimate can be as like fine grained as the
specific document. So you have a permission for a
specific document, you can build that with a bat.
Fermentation, right? If you want to use a VGA with re
re re re back implementation relationship-based, then the
Reebok ancient, we will need all the data to make the decisions.
So maybe explain a little more, how that Reebok works and
decency. Work mode works to this to make
more sense. So the way through Google had a
problem back in the in the think they did this initially for
Google+, which I It's probably early 2010, 2012, something
around the date, right? And they decided they want to
build an externalized, Sprite to manage population, and they end
up building service that they use for all products in Google.
So each time you share a document in Google with specific
person, you are writing a feel at beta, some data into the
Sunset Bar annotation and why what it needed to do that for
two reasons. First, they wanted to have a
consistent isn't way to define a manage authorization across
Google for all products. In most cases, what happens
today is like a URL to a company.
There are 10 20 teams they need to build for ization.
They do it all your different way and the and in this case,
what we will say is we want a consistent way, same apis, same
thing where you thinking for all of our teams, okay?
And and then, they also needed to scale for Google Docs and so
each time you Of P permission to someone that if someone else
wants to access the document that needs to be very fast, very
low latency High availability, right?
So we need to build product that help doing that.
The issue with a back is that in a but you need to go and get the
data yourself. And it's usually happens in your
existing transactional databases, right?
So I want to know who is the manager of the this user need to
be two. Adjoining some table, right?
Check the expense report data. I'll look at the expense report
tail and the and make you thinking for World up, like a
service calls, another service, we could go to another service.
Each of those areas need to do the same.
Sometimes the same database queries, something different,
sometimes the different services, that adds a lot of
latency, a lot of potential points of failure, like any of
those Services down, there is very low impact that API call.
So, what Google said is to be able to make those decisions in
a way. That is scalable, no, latency
and reliable. We need the data.
So we cannot rely on the developers.
Only Kermit people who's implementing this, go and get
the data. At the moment of evaluation, we
need to have the data before. So, what they Define, it's a
model where you provide to us and see our store.
Tuples that basically say this user is a member of the strong
this user can write this document.
This role can write this document and things like that,
right? This group can write this file
into this folder so they are policies, permissions that you
assigned to different entities into different resources.
And based on that when you need to ask can chef at this document
it will say yes or no yes or no, depending on the folder, they
were comedy is the group you are the road, you have the
organization, you belong to things, right?
And that so that is that I could be like, a bit
relationship-based, FC, a model and which is the That I'm
working on in after and the and then there's a few people trying
to build the same kind of intimidation, right?
Which is trying to solve that problem and that problem
requires the data and then one of the problems of people
amending a solution like this is that you need to get all the
data into the store which might be challenging depending on your
architecture, your project. It sounds like what you're
describing to me. Sounds awful lot like a
Knowledge Graph essentially. Yes, and building a centralized
repository of all this data is that the is that the gist of
this? Is there needs to be some sort
of Central master database, table, graph, whatever
technology, right, as being blockchain, as much as I hate to
use that word, right? We're all this data is basically
stored centralized kept up to date and then leveraged as the
Of source for these sorts of decisions when it comes to
authorization is that? Yes, and accurate way to portray
it. Yes.
And I need to know that we need all the data, right?
We just need the minimal data possible to make this analysis
of decisions. For example, recognition know,
back, when I need to know this document ID is is in this folder
ID, right. I don't need to know the content
of the document, the title document, nothing else, right?
So chefs there. The IDS of the relate of the
entities and how they are related with right and the and
with that you can make good decisions in a way that is very
fast. Scalable glorious event.
And there's so that that is what what?
And that is kind of the the new kid on the Block right over, how
to build authorization today and what what, what is a lot of
companies are trying to implement this after Google, did
it? There were a lot of other
companies that try to do similar things.
We like, BRB Expedia car that they are all, give their all
flavors of something. It is and that's what kind of
gave up gave us kind of more certainty to try to follow this
path because it seems like a it was a good path to take.
And that the challenge for us was that we need wanted to build
access product, right? So it's not a product that
you're going to put Bill itself and host inside your company,
that is tuned for your specific scenario.
We need the product that you bring any wood, could use and
anywhere could Define the their own entities and relationships.
A lot of the use cases that you just described and even kind of
the companies that have gone down this path are
consumer-focused, is that really sort of the intention for f g.
A is it is it more of a consumer-focused sort of
approach. You did talk about some
potential you know use cases inside a little calm like
Enterprise use cases. But I don't know if most
Enterprises are to the maturity level.
At this point to be able to have the the number quality of
attributes. Get to make some of these
decisions. I guess where do you see sort of
like the main use case for fga at this point?
Yeah. So We've been talking to a lot
of companies and that is that you want to do and something
that is and most of the use cases are B2 Visa scenarios.
If you think about the B2B SAS, it's interesting because you
need, when you start your first version of a B2B such product,
you probably don't have like a we have an admin role and a user
role and and that's enough for be 1, right?
And after that application involves and you start getting
more sophisticated customers, there are Ask you for more
sophistication, how you manage permissions together, right?
So, first time I asked you, I want Rose.
Then I ask, you know, I want to actually Implement find an
authorization, which is the producers can access different
specific documents, and folders depending on who they are and
things like that, right? So and so in our view, every B2B
sales company will eventually need to implement finding
authorization in the products because that's what customers.
Their Enterprise customers are asking them, right?
And and the initially maybe the smaller customers want when they
want to go kind of Upstream in the cotton, the size of the
companies they are requiring, those kind of permissions.
So so yes. So we see a lot of a lot of
opportunity there for me to be such companies to implement
cyclization and also like a initially in inevitably such
product. By definition, you have like a
one attribute Which is their tenant of the customer right
that that the Sailor Gates information, right?
So if you're an admin of an organization, you cannot see
data from another organization, right?
So that is already a biker, a little fine-grained in the sense
that is, you cannot model that just withdrawals.
You need to also have at least one attribute, which is the
organization that the user belongs to write to filter data
depending on that. And then and then it gets more
complex like a, you want to be the team.
Teams like a have people, which I have two folders and then they
want to share documents with with themselves with different
permissions. So it gets more complex in a lot
of those p2b scenarios and product like this.
Kind of makes sense and dryer cycle.
Oh my God, I just couldn't help. I mean, we're on audio only
podcast but we have our cameras on couldn't help, but notice you
have a shirt on this as open f, g a, and you talk to us a little
bit about what that is. I'm assuming that's part of your
mission in life at the moment, so Co and milk.
I'll tell you, it was acquired by October and couple of years
ago and the end at the moment, we were building a product for
solving find an authorization and the 0, it has more the
developer brand. And so we ended up naming our
initial project out 0ga, even if it was already part of vodka.
And then and and then we decided to open source it.
Okay, so right now I'm working in my mission in life is to
products one. Is called oxidative GA and
another one that is called open up.
See a opening gav open source version 2.0 GPA.
We use open appreciated peeled also York, CA and the and the
and the goal is that. Yes, we we want to be able to
open a ga with the industry. We think that a product like,
this is gonna be very important moving forward for building
authorization. And in, in all of these cases
we've been discussing and And we think the company like, OCTA can
with the right Partners can make this reality.
Like, having a de facto standard of implementing finalization is
relationship based Access Control way.
And so, and we think the way to do that is through open source,
and, but we have customers that want to also buy managed service
that they don't need to maintain the need to operate that.
They make sure the security is taken care of by that the
compliance is ticking. Heroes are those kind of things
and for that, we are still going to have a cloud version of a
product that you can use without costing it yourself.
Now, let's create a mini, no pictures, had a big impact on
our industry over time and you know, it's good to see that that
spirit is still kind of alive and well.
Yes, and let's see row and Uncle, both have been
contributing to open source for a while.
But we it's his first time in that.
We kind of launch product that is complete core of the product
is open source. Right, we have a lot of holes,
open source, libraries and things that you can use with
alter or at 0 but never kind of met product that was built that
way. So it's pretty exciting to met
expected. so, if I were to look into the knowledge graph of
Andreas. What would I find as the go-to
karaoke song for you going to end things?
On a lighter note here. So this is my way of tying it
back together. I'm thinking of the fine grains,
you know authorization that says hey Andre is is about to perform
karaoke. Here is the song that he's going
to perform. Yeah.
So it's fun because karaoke songs tempting to be like our
songs, everyone everybody knows and likes to seeing and are fun
and I usually don't like to sing.
Songs are more like a like to sing a song I like and so my
go-to song is down the road from Bruce Springsteen and the area
when I see it in your way nobody knows it and you know a lot of
people so it's not as fun and the when I sing it in New Jersey
that is more time. But by Kim.
What's your your go-to for karaoke?
I mean I have to admit like the hardest part about doing a
podcast. It is listening to the podcast
once in a while and hearing my own voice.
So it doesn't get any better when I do karaoke and someone
thinks a video of it and I'm like, oh my god did I really get
up and sound like that? But, you know, a few shots of
whiskey, or whatever. It takes to get up there on that
stage. So if I'm with Denise, my
girlfriend seems too nice if I'm with her, we like to do Kid,
Rock duet with Sheryl Crow, picture.
And so, that's our go-to for when were together.
Now, if I do a solo, it's going to be terrible.
No matter what, but I like anything by ZZ Top.
And I also like poison, so any anything within their catalog?
But it's just a lot of just sounds like a lot of screaming.
Jeff, it's not good. So what I'm there with Denise, I
tried pick a Song, where the male part is very short and the
female part is the dominant part.
And so that's kind of what we've settled on what about you have?
Probably, I mean, that's probably the way to go because
she's like a professional singer.
So, yeah, oh yeah, yeah. No, I mean, nobody, who's there
at the bar or whatever they were doing in the karaoke yet wants
to hear me, they bub when she sings.
It's like oh, you know people start coming up to her and
asking her to do duets with them.
I'm like, okay. I'm here.
I'm with you on the voice thing.
II. Do not have a voice for singing.
You could argue. I don't have a voice for talking
either but I still have some how to do it.
I think for me it's probably, you know, I like to go back to
my guys at Queen and Duke Bohemian Rhapsody Grant you
know. It is something that I generally
only perform after severe and you variation.
That's just saying which is a very rare Occurrence for me and
I will absolutely sing every part of that song, including all
the highs and the lows and everything.
Now I said saying I didn't say sing well, so I just kind of
make that stipulation out there that it is unlikely that anyone
will ever witness this and it is probably for their own benefit
that they do not. But that that's my go-to would
be Bohemian Rhapsody by Queen. Well at least you picked a short
song. Yeah exactly.
For long. The pain for everybody.
Yeah. That's what I actually like the
It's like putting you into the system like yeah, we don't have
that song that's like Stairway to Heaven, right?
You don't go into the guitar store and start playing that.
That's right. A bird or something like that
Andres. You've been very generous with
your time and I want to make sure you can get on with your
with your day here. Before we wrap things up, you've
educated it myself. And hopefully others all about f
g, a and sort of where it fits within the, the identity and
access management ecosphere. Are there any final?
Thoughts or takeaways that you'd like to get out there for the
folks who are listening that want to either get more
information about or things that they should be thinking about
when it comes to fga? Yeah, so I would recommend them
to Google about Google about Google sansevieria and because
it's kind of it seems to be becoming like a popular way to
implement authorization in general and it has like a diss
to great things which is a way to do find reforestation.
And also way to have a centralized way to manage
organization in the company, right?
And both things are very valuable in the so I hope and I
think that the next few years, this will become a thing.
And other people are going to be like, trying to implement the
requirement in this model. So it might be a good thing to
start learning about it. Right.
And and I'll have a link in our show notes to open fda.gov which
looks like a pretty good website for folks who are interested in
want to get more involved with sort of what it is.
Learn more about. It is in addition to Googling,
it is weird to say Google. Google's and Zanzibar, it sounds
like a double negative. But here we are Jim.
How about yourself? Any final thoughts from
fine-grained authorizations or, you know, singing Melodies with
your girlfriend. Nothing else, home singing?
Yeah. Great.
Topic today, very informative hopefully somewhat entertaining
for folks. Just a reminder about the
webinar coming up in a couple weeks and hopefully we can we
can tweak those numbers and get a few more people to attend.
It's on the 22nd at 1 p.m. and will have a note to a note in
the show notes link to the to the podcast or I'm sorry the web
fire and finally a shot out to Mike.
Thanks a lot. Not for hooking us up with
Andreas because if it's a great guest today, thank you.
Andre has anybody who wants to link up with me on LinkedIn?
I'm very open and networking and I dries.
I would assume you are as well. Yes.
All right. If you kind of, you kind of
spell my name. Yuri, be able to find me a link.
Yeah, or well, we give me the show notes.
I will definitely have a link to your LinkedIn profile in our
show notes. People can check, I doubt
there's always links for Jim and I hate, you know, we're always
happy to connect with folks that are out there.
I'll have links to whole bunch of stuff.
Basically will have Andres our LinkedIn.
I'll have a link to open fda.gov will have a link to the webinar
that Jim is doing. It's called MFA tried to fix
passwords but how do we fix em, f a great sexy title.
I'm sure Jim will deliver and things like that.
So I think with that, we'll go ahead and leave it for this
week. You can check us out on the web,
I done to you. The center.com we're on Twitter
at idea. See podcast and yeah thanks
everyone for listening and we'll talk with everyone in the next
one. 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 and identity
at the center.com.