So, thank you very much. Now we have all on stage and I hope that Nathaniel will be in a few seconds here also on stage remotely, but maybe we can take the time. There it is. Hello, Nathaniel, to introduce our few panelists, maybe let's start first time with Gail. So maybe short, brief words from yourself about what you're doing and what can the audience expect from your side.
Sure, absolutely. So nice, nice to meet you all. And I'm happy to be here as part of this conference. It's been some time for, you know, face to face meetings. I'm a, co-founder at plain ID and responsible for the product and technology at the company, plain IDs, the authorization company, we provided advanced the authorization access management solutions. And obviously APIs is one large portion of our use cases. Those use cases we address. So we'll talk about that in a few minutes, probably. Thank
You. Thank you very much. So next where we have onsite as David Markina manager of wave stone, which we heard already before. So some brief words from your side.
Hi everybody. So it's, I don't know to be there. I work on em field since eight years now, and especially on the API security and access management and authorization is a recurring topics and always very complex to, to tackle.
You're welcome. Then we have on remote and Nathaniel coffin, co-founder CSO and board member of cloud entity. Okay.
A, a pleasure. Thank you for having us and, and thanks for letting me join remotely cloud entities of company focused, you know, entirely on the authorization space. How can we make it easy, intuitive, and wildly applicable to both APIs as well as cloud native services.
And lastly, but not least we have our co-founder Martin Kuppinger who joined us just a few seconds ago because he found the topic very interesting. And myself, Fabian Z also project manager of co Analyst Aggie. So the topic we are talking about is APIs where security meets identity management. So first question from my side to maybe GA could be, what do you see as a more important to today? Access of humans or access of services and apps via APIs, or is this equally relevant?
I think this is equally relevant. I don't think there is one which is more important than the other. Actually, what we do see is that the human access, which begins at the level of the application needs to go into the services and the APIs. That's part of the challenge. That's part of what we need to solve eventually, right? We need to know the actual identity and provide the relevant level of access on the service level. On the API level. In the past, we used to use service accounts. Those are not good enough anymore because we can't provide the access we need based on just a service account. So
I, I sometimes try to provocate it always worked well. I said, if, if you need a, if you use a, a shared account, you did something wrong. Yeah. Yes. And at the end, I think it's true. Yeah. Something maybe not you, but someone, someone who developed an operating system or so did something wrong.
Yes. I, I absolutely agree, but there are solutions, you know, that's why we'll here.
Of course. So what's opinion of Nathaniel and David on the topic.
I will go first actually completely agree. All both aspects are completely relevant and important. And the difficulty, I think it's mainly on fact that today this authorization are dynamic. Before you could have chat, you could have clear and easy rules saying, okay, I am a system. I need to access that. So I write it in the mobile and it works today. It must evolve with the agile world. We, we live in and with the needs of the customers that evolve and implies that the business need to evolve with them.
So Nathaniel, so do you also think that's the, the point where your panelist colleagues going for, or do you take the opposite side?
I, I might look at it a little bit differently. And, and when I say that, you know, we have to stop and take a step back and think what are APIs fundamentally about, right. They're about sharing data with partners, with customers, even between internal services. And as we start to think about that and consider it in that aspect, we have to realize that APIs actually become like the API endpoint really becomes the perimeter, right? That becomes our new perimeter. That's where things have been pushed out. And we've been talking about identities, the new perimeter, and kind of all these things in the IA am space for the last four or five years. But it's really become that service identity, that API context that's become the new perimeter and whether that's sitting in Istio or whether that's as up as a function or behind an API gateway, being able to protect that fundamentally is how we're going to protect how data is being exchanged between our customer and systems.
Now, when we, when we accept that, then we start to say, okay, well, what's more important. Is it, how did the user authenticate, which, you know, I don't want don't wanna make it pass, say, because that is important. I want a strong authentication for a user. I wanna maintain that user context down, back to my APIs and back to my API to API transactions. But I wanna be able to evaluate, you know, in a zero trust manner, authenticate their user, authenticate the service, authenticate the data, and then appropriate appropriately authorize every data element, both what can the user know do in the application, but also what can the application know about a user to do privacy appropriately at that API endpoint?
But by the way, this is, I want to touch something which you said, which is about a zero trust aspect, taking the identity all the way to the API, to the service. That's what zero trust is all about. Right? And to answer question, this just emphasized the important of taking the person or whatever identity that authenticated at the beginning of the process all the way through to the application assets. And you can only do that if you really understand who the identity is at the API level as
Well. And I, I would have phrased it a little different, but one of the things I talked about for years is about end to end security. Yes. And I think this is the point. And, and we, we, we really did a good job on that. So, so we created whatever web application and so Martin authenticated and then the middleware already, or the applications knew about Martin, but then the applications server used the shared account to access the database and technically seen, we never needed to do that. We, we could provision to the database, we could pass through the identity, we could do that and we can do the same with, with, with APIs. And I think it's also part of the answer around, around, around human versus machine identities. Because at the end we have complex relationships and, and a lot of service, not all services, but many services act on behalf, many things, many devices act on behalf of that.
And that is what we need to do correctly. So this things are really closely related to each other. And I think we need to do that better, but it also means, yes, we, we, we have these APIs and we need to understand when something, one service, whatever resources acting, why and API, in which context is this happening? Is this really a service acting independently, which can happen back into, back end? Or is this something which is acting on behalf of the humans and we just need to do it, right? So not that we have services, which again are decoupled from humans. But so if, if it's logic that if it's from a business case, yes, they are decoupled. They're independent, fine if it's, so if it's a sense or an IV environment, whatever else, but if it's a use case where, where there is the relationship, then we must handle that relationship correctly.
Yes.
And actually to, to, to on that, I think one of the, the main difficulties to transform the business roles of business, what the business has expressed into something relevant for Z API. And you need to, to analyze API by API, exactly what you say. We will consume this API in which context, and why should let this call pass or not organize the access. And that's a difficulty because you can have several context. You can have, you can come from the API gateway, you can come from a, another API. You have the multicloud once again. So you can have trans call, not the API gateway anyway. So you have to decide where you will control and what you control at which point.
So I think that's a great point, right? Cuz what, what you're really describing is how can we move into a transac model? And if we look at how things have been done for the last, you know, 10 or 15 years, it's been long-term sessions, right? Whether they're five minutes or whether they're five days, we've been stuck in kind of these tokens that have been minted and that we continue to reuse, you know, for an extended period of time. Now we see, you know, within the ol spec as well as obviously within open banking, see things like logic, intent patterns, rich authorization requests that are moving that long token down to a very, very short token, meaning a transactional token, right? And with that in the intent based lodging pattern, that's present within open banking, you're actually able to start to divine. What is the intent of this user going through this device, actually in this, you know, much better job at both processing that from a perspective as well as making sure that your dynamic authorization is capable of, of integrating that those data sets to make the best possible authorization decision based upon what it sees from fraud or what it sees from what's going on on the wire or other cyber security pieces when you're doing it on a transactional basis, cuz everything that's happening in the transaction in the course of the request, as well as the course of the response allows you to pull out it all together and make the best possible authorization decision
Is probably speaking to the heart of gal that we need to think beyond authentication what, what we did more right now and, and go to authorization. And, and then really also in a serial trust concept and also form of trust logical security perspective, it makes more sense to look per authorization per transactions. Instead of saying, this person is good and we let that person do all the other transactions that would be
Yeah,
A little bit of too much of risk and nothing was zero trust.
Yes, absolutely. And also I think another point which was touch tail is that traditionally, maybe it was more complicated in the past. APIs were treated maybe differently. You had API gateway, a lot of responsibility was there, but today we are seeing different architecture patterns, primarily in the microservices area, you implement your technology stack as microservices, you must take care within the microservice stack in those APIs and you need to externalize authorization. I mean, technology is built to support that eventually took some time, but eventually it's there and you need to look for those type of solution that supports the technology, which you are using. For example, you know, solutions such as sidecars for your microservices, where you can actually enforce the access control to the level of granularity that you, that you want. And, and that only shows that maybe five years ago, you know, when we just started talking about that, it wasn't ready yet. The technology wasn't there, but
I've wrote a paper back in 2007.
Okay. Okay. Yeah.
So really great discussion. We can jump directly over from my second question because you already answered it altogether. So to the third one, when talking about controlling API based access, we are on one hand looking at standard protocols, such as O O or on the other hand on poly based access, which is the right way forward in your mind.
Okay. I don't think those are two separate things, right? Oof is a delivery method. That's the protocol which you communicate, which is the way you deliver. There are different protocols by the way, Samuel can also be considered a protocol to speak to your application. J just jots also. I mean, that's, there's several ways to speak. That's the language. How do you manage that? How do you manage the language now? That's the policy part. Okay. Policy defines how to connect identities to your data and what is the result, which is pushed to the token, which is SAML open iConnect or whatever. Okay. That's the way I see that. So there is a place for both. You would always need to consider how to manage and how to enforce. One is not, I can't say one is more important than the other, if you consider other aspects, which I guess is not the scope of this discussion like governance and things like that. Then yeah. Management is very, extremely important as well.
I completely agree. And I think both need to be used today, but there is something to, to keep in mind that O is not yet on my opinion, ready to offer the, the, the needed vessel for authorization. We have, we need
To speak
In a, we have this coming on, but it's still draft. And I think we really need in the, in the future, in the coming months and years, something to pass information in a standard way, for everyone in the chain, to be able to use this information and to build this zero trust, we talk about so much. Cause if you are notable to pass context, what do you verify authorization? That's the form is the main step for going ahead.
So Nathaniel, you you're nodding. So you're agreeing to your colleagues on the panel.
I, I agree probably 90% and
That 10% left over.
Right? So, so OA is a delivery mechanism, right? And I think one of the critical pieces of OAuth and one of the mistakes we're making, making today is we're using, you know, these big, giant tokens that are representative normalized data of the user. And we're just passing from API to API, to API, right? And we're creating literally honeypots and leaky APIs by doing that. So policy that needs to be evaluated at the edge of the API to gal's point, but there's also policies on how those tokens are being minted. And again, as we move into that transactional authorization model, it might be API gets to see the full user record API B really only needs, you know, the last name or the account number. And so being able to remit that token at a very, very rapid pace, and we're talking about, you know, tens of thousands, if not hundreds of thousands of transactions per second, to be able to ensure that the API is only getting the data it needs for authorization evaluation at the edge of the API really becomes one of these critical aspects.
As we adopt distributed services, this becomes fundamentally more important as we start looking at other API types as well. Right? So rest has been used, it's kind of the de facto standard for the last decade, right? But G P C GraphQL getting adopted very in very, very rapid succession, you know, as are things like Kafka, we can debate whether that's an API or not, but that's a different, you know, that's a different discussion. But as we look at how microservices are, intercommunicating being able to protect all of the different communication styles coming out of those microservices and not just say it's, it's rest only, right. Or it's not, it's no longer long with tokens. We need to do this on a per transactional basis. And we need to be able to make sure only the, the requisite data is present when we're authorizing.
So Martin, anything to add from your side?
No, I'm good here.
So for my side, last question would be, we are talking nowadays a lot about cloud infrastructure, entitlement management and related models. So how does this relate to API security?
Maybe I'll start here. I think it relates quite a lot because we are talking about resources services and all the ways they communicate. They are set up, etcetera. I think trust, we need to, that's what I talk about in my keynote yesterday. We need to think about cloud into multi-cloud multi hybrid. We need to think, or we think beyond cloud, into multicloud, multi hybrid, we need to think beyond infrastructure entitlements to all types of entitlements. So really sing it as, see the bigger challenge behind that. This is my point. That's why I brought up this dream concept yesterday.
Okay. So I, I think they do relate, but, but they relate in a rather different way. The they're not the same cloud entitlement speaks about access to different cloud services and the capabilities which they provide are many solutions today in this area. In fact, I believe there are nearly 20 new companies in the authorizations, just around cloud and entitlements in this last COVID deal. I just counted them a few days ago. And, and the objective there is to see what you have in your different cloud services. And to reflect that APIs would use that they would use that in order to access the cloud services. And they would need those cloud entitlements when you communicate between the cloud services. So I wouldn't consider cloud entitlement as a topic of API security, but they would be combined together when they okay. Yeah.
So that we are a bit at the end of the panel already. So starting at you, David, what is your takeaway for the audience? What would you like to say that what a can take away for the API part,
Actually, a topic we don't talk about in span, cause we are limited in time, but you have to onboard all the, of your chain from developer to business to understand what is authorization and to give them the key, to understanding in ay way for them to be able to themselves on these topics.
Thank you, Nathaniel, what is your highlight for our audience? From our panel? Yeah,
So, so super quick. I think, I think it's really important that people look at the cloud native protocols that are out there. Right? And so when they, when I talk about it, I like to actually talk about the four horsemen of cloud native authorization or cloud native identity and authorization O IDC, oof, spiffy for service identity, and then an externalized authorization policy. Something like OPPA or Oso, that's open source and, and, and able to be used by anyone and bringing these together with a rich layer of governance really takes you to kind of that Nirvana place where you wanna essentially manage your policies and the control, how data's flowing in between your different services.
So Gail, so what would you like to sum up for audience?
Okay. So I would like to sum up that authorizations for APIs enable you really to take security all the way through. You don't need to stop anymore the door. You can do that all the way to the actual application, object services, whatever, whether you are using open source, one protocol or another, doesn't really matter. What's deliver the method. You need to know that you have the option to really provide the right security for your APIs, for your, for your services. There are more advanced options out there today.
I, I like your point and I think it's important that everyone is on board, but with defined responsibilities. And that's not about silos of developers and silos of security. No, it's, it's about integration about literally defined responsibilities about interfaces, because it doesn't make sense to, to have developers doing the security part. They are better in developing security. People are not good in coding. Most of us, some of us are, but it's not our main responsibility. So not don't let security people code security, but provide what the coders need. We need to, to, to bring the people together with defined responsibilities, to make a team out of it, but not to let people do those things. Others do better.
Thank you very much though. We are now the end. So I thinking about that all of our panelists deserve an applause from our side. So.
