For,
Oh, thank you.
Hey, feel free because just about everyone on this panel, wasn't originally on the panel. So, I mean, you know, just, this is called the composable panel. I know about the composable enterprises composable panel. Okay. Okay. Yeah. All right. Okay. So verifying what specific applications, files and data a human or non-human entity has access to is at the very heart of a cybersecurity in the face of increasing theft of data for ESP espionage and other criminal purposes. It is no wonder than that. Authorization is getting more attention from vendors. This panel will examine the key drivers, major trends and standards in the modern authorization market. So to be quite honest, I don't know who I've got or why. So could you just run through, introduce yourselves, the organizations you represented, maybe a brief opening statement.
Okay. Okay. I will start. My name is GUIs. I'm one of the replacements. I'm the replacement of VAT Duan, where we still hope he will be online as well. I don't know I'm from one welcome, which is a, a, a company that delivers same solutions for Europe. We recently acquired scaled access and scaled access is let's say an expert in external authorization, and I'm glad I'm back up. What can you also present yourself?
Hey, good afternoon, Berlin. My name is what indeed together with thank part of one. Welcome. And I've been dealing with authorizations for quite some time. Before that I joined one welcome. I was building scaled access, which was an authorization platform based on rules and relationships between users and, and things.
Yeah. Hi, I'm Magnus. I'm a principal engineer at, which is a European eCommerce retailer. Yeah. We are seeing the problem popping out frequently in our in-house applications and yeah,
It's working. Okay. Hi, my name is Sean Parker. I'm working with Accenture for the client Deutche burn. I've been doing for a few years, some platform engineering there, building platforms, and I've been working the last two years with OPA and Tyron as, and we've made quite some experiences there.
Yeah. So my name is go KK. I'm heading up star up DEC creators of open Porwal agent here in Europe and working with both Magnus. And Cheban here as two of our customers to implement cloud native authorization as we call that. And I see that actually as the biggest driver, because I used to work with Al before I joined Tyranno for two years ago. And the biggest difference I see in the market is real. And when we're working with monolith, yes, authorization was complicated, but it was still doable in an application. When we're working in a cloud native environment, we have thousand are moving pieces and thousand of places, we need to do authorization and actually doing it in code as the old paring will simply not fly. It will be too complicated and cumbersome, maybe not right a first time, but to change and doing orders on that would be a nightmare.
So are we playing catch up yet, yet again? I mean, I get the impression that authorization has, has kind of been the, the kind of ugly duckling or the, the forgotten cousin or something that, that, you know, we just haven't quite kept, kept up to pace. I mean, what, what is your feeling on that?
My question to other panelists to the, to the users over here would be, are we talking about authorization within the company, or let's say also to, to the end users of, because Solano has a lot of end users and because that's also specific, we are in the business of B2C a lot, also B2B, it is a bit brewing and we see it's also important for, for end users for these lots of end users outside that we also take care of authorizations over there. But so what,
Yeah, so we are mainly using it for workforce cases, but since workforce includes service to service, communication customers actually touch the systems just that the authorization policies are much more complex on the workforce side, on the consumer side. It's more like, yeah, can you access your own data, which is critical GDPR wise, but it's normally not as complex as the other cases, but we will essentially move there eventually, but we are starting from the workforce side at the
Moment. Okay. So can I just hijack my panel back again from you?
The reason for asking that is that I heard a lot of use cases over in the B2C environment and you are asking whether we need to play catch up. I think that, that these are two different situations as well. And I think we need, there is need to catch up in, in the B2C environment because a lot of demand from, from our, our customers are there for, for these external authorizations.
So would you agree though that, that the vendors are increasingly paying attention to the authorization space? I mean, are they responding what you're nodding agreement?
Yeah, definitely. I, I think the sector and identity sector as a whole, we, we, we kind of resolved the identity issue. And so we now know who is using a platform. What we didn't resolve very well is what is used, allowed to do. And so there we, there we see a need for, for common patterns that can be reused across multiple platforms, as you said, that we can, we can manage consistently we can access what on the, which conditions. And that is a very dynamic thing. And the, what has changed in the, in the past few years is due to the, the, the, the open initiative. So we've got the developer community that now understands what it means to externalize authorizations. And so, yes, that's the, that's the part, yes. We need to catch up as a sector, but my point of view is that at, we, we've got all the stars aligned to, to play catch up now.
Okay. Now, so the, the, the at, I guess we're gonna spend quite a lot of time on, on OPPA considering the, the representation on the panel and, and the collaboration. So, but before we get there, can we just have a quite quick look and say, okay, right. If we're moving into this direction, we're gonna need, we're gonna need standards. So other than OPPA, have we got any workable standards that, that are emerging there and, and, and are helping in the authorization space?
So let me share real secret. We are also anus.
Okay. So this is, this is a very, this is a very, I mean, okay. So I, I need you to pretend that you're not, you haven't got in the game.
No, doesn't
Exist for two minutes. I mean, I mean, well,
We come, if we just reversed a tape three, four years ago, Uber wasn't on the market, we were still talking Saal. And did anything happen? I asked you as an Analyst, did you see an attraction in authorization market before? No. And I think that answered the question, because we have actually seen a couple of seeing clients using Uber that has more Ubers deployed, I guess, than there are SAC Indians in the whole world. So that's free to answer the question. So right now there isn't alternative, but that's also said past five years, that could pop up something else. But yes, now I don't see an alternative TOPA.
Okay. So now we are keeping a call, obviously in the E I C awards this year. We've recognized the work that, that, that the, the group working group on, on Oprah has done. So then can we look exactly what the modern authorization requirements are? And then you guys can, from your experience, and also from your background knowledge on it, say, how, how does Oprah address those? So just first enumerate the, the challenges in a modern environment, and then enable us to understand how Oprah does address those and how companies can use them. Because this morning we had an example of an op use, but they were saying, look, it, it, it kind of, because it's written in Jason, it kind of allows anything. So you need, you need something in between to kind of regulate things and, and it, you know, that kind of thing. So just again, enumerate the challenges and how Oprah addresses those and, and kind of how it's working in a practical point of view. I think that's real end
Customers fair. Well, yeah, for, for us being basically in the cloud native development domain, where we build a platform on our customers are developers and other people in, in the enterprise. The challenge there is that we never really know that the requirements, we have developers who want develop fast, we don't know how to, to handle that. And we don't really want to slow them down. So we want to give them the building block, which in that case is OPA because it's generic. You can, and it's, it's just a policy engine in the core. So meaning the challenge there is you have to understand Regal the policy language. You, there are quite some integrations out there, for instance, for Kubernetes, you, you can just integrate with that, but you still have to basically write the well, the, the integration, the adaptation between the, the custom systems you have in your enterprise or other products that are per se, or that don't have an integration yet. So for now, people have to be relatively tech savvy to, to use it. It's getting better with policy packages, but it is software in the end. It's, it's a building block, like anything in the Unix, well, or cloud native context, but people will have to understand code to certain degree.
Yeah. To add on this. I think OPPA is actually not the end goal, but just the stepping stone. And I think we will start thinking about it as commodity, like power that you just have. And I think the interesting thing will be really what you built on top. Like, so, I mean, we gave a talk, but like the other things like policy engines that actually transfer natural language into something lower level OPPA that you can actually execute. I think these will be the interesting products we will be seeing in the next years. And I think OPPA itself is just a necessary stepping stone to get to more flexible authorization that actually serves more software that's being built. And at least what drives this internally, I think most companies are becoming software companies like willingly or unwillingly, which means more in-house applications, which means, and like smaller teams serving like more focused business goals. And I think they just don't want to care about authorization, right? It's not like a big team that like develops something like SAP, but it's like something that develops a specific small service that serves a specific purpose and they simply don't want know, do they have the time to actually like develop or like even think about authorization? So I think these things are driving it and will also become more apparent in the next years. So
Can you remark what?
Yeah, I, I, I totally agree to that. So, so the, the rule engine is only one piece of the big puzzle and it is why we next to the rule engine. We combine policies with inflammation that is linked to the user that is, that gives context about the user. So let's, and there, I think that use cases that we cover are, are a bit, little bit different than what you're covering. We deal with business, like use cases, take insurance. We discussed that yesterday with people in many. So you've got, sorry, Berlin, you've got an insurance policy and you've got a subscriber of that insurance policy. And since that, that person is a subscriber, he is allowed to invite the beneficiary to get access to that same insurance policy as well. So you basically start building a network where you link, use it with each other, but also with an object, which is in this case, an insurance insurance policy. And so you need more than only the, the, the, the, the authorization rules. You also need context. And that is, and, and I think that, that, that's, that's what, where you are referring to. So, so the policy engine is only one little piece, and you need to add a lot of things around it before that actually start generating value.
Okay, great. Thanks. So before we come to the questions and I'm sure we'll go back to OPPA. The one thing I just wanted to ask is, so we've got just in time privileged access management is, is something else that's, that's happening in the markets? I mean, do you think this also has a role to play? I mean, it, it is a development in the direction of being able to, to kind of enable authorization in a kind of more finely grained way and, and looking at privileged access management. Do you not see this as a significant development in the market because we are keeping a call? Certainly do.
Yeah. And, and, and then I tend to disagree if, if you do authorizations, right, there is no need to, to have a particular category that says privileged access management, because every access is actually privileged and every access should be personalized who use it and to the, the, the thing that user wants to do and doing, doing just in time provisioning for me is a way to deal with, with legacy applications that are not, not qualifi.
Okay. So now we can go to, to some questions and as predicted ISPA, a good fit for enterprise authorization use cases since it isn't that auditable and segregation of duty is difficult.
I, I would, of course claim yes. And one of the reason is that scalability, as Magna said earlier today, they have like a million decisions per second, right now, under peak hour. And it is audible. You can get the decision logs, but you need to be able to read the policies. But even me and I, haven't written a single line of code since I left university 25 years ago, I started cheating in writing RGO last year. So it's not that complicated. And I can read RGO without any issues, actually. So it's not that hard. And then there are toes that actually abstracted already, but I think we will similar tools like
That. And from practical implement implementation side, do you agree?
Well, I do. I mean, OPA is something you can integrate in many systems. And our challenge was really to, well, get that overview to see what is happening in the system. And for instance, we used DDA the product, good stuff is really presenting. And you get out of the box, a good dashboard. It's where you can see violations policies that are not being enforced, but you can see them being active and you can trace them back to where they're and when they occurred. So that was for us a great help. And since the product is API driven, you can still build your own products on top of that. So it's coming all together in well, Starra for that, but you can also build your own solution, integrating that with the OPA in sensor Starra is just pulling everything together, out of the box.
Yeah. So to answer this, I think there's no silver bullets, so I wouldn't try using OPA in front of Salesforce. I think that's just the wrong thing to do. The other thing is like, you would also not try to do OD in a specific application. You would rather do it cross applications anyways. So I think that's how would see how you would actually implement sod on top of Uber, Uber shouldn't care, but it is actually something, a control that you place across applications on top of Theus. So I think it is possible, but shouldn't be solved inside open. I think if you're trying to do sod there, you're doing like at the wrong place.
Okay. Question in the room. Let me add a little note. Okay. Sorry. What, there's a question in the room, Paul. Well, pushing a microphone. Well, that's not very useful. Grab a microphone.
We're not
Who's who's asking the question. Are they okay?
What do we pay you for Paul?
Well, not this
Thanks. So to follow up on that question about the enterprise application, I, I can, I can see the logic of policy based access control. And do I have a correct decision? Your policies have to be correct, but also you have to trust the input data, the attributes. And I can see that perfectly applied in a cloud scenario where much of the data, the attributes, the context are technical, but in an enterprise isn't managing all the attributes of all the employees of all the employees in your, in your company, even harder than managing roles. Isn't this even more complex than for example, Arabic, which is even which, which we haven't solved yet in practice. Is this doable in the enterprise scenario?
I guess that was your is.
Yeah. So the thing is like, if you do aback, you don't necessarily have to use attributes. I know that's a strange statement, but you can actually perfectly fine do like ACLS or AACH using that policy engine. And that is much more like simple and much more like usable in practice. Because if you think about like textbook ABIC, you check. If the user is a member in a certain department, in reality, there might be a stretch assignment, the users reassigned, whatever HR hasn't caught up, and that user simply needs access for valid business, reason X. So what we essentially try to do is essentially get data from a governed source, which is our IJ tool. And then essentially use that and do simple policies and get them working. So I think you don't necessarily have to go full aback because I think that has its own sharp edges, hope that answers it and the governance should be done outside of OPPA anyway. So you should have good governance on user attributes, your roles and so on. I think you can just continue doing what you're doing. You can just use it as an extended tool on top of what you have in your tool build.
Okay. Are there any more questions in the room? Otherwise, I'm gonna go to the question online, which is for the users of OPPA, what type of policies exactly. Do you manage? Please give examples.
I'll restart for us as a platform, having our customers, being developers who provision throughout Kubernetes using cross plain, it's a technology that provisions in terms of man manifest Kubernetes objects, resources at AWS, as such as, as in three bucket. So what we do is we monitor or modify for instance, objects going into Kubernetes and basically enforce that they're compliant. For instance, securities, like KMS keys are set that they're not public and those kind of things. This is what we are mainly doing right now since we're focusing on infrastructure.
Okay. And that brings us nicely to time. Thank you very much, gentlemen.
