Okay. Well, I get the dubious distinction of keeping you guys in line. All right. I'll do what I can. Okay. First off though, if we can just go starting with at all, we'll just go through, just say 30 seconds, who you are, what do you work for, and any snippet that you want to give us in regard to our, our topic here at all.
Does this work?
Yep.
Okay. Hi. I am a, I am CT of a company called Signal, s G l, and we are into, you know, access management, as you can imagine. I am also a co-chair of the Open ID Shared Signals working group, which among other things, it standardizes the protocol called cape Continuous Access Evaluation Protocol. That's, that's me.
Thank you. I'm Bernard. I'm a C TPO for O Identity security solution. We are offering modern i g solution to, to the market. Very pleased to be here. I mean, technology is moving very rapidly. We need to adapt and, and, and, and clearly this discussion is very variable and very interesting for me to be part of.
Thank you.
Hello, I'm Sebastian. Sebastian Fe. I'm CT of a company called Brainwaves. We are specialized in identity analytics, so we help you to understand we is working for the company and we can access to what we've just been acquired by Radiant Logic. I'm very happy to be part of this panel because basically authorization Israel is the biggest challenge to come in the coming years.
Okay.
Hello, I'm Anders. I'm a developer advocate at Tyra. Michael Tao.
Well,
About, I've been involved in the open policy project for the last four years or so. So I've been, started out on the consumer side in a company similar to Michaels and then eventually transitioned to work full-time on the project.
Cool. Thanks. And so I'm Gert Drapers, I'm the CTO of ato. We're building an application authorization platform based on opa, where we bring a data plane to OPA to make data management easier. We also provide a secure a deployment chain for policies through an open source project called O pcr, which is delivering policies in that way. And last but not least, it's like we're bringing in a reback model to OPA as sort of the information endpoint Yeah. In the whole environment. So,
Okay, thank you. And Michael,
Hey, let's see if this works. It does.
Oh, you got one?
Yeah, I'm already miked and smart. Good. Yeah. Yeah, he's special. He's wired. I'm a special little boy. So, yeah. I'm Michael, I'm head of authorization at Bank Data, which is a Danish banking consortium. And I think, unlike most of the people here, I don't, I don't have a, a palsy code type solution to sell you to sadly. But we, we have implemented that sort of solution in a very highly regulated industry. So yeah, I have, I have that sort of perspective on it. Good
Proof point. Yeah. Okay. Well that's very good. Thanks for that introduction. Now we're going beyond our back, right? That's what this panel's all about. Can we, can you briefly, each of you tell us how you consider we are going beyond our back? What are we doing to go beyond our back at all?
So I think couple of things, or maybe three things come to mind. One is that we are doing this in a continuous access enforcement kind of way, so that we are not sort fighting and forgetting. Like once you've defined the roles, you don't care after that what happens to them. That's not the case. You're continuously dynamically, you know, adjusting the privileges as, as things change in the enterprise. The second thing is the, the policies need to be scalable at enterprise levels so that they can be easily read and enter, credited, and can be enforced at the same time. That's, that's
It. Sounds good.
My perspective is going beyond it doesn't mean that we have to stop from using it, as you mentioned is a transition. So moving, moving to the cloud is, is something that is happening and we need to leverage it. We need to automate as much as possible, but to be successful, I mean legacy application and not going all of them to, to shift to the cloud either is not improvement or, so it, it's, it's would be very important from my perspective to combine the two, so these new capabilities with the old one and, and to create really an efficient model.
So you can't throw the baby out with the bathwater type stuff, but we are, we do agree we are moving beyond just doing the based group membership type approach that we've had for, for a long time.
I, I fully align on that. The point for me is what, what discussing with a lot of our customer the least and chief to, to, to the cloud, moving to vm, just moving to, to csp. They just realized today that in term of TCO is not necessarily, again, I mean at the end we, we just enrich the, the big cloud service provider. So they still have to live with the old and during this transition, the goal is indeed we, we can discuss about it, but is, is to make the, the two world working together. Yeah. So wherever there is a need of automation and that we, we can bring these new capabilities, especially in the cloud. It should be the, the way to go for the other one is how can we balance a tool to get an, that's
My Sebastian.
Yes. So I fully agree with this actually, you know, it's not like opposing a legacy model, role-based access control with new US model policy based. It's really more about cost, grain access control, find grain access control. And the ideal role is to adopt some kind of an agile approach. Because depending on your use case, perhaps you'll want to stay on a rule-based access control, which we, which is by the way, much more easier to audit in order to understand. We can access to what, for instance, those new model policy base are very good in real time, very good for fine grain access control, but it is very costly to try really to 100% of your perimeter, especially leg as applications to a fine grid access control model.
Okay. He,
Yeah, I think the approach we taken in OPPA is, is basically that Rach is essentially a subset of aac. You just, you're just working with a single attribute, which is the role. So it seems, it seems silly to kind of try and limit yourself to, to just that single attribute. And there are so many other things that could be of importance and, and that connect to keep, to be agnostic about the data you manage also allows you to, to work with policy for a number of other interesting use cases like infrastructure. Like should this should, should we be able to deploy this cloud resource given that it's has an insecure configuration or so what, so yeah, I, I definitely think like this kind of distinction of Rach AAC or
Whatever, okay, maybe we should make it the distinction between a static model and a dynamic model. Maybe that makes more sense. Yeah, yeah.
Agreed.
So again, again, maybe we should just talk about the steps we can take then how do we do that movement from that static model where we've had IAM people and an entitlement silo and all of that sort of stuff. How are we now gonna move into a dynamic, more of a dynamic model?
I thought you were still answering.
Go ahead.
So I, I think one important aspect is, is like what is your policy, right? Is your policy code, is it Rigo or is it policy as data? Right? It's like, if I look at Rach, which is to me is like I'm a database guy by nature, it's like it's sets, right? It's nested groups in relations, you assign permissions to a role and you use that to assign that to an actor or a group of actors. There's some inherent challenges with that model, but it doesn't make it necessarily bad as we already heard, as also it's like, in the case of legacy is like you cannot simply rip it out. I do believe that it's like new or other approaches like a reback model, which is like things of more like relations between aspects gives you more flexibility to deal with your role explosion, for example, that you have combining it, like what Anders was saying is like sometimes you need to bring in attribute based decisioning.
It's like, am I, is, is the branch of the bank open today? Right? Am I allowed to do this as I just had a conversation at the booth with a customer is like, he said, it's like I have 15,000 attributes right now and 300 more roles because somebody was trying to encode the location into a role, right? The same as like you are referring to a birthday in a role. It's like that doesn't really work together. That's a round hole, square pack situation, which you try to avoid, I think, which we can do better and therefore make a more streamlined solution, which I think is better to audit as well in terms of determining who has access what.
But then how do we do that? How do we avoid encoding a a date of birth in, in an attribute? Did you have a comment
On Yeah, just a small comment on this. Moving from airbag model to your more dynamic model at the end of the day ultimately means that you will have to build fresh and sanitized data because all those information, all those decision will be based on data. Because we used to manage role in the old days, I will say, so we had role management, no, we want to take real time decision based on attributes, based on policies, but ultimately it means that it moves from the role to the user attributes, all the decisions that will be made automatically by the policy engine. So if you want to transition from a role based model to a more dynamic attribute based model or policy model, then you need to start first by thinking, okay, do I have clean and sanitized data available in order to automate all the authorization decision?
Okay,
I do have a question. Is, is this transition available at all different level? What I mean is that when you're creating a role, I mean there is a, there is a direct implication of a business who is defining what are the needs associated with this specific business needs when we're moving to this new model, policia as a code policy, as a data, which is very powerful. How, how does it take place? And, and today maybe one of the change I see is the, the, the number of resource available today to bring this into, into enterprise to get this implemented. So the lever of skills and is maybe an important question, but is required to move to these new capabilities. I is it the same as of a previous one where based on airbag, where that is pretty basic
As such? Yeah. Okay. And
Brought
Good point Ben. I like it. Let's, let's just agree then that we won't mention roll again. Okay. No r back anymore that we had a question saying, you know what I mean? Let's face it role as an attribute. So what we need to do now is to move into a real time environment where we are not controlled by, you know, when when the banks open type thing. That's, that's something we're going to have to do in real time, right? Cuz we're gonna have this an environment variable. How is it, how do we do that? How do we get there and how do we, I want to come back to this policy bit. How do we set a policy based on that? You know, if we are looking at how we help our DevOps deploy policies, what tools are we gonna do to, number one, certify the policy? Do we need to go through certification? Does it need to have that review number two once it's in a library? Is that something any dev can use? Or what sort of controls need need to be put around that? Who would like to go? Definitely. Yep. No,
So I think there's, there are two aspects to I I want to tie back real quick to something before that, right? I think the first thing you need is to have a common sense or a common representation about what identities do you deal with, right? That's the first, the property you need in every decision is who's the actor? Is that a user? It could be a machine to machine, but it's like that's the first property sets that you need to normalize around, right? That's the first data problem, right? Before this. It's like, I came up out of active directory. It's like that's, it's like active directory was one of the common denominators that a lot of customers had because it gave you the login, it gave you groups and it gave you the ability to then make these level of decisions. Now it's like it was a ping in the rear to actually integrate that with applications because l a is not a friendly environment anyhow, but it was all encoded in this application.
I think the first thing is that we're saying is like for new applications or modern applications, we wanna start taking out all these rules out of the applications and bring them external so we can have separation of concern, right? We can manage them separately and we can start developing this secure delivery pipeline that enables your question that says like, how do I develop an A policy? How do I actually distribute it? How do I make sure it's not being tempered with, right? It's like one of the things is like with with opa, it has a perfect model in terms of, hey, it's like here you have a bundle, right? It's like the bundle gets distributed. We added capability that do actually make it more like a docker workflow that says, it's like you're building it, you can now sign it using technologies like cosign. You can put it in a artifact registry. So you know that when you consume that and combine it with signing that is like, it is a secure untempered artifact that your entity or your authorizer can actually use. These are toolings that you're trying to fit into your, your environment, right? It's like every team and it's like, yeah, Michael can probably attest to that best as the sort of the living proof points that this works to some degree. Yes. Right. Okay. Is that it's like how to fit this into the mo into your organization?
Any other comments on policy management?
Sorry. Yeah, so I think one of the key things about policy management is that the policy that actually gets interpreted in the code needs to be readable by business people, right? So that they can interpret it and that that is the thing that gets sort of certified as your, as your official policy. The second thing is you need to have re reusability so that the policies can be used regardless of the specific resource or the asset that you're trying to protect with that policy. With that you can sort of multiply the use of that policy without having an explosion of the policies, right? And then thirdly, you need to have good access, you know, version control on all of this and approvals on all of this so that you have good workflows that'll allow business people to approve changes to policies, record those changes, and then version them as as needed. Yeah.
Okay. Good. Michael has a comment.
Yeah, so, so I'm, I'm inclined not to fully agree that the policy needs to be readable by a business consultant just because I don't think that's feasible in a lot of the context that at least the kind of context we would be in that that's not feasible. Instead, what we would try to do and what we have done is, is build like verification suites. So if they've come up with a spec for us as saying that, oh, this is what we are expecting this API to do in different causes, these are like the overall business rules, those business rules, they can test that with test cases against, for example, in can do that and, and that way we can verify it for them, but there's gonna be a lot of nitty gritty details beyond just that, that's gonna be in the policy that they don't have to worry about. So I feel like it's, I I I generally would like to see more towards developers, less towards business.
I told wanted to hit you.
Yeah, sorry, just wanted to Roberto on on that. So I, I I agree that, that it's, it's not super easy to make policies that are readable, that are actually interpreted by code. I think one of the limitations of existing systems is that they go to a tuple based model, which sort of is like a row by row kind of thing, and as a result the expressiveness of that model is very, very limited. But if you use something like a graph data model, which expresses the relationships in a very natural kind of way, that graph is able to now allow, you know, support the existence of these policies. While it may not be like pure English, like it is very close and it, it can be interpreted by business people who may not have coding skills or may not understand. Yeah. But
Surely, surely the actual decision regarding the policy maybe transcends that and maybe it, it'll depend upon the environment. Like, so Michael's coming from a really legacy environment, banks, you know, stodgy banks, and maybe in that environment it doesn't work, but maybe in other environments it does. I don't comments and as you had to go,
Yeah, I, I feel like the main point to make, or if there's only one change that you should be like, be working on, I feel like that's to decouple policy to and whatever, whatever you decouple too, that's, it's could certainly be important, but the most important aspect is that you actually do decouple this. I think like the identity folks, they got this right 30 years ago. Like that's basically how you always did identity. You just send someone off to somewhere else to do that authentication and, and then they come back with some token or to assert their identity while for some reason, like as soon as we've talked authorization or policy, we have been like very keen on doing that in our code. So like policy as code is, is, it's nothing new. Like we've always been doing policy as code. We've just been very bad at doing that. Yes. It's just been embedded and coupled to our applications. Yes.
Okay. We've had a question on that actually. And, and you did too, Andrew, thanks for sending through your questions. Can you explain the policy as code versus policy as service approach that you mentioned?
Oh, yeah, yeah, that's good. A good one. I guess like policy as service would basically, like any, any policy engine basically works like you ask a question, which could be something like, should this user be allowed to do this or that based on their roles or other criteria, and the policy engine responds with a decision. So a policy as a service would, would basically just be that policy engine hosted on, on somebody else's machine, I say. So I I would not make a, a big distinction of those two.
Okay. And Michael did send in some questions too. Thanks for that. The, you you mentioned there's a trade off in the added complexity, latency and overall risk when delegating authorization from the main code base, the, the application to a policy decision endpoint like opa, can you explain your thoughts that way?
Yeah, so, so what I think, I think the question came after whether or not there was, there was always a good idea to do because I feel like a lot of times when people talk about implementing avac and, and policy based access control, they seem like, they seem like they're thinking that this needs to be applied everywhere and it's always universally a good idea. But like a lot of the times it isn't like you have to take a risk-based approach to all of this because every time you add, let's say you added an opa, if you're added that in the simplest way, you could do it, you're adding it as a sidecar, that's a new thing that can break down. That's a new thing. You can accidentally set limits on incorrectly or that has some other complexity in terms of how it's set up. And if you start doing that for every single one of your microservices, that's also a giant overload, like overhead of, of resources. So you need to be smart about how you're doing all of this and you need to actu like you need to do everything based on your inherent risk and the cost involved in doing it. And I feel like people are, are approaching it very black and white, at least a lot of the thesis I've seen it.
Good point, good point. Okay. How about from the audience? Do you have some questions from the audience please? S
Hi. Yeah, so we talk about certifying this policies and reviewing them and so on, but what about the data, right? Because you're making decisions based on this data, obviously you have to trust the data and this data could be signals coming from different sources. Any thoughts on those things?
Yeah, who would like especially,
This is actually very good point. So, so, so, so so far we discussed about oppa, which is policy engine. So this is the engine. I mean if we, if I take this image, I mean this engine is fueled with data. So at the end of the day, the engine will make a decision based on the data. So it can be simple attributes or it can be more advanced systems such as relationships. So Zanzibar for instance, there is a good paper from Google called Zanzibar that you can, that you can read when it, it expressed the, the need that you need to build relationships in order to make those decisions such as, okay, this individual is the owner of this document. So this is the reason why you can access to the document, for instance. So my, my feeling on, on my opinion on this is that at the end of the day, we are moving from a, from a position where we will review basically the role on the user access to a position where we will review the data itself. So we will end up in a situation where we will have to review the attributes, review the relationships, review the quality of this on attach as well lifecycle to the attributes and relationships because actually all also decision will be based on this data, you know, this is released.
Yeah, okay. But on the data side of things, like you got the Richard code for the policy and you've got your JSON data. How do you manage that when you're putting a CCAR down by a daco container, right? How do you decide what goes in that particular container at all?
Yeah, and, and I mean there are models where you don't actually have to distribute the data to whether you know, the enforcement point, right? It can always query back to a decision point, right? But to answer your question about the data, I think there is, there are possibly two ways to approach this, right? Sometimes you create authorization specific data, right? And tho those, those are kind of the roles and all that that you create in, in IGA systems or, or whatever. But the other way is to actually rely on your systems of business, right? So the ones where you're actually having your approvals, your workflows and all that. And if you can directly take that data and use that to enforce your policies, then you are a little better off because those are the systems that you're running your business on anyway, right?
Does that sort of answer the question?
So if I could follow, if I could follow up on that just shortly, we actually had these sort of thoughts as well and like how do we actually know what data to trust? Because a lot of developers earlier on would look in, for example, our customer databases and would think like, oh, I don't need to use roles for this, I can just take this attribute out and use that because that seems to solve my problem. And that sort of thing. We were very strict on making sure that you didn't just do that because you don't, if you don't understand the process with which that data changes, you don't understand the business process that actually is involved in making modifications to that. You can very quickly base a yes or no decision on something that is either stale or like can be easily changed by people. You don't want to be able to change it. So it, it sort of goes away from the technical side of things and goes over to to understanding business processes. Like you have to take that step back. So data modeling is by far the most complicated part of going to an APAC system.
Okay. And does g
Yeah, it's an interesting aspect that I think of a lot is also that like we're, we're good at this point and when it comes to like collaboration and, and things like versioning tools, other things when it comes to code, we don't, we don't really, we don't necessarily have those tools or standardized processes on how do we work with data? Like how do you, how do you have some room review, a change in a database? We can like, and, and we can version our code. So we can say like on June 22nd of like 2020, this is, this was the state of our policy. Like, and we can replay that, but very few databases allow you to say like, Hey, give me a snapshot of, of the database as it was two years ago. Because that's what the auditors are interested in. They're not, they're not gonna care what it looks like today. They're gonna want to know at the time of the decision what did, what did the data look like and and who made that change to that data. And, and we generally, we, we don't have good tooling around that, that
That's a general data cleanliness problem though, right? It's like in every warehousing situation is like you have the same questions, this is not unique to the authorization space, right? Being able to deal with data as input, you need to be able to guarantee cleanliness is like in any GDPR CPA project Yeah. You have the same constraints. Yeah, it translates. It's like, and yes, I agree with like that the business system is supposed to be the record or the data of record, but it's like in many machine learning data warehouse cases, it's like this is derived data from second, third, fifth. I have my previous job is like, I had systems where it's like it was eight generation data and nobody could attest to actually how that was constructed at the end of the day, but still it was being used in, in a decision making process. Okay. And I think that's what if, if you don't have control over that as an organization is like, yes, you're flying blind, right? It's like you're exposing yourself to risk. Understood.
Okay, I've got, yeah, sorry, I'm the next question. Question. I'm interested, there's been a lot of discussion over today, various other sessions and, and the sessions here around opa and there's been some discussions around, you know, zamal like where, where we are and what we've done, et cetera. Now I'm operating in an environment for mission critical applications, especially in the defense space and especially around zero just architecture and delivering access control right down at the brigade combat team on a war ship, on a submarine, et cetera. What I'm interested to understand is up to now I've, I've seen OPA as the solution for cloud-based authorization where I've got hundreds of thousands of, of, of, of decisions where you need to make it. What I don't understand is what, and I've seen zamal to be the solution for certainly zero trust at the edge, what I call zero trust at the edge, which is really mission critical type applications, very specific authorization decisions, even doing dynamic rback as an example. What I don't understand is, what I'd like to understand is what are your views isac? I mean there's been talked about exacts dead. I don't see it, I see a lot more growth OFAC around that mission critical application space. Okay, just a second. The nist, the NIST US government have I implemented and said for US government and U S D O D, NIST is exact for zero trust network architecture. So it can't all be wrong. Whereas for instance, why did the
Name, I don't think anybody has said exactly what was wrong. I'm not the behind you.
I want to understand how did the bank, Denmark Bank make a decision to implement OPA rather than exactly what was the reason? Was it a latency issue? Was it distribution? What was the problem that you said NOAC was the wrong solution?
Yeah, so behind that question is ZAMAL provides a protocol without a deal with decisions. Oprah doesn't. How did you come up with Oprah as being the preferred solution?
Yeah, so we, we looked at a number of vendors including ones that use sacl and at the end of the day, there is the truth that sacl is a, is a standard. And I think that's probably most of the reason why it's being referenced friendness and not so much else because they solve the same problem. They overall can do the same, but OPPA is designed more modernly more adaptively. We don't have to put up a bunch of decoration on top of it to make it usable, which we do for SAC all, we have to build a second language to interpret the language. So it's, it's down to enabling developers to actually build authorization systems.
Okay. Any other comments from that? No. Okay. We had another question. I had one from
The
Audience. Go for it.
From the remote audience or maybe from in here. I don't know, actually looking at hybrid scenarios, so really yeah, making peace between RBK and aback. So can policy as code, all policy as data also be controlled with typical business roles from a classic IM system? For example, can specific fine grain policies be assigned to user groups based on course grain roles,
Wine? Why not?
I've talked so long and this is the answer. Come on.
Yeah. At atto has a comment. Yeah,
Just, just a comment. As long as you don't restrict the policies to be specific to a particular resource, then you can definitely use that across, you know, different resources,
Right? So there's piece between both still.
Okay, we had a question back here,
Just a second.
Yeah. And then can can
We hand it over please? Thank you very much.
Speaker 10 00:32:06 So hey, this, this, this might be more of a, of a, of a basic question, but this, this discussion tends to be to, to get very, very technical and, and towards the things that we can do on, on a technical layer. I'm still struggling to understand. So in, in this, in this description of this panel discussion, we, we said that attribute or policy based access control solves some limitation of role-based access control. And a couple of things that I've now, now learned and heard here is that, well, we do policy, we do policy-based access control, but we all acknowledge and know that, that the data behind this is often not in a very good quality. And, and from experience also, I know that, well, even if we talk a, if we only talk about roles, one of these attributes aligning and settling on roles is, is sometimes hard enough for a company, hard enough for a business and figuring out what is a certain role and titled to. So what I'm really struggling to, to still understand is what are the limitations that an attribute based access control solves? What, what does it solve? What is, what is the benefit to go beyond role based? And why would I even go into this, into this battle to make access control even more complicated? Because I am way more fine grained now. So what's the business case here, frankly speaking.
Okay, well maybe we we're gonna have to wrap up. So, and each, each of the panelists gets a chance to say their ending argument. So maybe they can say what their view is on that. Okay. Find grain. I'd be very happy to
Speaker 10 00:33:42 Hopefully the audience agree. Now we
Do that.
I think when, when, when you move to CICD process, having these new capabilities can really automate the process of deploying software into an infrastructure completely automated with a very fine grain approach. That's where I think there is a massive gain of using this, this new capabilities.
Okay. Did you have any closing comments, Manuel? And then we,
It was my closing comment. That's your closing
Comment. Thank you.
I'm not, I'm not author authorized to talk any anymore about rules. So
Do appreciate that you
Just kill me about my closing comments,
Sebastian?
Yeah. Okay, so, okay, my closing comment is, so it's with zero trust, actually authorization is not limited to app at an application level anymore. So this is really easy idea. Everything must be secure, secure, secured, everything must be properly authorized. And this is one of the driver of fine grain authorization and policy engines. Really, this is the ID zero first and my last comment will be a policy engine is just an engine, so it needs fuel. So if you plan to deploy open, I mean whatever the system you want to deploy, do not forget to start with thinking about the da the data really identity data, user data relationships. You need to have clean and sanitized data in order to fuel those engines.
Very good.
Yeah, I, I don't, I don't really know what the question was, but I like the distinction there. Like what, what is the value of abac? And so what is it add? I think like to me the most important thing like that, that I feel is like it also opens up for, for others to take part of this whole like, decision process or like what is, like who sets the roles for an organization that, that would be like an admin task. Like, well if you take any type of attribute into account, it also kind of democratizes that whole process. Or if you can use like any data source, a good example would be like using a a, the Google calendar API as a data source. Like how do you might wanna have, you might wanna say a use a user should be able to do this if they are on call.
Like if they are on duty and how do you know that that's not a role? Or you could, I guess you could add a role every time they get to work and then you have it removed. But it, but, but so how do you tell if someone is on call? Like you, you go and read that in their calendar, you'd see when, when they're working or not. And like if you, if you don't want to, if you're not on call like you, you change your calendar, anyone can change a calendar and so you're basically allowing anyone to to, to work with policy without them knowing it. So that's a, that's a major win for me.
Thank you.
Yeah. To add to that, think Andrew is like, I think the biggest challenge with Rback is not that it's bad, but it's restrictive, right? It's like it's restrictive in what you can express and how fine grain you can express it and the management aspect as the example givens like birthday are you on call? So I think therefore it's like I do believe we're move, we will be moving with newer applications, right? It doesn't make always sense to start taking out existing applications, start retooling them. That brings in more risk most of the time than anything else. But for newer systems we have a way more expressive mechanism to achieve what we want to achieve by combining relations and attributes, right? But most importantly I think the policy based aspect is about the externalization of that knowledge from the application, right? That's the big first step. If you don't make that step, you're still embodying it in your application. You're still hardwiring it, you're didn't make the big move. The big move is to separate the concerns of the rules definition and how they're actually being used by the application. Good point. So they can move separately.
Thank you
Michael. Yeah, so there are clear benefits to aback over our back. So some of them has been touched upon already. Maintenance being a big one. I, I don't know if you heard the example I made earlier with someone going from being 17 to 18 and having to be changed roles by a person who manually changed that because they didn't have a access to a verifiable birth date attribute in that particular case. But we have tons of other situations like that, like financial information, not that not being available to determine whether or not a customer is in what we call a private banking specter. So like they have sufficient engagement with the bank, that they have enhanced rights, that sort of thing. You can also do as attributes. And the beautiful thing about attributes, at least if you're modeling it correctly, is that it doesn't require maintenance. It's a side effect of a business process. So the fact that they have so and so much money on their account is just a question of what transactions and no one had to manually say that honors has free million in his account, that they're just there. So by doing your authorization based on in like indirect the set data, yeah, you reduce the cost quite heavily. Thank you at all. We didn't
Get your comments. Yeah, I was wondering if you're gonna come to me or not. Thank you. But yeah, so I think great point about why should we introduce all this complexity of, you know, attributes based access control. And it doesn't always have to be attribute based. One thing is, you know, with role based you end up with a lot of permissions that you do not need it, it sometimes represents the universe of everything that anybody needs to do anytime in their job, right? Which, you know, may not, may not be what they should be doing. And as long as you can automate all these processes, as long as you're not sort of trying to, trying to create new, you know, processes and new administration overheads, I think you can get to a state where you can be very fine grain just in time and be able to give, you know, real time audit and all those things which are not possible today in role-based access. Look,
Speaker 11 00:40:15 Let's give our panelists a big round of applause.
