Well, good afternoon or good morning, ladies and gentlemen, depending on where in the world I currently allocated welcome to another copy. Call webinar. Our topic for today is authentication and authorization for the microservices world. My name is Alexei Alexei Balaganski I'm Analyst Analyst at call, and I am joined today by your he Andres, who is a director for product management at, for rock. And obviously this webinar is supported by for rock. Before we begin, let me tell a couple of words about keeping a call as a company. We are an independent Analyst Analyst organization founded over 13 years ago, we provide a neutral advice expertise and for leadership on various it related topics, such as information security, identity, access management, and governance, risk management, and compliance. And just about everything about the digital transformation. We have three core business areas. One is research. We are publishing various types of reports about products and market segments and companies. We do a lot of events ranging from free online webinars like this one to fairly large scale, and even say leading physical events or on various topics where they are the largest one. You probably know already. It's our identity European identity account conference, which we usually have each may in Munich. And of course we, we do advisory projects and that we support our customers, boss or software vendors and, and users in their adoption of digital transformation and making their it projects more successful.
As I mentioned earlier, here are our key upcoming events for the rest of this year. In the beginning of the next one, we had just wrapped up consumer identity world in the EU. It was in Paris last week and the next one will be in Singapore, just in about less than two weeks now. And the next one will be digital finance world focusing on FinTech and financial organizations in Frankford next March. And of course, as I mentioned earlier, the EIC is our flagship event will be held for the 12th time already in Munich, in may, as usual, some short guidelines for the webinar, your own muted central. So you don't have to worry about anything. You can just concentrate on listening and formulating your questions. We are doing. The recording will be published the latest tomorrow, and we will send each one of you a link to the recording and the Q and a session will be held at the end.
And please submit your questions at any time using the questions box, which you will find on the bottom of your go webinar control panel. As usual, I will gender split into three parts. First I, as an Analyst would provide a general introduction to the problem area. So to say, I will talk about what microservices actually are on what benefits and problems they bring and way exactly data authentication and authorization fits into that picture. After that your will talk in a much more detail about the actual patents and use cases and technical implementations for various else, microservices, architectures, and how to enable persistent and portable identities across various environments. And as I already said, Q a session will be at the end. And let's just start by saying that. Yeah, you've probably heard a thousand times that we leave in the era of due transformation. I will not repeat the enables, which I have listed on the slide.
I would just say that the digital transformation has profoundly changed the way society works, the way businesses are done. And of course, the way the software is developed as businesses need to stand as agile as possible to adopt, to constantly changing market challenges, to new customer demands and to incorporate ever appear in new technologies, they have to, they have to design the applications fundamentally differently. They have to become, customer-centric focusing on consistent UI, the user experience and interface across mobile and cloud and weapon, desktop, desktop, and some other innovative platforms. They have to be mostly scalable to handle millions, potentially at least millions of customers. And they have to be highly available, especially during the seasons like this one, if you are Amazon, for example. And of course, the time to market has to be minimized. Every new software must be brought to the customers as quickly as possible, because otherwise you will be just stamped by your competition.
But this all has led to the emergence of the whole area of DevOp that is development plus operations, which focus exactly on this to minimize cycles, to incorporate as much automation into the delivery process and to design fundamentally new software architectures to, to address challenges on this slide. I have tried to kind of make a short sketch of how software architecture have evolved recently. So yeah, we all have started with the monolithic infrastructures application architectures, where everything is basically packed into a huge black box, including the UI and business logic and or persistence layer and everything else, including authentication. Of course, the problem is this. I mean, I would also say the advantages of this approach are obvious to every software developer it's, it's been done like that for decades. The biggest problem cause that this architecture scales poorly, because if you want to support millions of customers, you probably have to run thousands of copies of your monolithic heavy and loaded applications.
It's really difficult to develop in parallel and to adopt it to new requirements because ERY small change you make in this mono requires a lengthy process of testing deployment and ensuring that nothing has broken on the way or kind of the next step in that or development was server oriented architecture, or it's usually called the ESB enterprise servers bus, where basically you already have individual components focusing on business logic and different presentation, layers and persistence, and so on connected to a single heavy and thick middleware, which is kind of takes our lot of heavy lifting, Azure messaging, transport security, service discovery, and so on. So you have kind of heavy centralized, smart pipe, which does a lot for the developer, but unfortunately also kind of does not scale for the internet or for the cloud. It's really expensive and complicated to deploy and maintain. And of course it's often locks you into a single development environment in framework from one vendor and you do not have the flexibility into choosing the best possible development tools.
And here we come to microservices or the latest range in the software development world, this is kind of a modern interpret reinterpretation, OFA architecture, but focusing on implementing in small individual business capabilities, as a lightweight, scalable, and easy to develop and to refactor and to deploy services, the microservices in a, in a, in a way this could be called the way of software development, where basically each function is handled by a tiny specialized tool, which communicate with each other through down pipes, it's designed for independent deployment. So it can be developed in different languages using different frameworks and databases. So you name it. So it's extremely developer friendly. It's easily scalable. It's running on lightweight and simple APIs and protocols say dump pipes. It's basically rests MQTT, you name it. So again, it's very easy to, to redeploy refactor replace kind of rip out and rearrange in your application of infrastructure.
The only downfall of course, it's a nightmare to manage because sooner later you end up with hundreds of microservices and probably tens of thousands communications between them on the next slide, I've listed the key advantages and short comments of microservices, namely. So again, microservices are great for developers because they focus on single business capabilities, which are usually quick to implement and can be developed in different frameworks and languages. They are extremely loved by operations teams because they are deployable individually in a way that could be scaled easily and duplicated for higher availability and fits greatly into this whole C DCI tool chain, which maintains integration deployment automation. And it allows tool introduce changes to your product without significant downtime and even failures of individual services usually do not cause visible service disruptions. The short comments are, are again, I would say pretty obvious to any developer.
First of all, they, the way how you would partition your existing application to Microsofts it's, it's an art, it's not a straightforward process. Most of the time, you really have to make a lot of compromises and think of really complicated stuff. You have to plan for things like network latency, full tolerance, increased results comes. It is a distributed application with its inherent problems. And of course, distributed applications are notoriously difficult to test, and there is greatly increased complexity. As I mentioned earlier in communications between those tiny services, which appear and disappear all the time though, to orchestrate them, to enable, to ensure that each service talks to the right neighbors and peers and the data flows across those architectures are flowing. The way they were intended to is extremely difficult. And again, security is a nightmare and our identity that is authentication and access control for the data flows and API calls between those microservices is really, really complicated challenge. And this is exactly what we are going to talk about today. When we say security microservices. Yeah. Identity and access control, probably pop up into your head the first time, the first place out of course, security microservices. It's actually a much bigger challenge. You have to think about lots of stuff,
Infrastructure, security, network, security, data security, that's encryption. You have to think about securing the data flows. That is the API calls. You have to protect your infrastructure from external threats and or internal threats. You have to monitor on the whole, really quite complicated infrastructure to make sure that it's, it's working ascertain. And last, but of least you have to think about business terms like governance and risk and compliance. So here are, and the biggest problem that the whole, the better nature of microservices does not really let the traditional security tools like firewalls or API gateways or web application firewalls, or even traditional IM solutions kind of fit into the easily because they are not, they were not developed for scaling and for managing hundreds and thousands of tiny entities interacting. Now, this is why here we can just kind of switch from theory to a little bit more practical things to talk about and to introduce the API gateway. So here microservices communicate over APIs. Clients communicate with microservices over APIs. This is what we see at the picture. Now, how do you secure APIs while we all know that you secure them with API gateways?
Why an API gateway? Well, because such solutions have been specifically designed and optimized for high performance for most and efficient handling of the protocols, which are microservices friendly. So to sale again, like HTP, HDS rest in QTT, we name it. They provide extensive additional functionality, especially in the security area
And especially in the, the whole kind of request transformation area, which I mean that developers are, can actually offload part of the microservice functionality to the gateway to kind of, to outsource security parts and the little bit of even little bits of business logic into the centralized gateway, which saves a lot of time. And again, time is in essence for bringing the product to the market as soon as possible. And of course, an API gateway natively support the identity and authorization pro protocols such as or 2.0 and open ID connect. And they usually have an extensible architecture, which allows plugging into additional features, which is exactly what what's needed for adding additional or threat protection, for example, functionality or identity functionality.
But then again, if you have hundreds of thousands of microservices, why kind of stop at the client? Why just let the client communicate with the services through the gateway? Why not just say, okay, let's do every API call between every pair of microservices through an API gateway. Of course it's becomes probably extremely difficult to do through just one central gateway because kind of neutralizes a lot of benefits of a distributed architecture. This is why the whole notion of micro gateway has come, has popped into existence recently where in micro gateway is a specialized and kind of dream down of all the fat, extremely lightweight and agile instance of API gateway, which can be deployed along with each microservice and handle all the API calls between within your microservices architecture.
The question is, of course, how do you handle authentication in this case? Can the authentication service become a microservice as well? It actually can. And this is exactly what your will be talking later today. And the second question of course, is how do you actually manage and monitor and maintain these hundreds of interior micro gateways? How do you ensure that the policies are applied uniformly? Where is the central brain for controlling them again? I will not answer that question. Now I will leave it for your him. And I just say that, yeah. When you are thinking about deploying microservices, you actually have to probably start thinking about an API gateway solution first because it'll even essentially become one of the most important decisions for your future microservices waste project. And you really have to think about security way beyond just identity and access control because monitoring governance compliance are even some kind of advanced stuff like predictive analytics are extremely important yesterday when we were kind of discussing the webinar internally, the notion of shadow microservices has popped up, you know, what shadow it means.
So it like when your it department enforces their, the rules or regulating cloud service usage in a way that users are not happy with, they will start doing, they will start going rock and using those cloud services illegally, if you will. And the same can actually happen with developers, they would start to develop will start to kind of actually sabotage your security and identity architecture and try to overcome it. So you have to make sure that your architecture is not just secure, but it's also easy to use in convenience for developers. And of course in realtime deployment deployments, the kind of departments will be much more complicated combining both full size and micro size API gateways. And there will be a lot of interdependence with the, the functionality provided by the kind of the underlying infrastructure for your microservices. Be it Docker containers, orchestration platforms like Kubernetes or cloud platform or a service solutions like cloud Foundry, or even kind of the latest range, the server, less computing platforms like us Lambda. There is a lot of practical things to be thinking about. And this is exactly the point where I would like to hand over to your heand to, to talk about your debt. So please, it's your turn.
Okay. Thank you very much. Alexei. Good morning. Good afternoon. Good evening. Also for my side, my name is yare and I appreciate your, your interest in this, in this webinar I'm product manager at for fork's identity platform is an identity and access management solution with the adaptive intelligence to continuously protect against risk based threads and drive personalization across people, services things as well as more technically speaking, web applications, APIs, microservices. So today it's, it's a crucial challenge for organization to drive identity and of course, security to all the across all these digital assets across business units to, to allow on the one hand, a unified user experience on the other hand, to eliminate the digital silos. So as this challenge spans across, across the enterprise and the business, right? However, in this, in this webinar gonna focus, focus particularly on the microservices aspect. So let's zoom in on the microservices world.
So microservices world can be incredibly complex, right? As Alexei alluded to not only by the number of services that are deployed, but also how these services communicate amongst each other, where the services are deployed and also how they're deployed, what kind of tooling, what kind of S you're using and so forth, but further, despite the fancy name, microservices, Microsofts are not all Greenfield, right? Like it or not. There is business functionality and processes existing, and you kind of need to incorporate this somehow in your holistic authentication authorization picture, right? Even maybe disguise something existing as a Microsoft, although it's not a Microsoft, Microsoft might not be proud of it, but that's not really, that's often a given, right. And, and the requirement. And certainly, I guess we, we all noticed that the microservices are, are becoming well. Probably more generally APIs are, are core to certain business cases.
The, the fact of opening services really creates opportunities for monetizing them on a much lower level cross organizationally with partners or externally. And that really drives the need for authentication and, and authorization. Or in other words, there should, there should be no technical obstacle for anybody to be able to execute a microservice that should only be governed by, by the security and by the business. So service plans by the billing, by the entitlements of, but there shouldn't be any, any technical obstacle to this. So many of you, I guess, are familiar with, with, with that portion, but, well, let me just touch on authentication and well authentication is the process of determining the identity of a, of a digital actor. And they're typical to typically two types of digital actors or initiators of, of, of a service and then which probably triggers one or multiple change of services, which would want a human being front of a browser or mobile app or a service or thing, or machine or robot.
But in both cases, as the result of authentication, initiate a should have the appropriate set of tokens to execute the service itself, as well as the chain of microservices, which is triggered or the chains of microservice triggered by the service. So these tokens can be openly connect tokens are always tokens for authorization, ORs tokens. Now authorization is the process of determining if the caller has the right to access or execute the microservice. So in the physical world, this would, the equivalent would be to an I token, for instance, a password, a passport, sorry, a passport issued by, by a trusted authority. It has an expiration date. Whereas the OS two access token is more like a bank note, which is also issued by trusted authority, but independently of, of the name, the nationality agenda, it gives you, gives you the right to, for instance, buy an object if you have the appropriate amount and the appropriate currency. So I mentioned here, I was too in open I connect.
If those are the right protocols for you is up to you to design probably. And the industry embraces both pretty strongly in the webinar. However, think I like to remain a little more agnostic of, of a specific specification. I will use though, almost two as, as a sample in various places, as, as it highlights certain mechanisms pretty well as mentioned opening microservices as well, internally to wider audience or, or externally really poses a challenge of, of syndication or solarization. How we going about to, to secure these maps. Now we could be tempted to throw maybe a spec or a library across the fence to, and, and let developers figure out implementing security, but for developers to do it, to do it in house would be a very tedious and time consuming effort and would be very hard to actually meet the key characteristics of a sound security strategy that, that I want to highlight.
So, so what would the, what are those key characteristics? Well, number one, simplicity. So microservice Microsoft are single purpose programs and shall be kept micro, not directly relevant functionality shall be done elsewhere. Maybe another microservice. So programmatic security in the Microsoft itself probably overload it's really its purpose in most cases. And, and Microsoft security should really be simple so that the, the developer can focus on the business needs. So for instance, you can expect your developer to build a M service that scales or is scalable, but can you expect that, that the developer also scales for instance, token cashing or, or signature validation. That sounds like something that you should externalize now, secondly consists. So, so security strategy, which, which allows many ways to do the same thing is generally not considered as, as very sound, as it's, it's hard to understand test and certify and support all possible options that one might use.
So it's better to have a very limited number, but well understood, tested and, and certified set of procedures. And thirdly, well, modernizing as mentioned earlier, microservices are not all Greenfield, so like it or not, but you need to be able to take on board existing infrastructure. Well, some of the existing infrastructure might even have some sort of syndication authorization in place. So in safety infrastructure, meaning existing Microsoft or existing M service type type services, I should say, and these might already have some sort of infrastructure in send occasion authorization in place. So, you know, strategy need to bridge the gap within the modern world and the, and the existing.
And in certain cases, you also have to deal with services that well, that work well, but cannot be touched anywhere because nobody understands how the works. So you typically, in this case, you have to use an external layer, fronting the microservice to provide authentication authorization for, to the existing. So I guess embrace the existing is, is, is kind of the word. And from, from the stance of modernizing, which is more like the back looking, there's also the, the, the, the looking ahead portion, which is the ability to evolve. So we don't know tomorrow's requirements, for instance, token type or procedure that that are okay for you today. Well, might not be sufficient for you anymore tomorrow at some point for, for whatever reason. So let me take an example if you, if you OS two, and do you wanna move to OS two as proof of possession or any other protocol? Well, you should be able to do this and to, to adapt and evolve your syndication authorization without touching the microservice itself.
So simplicity, consistency modernizing adaptable. Now I, I hear you ask the questions of, hi, am I going to bring this to life? So I will in the following, I will outline four deployment patterns on how it can bring authentication authorization to your service. So the first pattern here is the microservices gateway, which looks very similar to the, to the API gateway. I mean, meeting the previously outlined characteristics. I think it is very hard when brokering the security mechanism in each microservice. So you'd only do this. This is compelling. So the first deploy pattern we're looking is really here, the, the gateway to which you can offload a syndication authorization enforcement to the micro syndication authorization enforcement on behalf of the microservice. So the gateway here really intercepts the traffic and validates tokens, validates signatures, enforces authorization, and an authorization provider here in this picture for org access much would serve as, as a decision point for authorization.
And the gateway in this, in this scenario also take care of, of like in, of any of the following scenarios would take care of, of cashing. And generally the scaling aspect of security now further to this is gateways are also able to, well, in this case particular photo identity gateway, also able to, to deal with various token types and potentially token transformation, which comes in very handy if you need to integrate with the legacy. So draw like this one gateway might look a little bit too inflexible because you might have services deployed across dispersed business units, dispersed operational platforms. And this kind of leads to your second deployment pattern where you essentially divide and conquer. So the different rounds, different kingdoms here could be different business units, different operational platforms or, or whatever your, your business or your operations, whatever might be most suitable for your business or for your operations. It, so this is particularly applicable when running across different cloud providers, each realm should be so each blue and the gray realm here. So each realm should be protected with, with something probably something as running local. So for instance, if one of these reals is deployed in a particular AWS zone, it should be protected by gateway running also in this particular AWS zone.
So now you might have yet another, another case where you want to deploy services anywhere, anytime, and it might not necessarily practical for you to, to bind a, a service to, to particular gateway, or in fact, you don't really trust the link, or you can trust the link between the gateway. And for instance, Ms. Zero, do you wanna look more like you're looking more at like a zero trust model? So in this case, well, you can deploy a dedicated micro gateway per microservice in this scenario, the microservice and the micro gateway, what can run in multiple containers, see here, the dock symbols down here, but from a single unit of deployment, it's a single unit of deployment microservices and the micro gateway. So there can be co-located on the same, same house and share the same resources on such, but for this to fly, the gateway must support the same deployment and scaling flexibility, Daniel microservice, like for instance, running in Docker, for instance, being deployable by Kubernetes or, or, or the tools.
And, and there's in previous previous scenarios, right? The micro gateway has still the same responsibilities in terms of authentication enforcement, authorization, enforcement, token exchange, and so forth cashing. And this is probably the most say DevOps friendly deployment pattern and this which tells to drive changes well, any controlled way, probably the quickest through your continuous integration delivery part. So into broad. And so in a and last deployment pattern, I wanna look at at how, how pass environments handle security for microservices, especially by the example of, of cloud founders. So cloud found is really an example here that I, that I use. So cloud foundries specifies the notion of, of, of routers cloud Foundry route. So, but the idea behind the cloud Foundry route service is that application developers, well, my wish to apply transformations or processing to request before they reach region application. So that's kind of ties back to the simplicity characteristic and to consistently characteristic that I, that I alluded to earlier, and really common examples for, for this are, well, not only authentication authorization, but also swap and, and transformation.
So a crowdfund route service can run inside or outside of cloud Foundry, as long as it fulfills certain service instance responsibilities. So essentially one who deploys an application cloud Foundry can buy this application, or this microservice Ms. Zero here, two, a route service. So the CF router here, if it's hit by request. So in step two, route request first wider route service, step three, the routes of it itself would, would look at how, what are the, what are the access entitlements, the access control and so forth for this request, potentially with an access management environment to help figure out this decision, and then route the requests back in step six, to the CFO router and step seven, the CFO router, wow. Verifies if the right header Arterys were set by the, the route service and, and, and let, let the service request go through. So the interesting point to know this, I mean that that's a machinery of redirect, but the interesting point to know is that when cloud Foundry specified this, they're really onboarded a couple of the characteristics in the design that mentioned earlier, and it's very agnostic of any particular security protocol.
So this, this setup is really the ability to evolve. You need to go beyond ORs. If you need to go to something, something else, then this is fine. This, this really caters for that. So as a conclusion, simply put externalize and externalize authentication and authorization and, and use the capabilities of security, gateways, micro gateways, and a centralized identity solution across all applications, not only Microsoft, also APIs, also web applications and so forth and making security, simple, consistent, modern, adaptable, deploy, authentication authorization, where you need it when you need it, where you need it when you need it. DevOps is king really DevOps is king, not the programming, not coding. DevOps is king for this, so that your, your resources and your development resources can really focus on meeting the business needs while doing this. And lastly, a centralized identity solution can eliminate digital silos and build and build relationships with persistent identity that integrates connect, secures people, services things. Thank you very much for attention. My name is Jore and I will hand over back to Alexei a
Okay, well, thanks a lot for this insightful presentation. I hope our viewers were kind of sufficiently content with the level of technicality you went into definitely kind of way beyond what I was trained to talk about in my part. And this is now the time for the Q and a session. Please submit your questions, using the questions tool in the go to webinar control panel. And we actually have a couple of questions already there. And the first one is quite simple. If the gateway pattern IG plus am, I assume that it refers to the product names, identity, gateway, and access management, right?
Yes, that's right. That's right. Yeah.
And I guess you actually answered that in one of your later slides showing the product names ly clearly. Yes. And
That
Slide, and by the way, I would like to kind of use this moment to attract your attention to the research. We have our website among other related stuff. We actually have three views of both products and the whole for drug identity platform in total. So yeah. Next question is a little bit more complicated. Will the policy decision point the PDP be in the microservice gateway itself or in the authentication of authorization service?
Yeah, the PDP policy decision point. So there's no question about the enforcement point. That would be the gateway. Yeah. And the policy decision point. Well, it should be close to the gateway. I don't think it should be in the gateway itself. Now we have access management or for drug access management as, as the, the policy decision point. But we also have an earlier for also an early access program in flight have an authorization for an authorization microservice. So the idea is to, to move the, the decision point closer to the microservice itself, closer to the pod,
The right. The idea is that you actually have flexibility in making it the best possible way for your particular deployment scenario, right?
Yes. Correct. Correct.
Okay. And we have questions, more questions coming, which is always great. The next one. Alright. Okay. So why, why are you not using an orchestration engine to orchestrate across microservices to achieve a microbusiness function instead of, and microservices communicating between each other? Well, not so an interesting question, kind of, it's less related to our today's topic, but in more kind of a design question, right? Like why are, why do you not have a business logic, you know, centralized location to kind of make this whole microservice architecture, less complicated, right. If I understand the questions correctly and the answer from my side would be, wow, you definitely can have it. And as I mentioned earlier, the, even the API itself API gateway itself can be such an orchestration engine to an extent where you could define our, the complex rules or combined request to various microservices and, or process them inside the gateway and deliver their combined results back to the client. This is kind of an orchestration engine, but again, you have the flexibility to do it the way you want to do it. Do you have anything to add to that?
Yes. Yes. Correct. I guess you want a choice. I mean, what should your particular needs best, I mean, would be an evening filling topic, but yeah, I believe that DevOps is, is key. You want to get, have it simple for your, for your microservices. You want to use authentication also just switch it on your, on your pod whenever you need it.
Okay. Next question. Would you consider having no authentication authorization at all within microservices communicating in the same domain as you positioned the identity gateway at the domain boundary only. So like, would you say that it's a viable option to just let microservices talk to each other or at least in some enclosed area directly without any authentication?
Yeah. Well, within the realm, right? You will need to define your realm and say within this realm I'm okay. I guess you would not say it's generally there, there's always this notion of, of boundary that you need to draw around the, the microservices that, that can communicate with, with each other, without any particular sanitation.
Right. But
Probably getting in, you need to have something
Okay. Right. From my side, I would add that again, kind of microservices are as a development style, do not force you to do the other way on the, this way or the other way you have the complete flexibility myself kind of in theory, I very much like the zero trust approach where cause of no communications are allowed to be unauthenticated is there's definitely not a use case for, or not a recipe for all use cases, but there are definitely where it could be preferable if only for compliance reasons, for example. So again, you have the flexibility it's, it's your decision. Okay. Next question. Would question of authorization policy decisions of the gateway make sense in your opinion,
Sir, can you repeat that? I think
In your opinion, would question of authorization policy decisions at the gateway makes sense?
Yeah, of course this is the gateway should give you the, the possibility to do this for one. So a gateway that doesn't have the possibility, the cash doesn doesn't, doesn't offload a lot of the complexity, you know, onboard the complexity to the gateway, right? Like the cashing. Now, if that is, and how you cash, that depends on the, on your, on your particular needs and your particular balance performance or the security, the gateway should always be able to cash. Yes. Including policy decisions.
Okay. Understood. Or again, next question from the person who asks the very first one. Why or why are you, are you talking about the combination of identity gateway and access management and not just access management? So what exactly does the gateway do, which am for am alone cannot provide.
Ah, okay. So the, the am will be the policy decision point. So the centralized store manager, entities and authorization. Now the policy enforcement point by definition will sit very close inside the business or very close to your microservice. And it's typically yeah. In, in this kind of realm and, and yeah, and you need to incept that traffic and route it and inspect it and then only talk to am for, for the authorization decisions. So an access management tool by itself couldn't do this, but I mean, it's a platform, right? Photo identity platform that provides you am and the gateway, so that we're able to really bridge your identity world to your business world. So yeah, you will need both.
Well, if you allow me a silly analogy to make, so to say like, or if you think about your architecture as a nightclub, then you would have the owner who decides who can get in and who doesn't. And you have a bouncer who is sitting at the door and actually enforce all decisions. The owner can totally stay at the door himself, but he may run up in the program. Yeah. So yeah, it's definitely all for separation of labor. Right. Next question. Well, we have so many already okay. In my organization services are deployed in many different clouds and also on premises, what would be, or the deployment scenario for microservice gateways in this setup.
Yeah. So it's not only in cloud. So, so also OnPrem, if, so the, so here you already have a, a kind of segmentation by, by realm. So, and typically you want to deploy the mic, the gateway close to, to your realm of microservice. So you would deploy a set of gateways, for instance, AWS, and one with Google, another one with Azure, and then on-prem as well. The advantage here is, I guess, is that you have, despite the fact of having hous platforms that you deploy into, you have a consistency on how you bring authentication authorization to these, to these services and the way how you deploy them. So you would have a gateway, a set of gateways on each of these operational platforms.
Okay. And the next question kind of follows up on that. Will it be the same gateway software for each of those scenarios or do you have different ones?
Yeah. So in fact, in, in all of these scenarios, it's the gateway software's photo identity gateway. So that's the same one. Really. We consider deployability as a, as a, as a feature, as a real feature, because that gives you choice. And most of the time you will probably not, not stick to, to one, even in the organization, you don't stick to one deployment pattern. Like you, you will, you know, for some, you have realm for some, you have, you know, maybe the micro gateway approach and whatever suit you, you should need. So it's the same. Yes. But yes, the answer will be, yes, it's the same, same software.
Okay. Right. Next question is a little bit tricky. One other other commercialized microservice gateway products in the market. Well, that's just one for me to answer. Definitely. Yes, there are, of course, other commercialized open source and commercial, as in closed source, API gateways and micro service gateways product on the market. Unfortunately, I am not going to talk about them in this webinar for obvious reason that if you want to kind of employ our Analyst services, you should probably refer to our sales department for that. Thank you. Right. Next question. How can you manage all the micro gateways in an environment with hundreds or thousands of microservices? Because we follows back on micro question, which I left unanswered in the beginning of the presentation.
Yeah. So I guess it's for me, huh? Yeah. So Microsoft, why too good. Don't have a, have a user interface, right. Or something like this, but the, the configuration of the micro of the micro gateway, sorry, the configuration of the micro gateway shall be dealt with as an, as an artifact. So the configuration of the micro gateway is code and should be managed in a, in a source code source code management system. Right. Just as the code of the microservice itself. So if, if you need to roll out, so really co-locate these, these two ones configuration as an artifact for the, for the micro gateway and, and, and the microservice crisp one and microservice itself. So whenever you need to roll out a you configuration, well, you, you relo the full deployment unit, Microsoft and, and micro gateway, I guess.
So it all depends on our actual deployment automation tools, which Al developers are using and which infrastructure they're using to host the micro services with it, like Docker or Kubernetes or any cloud-based platform or service. It's all, it's all about the tools, right? Yeah. Okay. Well, so please keep those questions coming. We still have some time left or, okay. Next one is what if I want to incorporate services, which do not speak or the standard protocols like, or two, can you do it with micro? Can you do it with such a great way?
Well, yeah. So how would you go about this? So that's, that's probably, yeah. You might have existing and I might have a, a security process. So yeah, you can, you can do with the gateways typically I would say probably three levels of, of, of transformations. That's, that's what we are. What we are looking for is like token transformation by itself, maybe exchange, but that's what you need token service for which could be co-located with access management or another STS. So, which could transform tokens for maybe open 80 connect tokens to some tokens, whatever the downstream service needs. It's one could be gateways can be cable of injecting tokens, maybe shared secrets, right? The, the ugly shared secret, but sometimes not your choice and, and, and get what should also be able to transform the request in it's. Well, entirety, it's not necessarily great for performance, but I guess you living handled world of constraints, but the, but the gateway is there for the bridge, your old world, existing world, your legacy world to like the modern world.
Exactly. So that's exactly why we have, we are even talking about API gateways or the best possible tool for such use cases because they can already do it and can be easily adapted for different scenarios, whether it be microservices or legacy services, or even from mainframe running in your basement. It's, it's all about your, kind of the universal functionality for those transformation between different protocols and standards and tokens. Right. Okay. We still have some time for a couple of questions. How does the photo rock microservices currently in the development compare to IG lightweight, alternative, or modularized functionality of the IG identity gateway?
No, that's not a, well, the identity gateway itself is, is pretty lightweight already. Now the, it would rather compare to access management of being a, how should I put it a, a rather stateless single purpose function, for instance, token validation or self contained single single purpose stateless function with regards to token token, for instance, validation, authorization of token exchange. So the, the identity gateway could, or gateway would talk to access management, right? I mean, OS two token validation is pretty, is a very standard process, right. Using, talking into spectrum for, and so could be done with, for drug access management, as well as with the, in, in development for drug microservices and in fact, any other or two provider. So yeah, there's no overlap with, with the gateway itself. It would serve as, as kind of a stateless policy decision point and validation point and so forth.
Well, actually, the way I understood this question is maybe a little bit different. Like when we are talking about the microservice micro gateway from, for, is it the same product as the, the full scale identity gateway? Or if it, is it a specialized, separate piece of OK,
Yeah. Sorry
As,
No, no, it's the same. It, it is the same, same software product.
So there is no need to kind of trim it down for it's already lightweight enough
Now it is already lightweight. Yeah.
Okay, great. And we actually have just about two minutes left and either you type your last question in quickly, or we have no questions left, I will give you a few seconds. And in the meantime, again, I would like to draw your attention to our related research about identity platform by, and of course our more general multi vendor reports are regarding various topics like API management or access management and federations. You will find them our website record.com. And we have the last question for today. Can we get a copy of this presentation? Yes. In fact, you can, it'll be uploaded like minute after this webinar end to our website and it'll be available to every visitor. So we are at the top of the hour. Thanks a lot for sticking with us for this webinar. This include to you, your him for your very deep and interesting insight into this whole microservices world. And I hope to see you later in a, another call webinar. Thanks a lot. And goodbye.
Thank you. Goodbye.
