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 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.