Please welcome Michael Dujek. He's a Senior Product Manager at Ergon, and his session is entitled Implementing Identity Aware Zero Trust Architectures in Hybrid-Cloud Setups. Among other things, Michael will talk about how organizations can deal with external identities. The floor is yours. Thank you very much. My slides are up. Perfect. Thanks for having me. I hope you will find the switch from the policy layer, which is very high up in the clouds, down to more of the identity and network layer. You'll find that interesting.
I'm going to talk about managing identities in hybrid cloud setups, but I think first a little bit of introduction. I'm working for Ergon Informatik. We're located in Switzerland, a little bit more than 400 people, and many of them are working in the solution business. So basically, if you come to us and you have a problem that you want to have solved in software, we have the guys that do the consulting for you, business analysis. They implement it and even operate it for you.
Now, me personally, I'm with the smaller team, and our product name is Airlock. We have two products in there. One is a web application firewall slash API gateway, and the other one is an identity and access management system. As already said, I'm one of the product managers, and that's what brings me to the topic of managing identities in hybrid cloud setups. To start off, let's first look a little bit about what I think are the requirements that a customer identity and access management system must meet.
Now, let's clearly understand this. This is not about an enterprise IAM, so something that you use internally to manage your employees. It's really about managing your customers, maybe partners, and identities that come from the outside world that need to have access to your resources. And the primary focus with such systems is always the user experience. That's key, because if you don't get the user experience right, then the customer will not join your company, but he will go somewhere else and spend his money there, and that's something you don't want.
UI customization is a key point, because corporate identity, corporate design is important. Everything needs to be seamlessly integrated, so it works well for those users. And you have to offer self-services, so they can actually get to your system 724, and they can even help themselves, which reduces the cost for your help desk and gives them a good feeling, because your systems just work. And you have those social logins out there, the login with Google, the login with Microsoft, all these things. You need to have legal and compliance in your IAM system.
GDPR, DSGFAO here in Germany, I think it's clear that you have to comply with those, but there's also the strong customer authentication. For example, we have many customers that are banks, so they need to comply with PSC2 if they're working internationally. You have transaction approval, a tiny little thing that obviously banks are interested in, where they can actually make sure that the customer agrees to send amount euros X to recipient Y. Or you have other legislation which says you have to have a cool-down period.
It's not something very common in the EU, but for example in Singapore, when you register a new device, that device for a time period like 12 or 24 hours can only be used for low-risk operations, but not high-risk operations. Your IAM system has to support mechanisms like that. You have the technology, which is evolving constantly. I just put on here Fido Passkey, because it's one of the more recent technologies that is seeing more and more adoption. You have to bring your own authentication, where you have to be flexible enough to support that. You have risk-based authentication.
And last but not least, you have operational requirements in a customer IAM, where you have the availability, the cost efficiency of the entire solution, and of course the performance. So bringing it all together, it gives you a nice picture. On the top, you see the lifecycle of a user from the onboarding, until the hopefully not for many years off-boarding of that self-sim user with intermediate steps. I'm not going to go into the details, but there is a lot of components in there, up to and including standard APIs that you're using for automation and integration of your IAM system.
So now that we understand what a customer IAM system is, let's look at the world of a Zero Trust Network architecture. On top here, you'll find a few clients that your end users are using. That could be mobile devices, browsers, it could be IoT devices, or it could be a partner that directly wants to access your API. And as a company, you have quite a few choices to make. And one of the choices traditionally companies have made in the past, and they're still having those systems around, is that they run their own IT in their own data center.
And they're using classic web applications, front and back-end kind of architectures, but they're also building up Kubernetes clusters, OpenShift clusters, where they're running microservice architectures with containers. And they all do that in their own data center. These days, many companies decide that they want to run part of their microservices somewhere in a cloud, because they don't want to deal with the hassle of having their own hardware.
And the staff that needs to operate that hardware and the operating systems underlying that, they just want to worry about the containers, which is really what their business is about. And last but not least, you have third-party services like SaaS integrations, where you have a CRM system that you're just using from the cloud. And you have partners that want to connect to your systems, or where you want your customers to allow direct connections to those partners for B2B processes that you have.
Now, all of that needs to be secured, and the security is exactly what I want to talk about. The first thing is, on the corporate IT, we find that very often you still have an edge gateway, which is a web application firewall slash API gateway that will filter your traffic. In the microservice architectures, on-prem or in the public cloud, you can deploy what we call micro-gateways. Kind of the same functionality, but much more lightweight footprint, so they can be deployed as sidecars directly on your service.
This also gives you the opportunity to combine that, where the policy enforcement really only affects one service, and it avoids the cumbersome edge gateway that needs to meet the policy of all the services that you're exposing, which makes them quite complicated, and typically those configurations are huge. And last but not least, you have identity. So you have an identity and access management system, D1, that we just talked about earlier, and it creates for you identity tokens that are being consumed all over your corporate infrastructure.
And you can use the same IAM system to actually deploy those identities also to things that you have deployed in the cloud, or even to your soft service that you have integrated or partner that you have integrated. And they're all stemming from one identity source.
Now, this is a problem. If you only had one identity source, I could actually end my presentation right now and right here. But the reality is that these days, we cannot really rely on the fact that we only have one identity source.
Typically, businesses are much more complicated, and they have to manage different identity sources. And that's exactly what this is about. Sources of identities can either be partners and suppliers that would like to access your services, or it could be that your C-levels have decided that mergers and acquisitions are a good thing for the company, but they're typically a bad thing for you as D1 that has to run or operate the whole thing, because it means that additional identities are coming into your company. You have the social logins, or you have the pressure of the hyperscalers.
Let me ask you a question. Who of you has a Microsoft login? Me too. It's PowerPoint. I'm required to have a Microsoft login.
Otherwise, I can't do anything. So I have an identity there, and that identity should play nice with the identity I have from Ergon Informatics, please. So we have to deal with that. The reality is you have multiple sources of identities, and we still have one goal, namely that we want to have a single sign-on for all our end users with identity federations, so they don't have to worry that their identities may not be the identities we have internally. And there's a solution for that problem, and I'm going to quickly present you with something called Token Exchange.
It's an RFC 8693, and it's a way on how you can actually make sure that what you're dealing internally is what you have under your control and not something that Microsoft or Google provides you with. Here the picture is on the left-hand side, you see a client mobile device.
It's going to try to connect to a front-end server because it wants something from the front-end server, it's a web shop, and you have to fill a shopping cart, and sometimes you want to actually check out, so the back-end server will send you the bill, it will have all the B2B connectivity for the suppliers that actually send you the stuff you just ordered. But what you want to do, from a security point of view, is you want to keep the end users in the blue zone.
They have nothing to do in the pink zone, because the pink zone is where the real money is, and where all this connectivity is, and you don't want them there. And token exchange is exactly the protocol that allows us to do that. So what's going to happen?
First, the client tries to get to the front-end server, and we have a micro-gateway there that filters the traffic and says, oh, you're not authenticated, you don't have a token, please get yourself a token so we know who you are. You go there, and you have an authorization server, and it will issue a token, an identity token, to that person, and it's a blue token. Why?
Well, it's a blue token because it's valid in the blue zone. So using that blue token, our client now can get to the front-end server, and it's going to behave nicely there. The front-end server wants to do its thing, so it needs the connection to the back-end server.
But again, we have a micro-gateway there. You remember the Zero Trust Network architecture, every service protects itself, it enforces its own policy, and the policy says, hey, you have to have a pink token, a blue token is not going to hack it. So we have to make this token exchange. We take our blue token and say, hey, we have an authenticated user, we're the micro-gateway, we're actually trustworthy, please exchange for us this blue token to a pink token. And with the pink token, oh, finally, we're there.
The back-end service is going to accept us, and it's going to send the bill, it's going to order the material, and everything works. Now, why am I presenting that? Because I think that we actually can use that in two use case scenarios. And the first one is internally. Those security zones where we want to make sure that end users with their devices cannot connect to back-end zones. And that's exactly what we're achieving here.
So we're introducing micro-segmentation, and we're enforcing policy, not only for filtering, but also on identities, to make sure that those more secure zones or zones that require more security cannot be impacted, and we minimize their attack surface, because we know no end user will ever be there. The second thing that we're going to achieve is identity federation.
So when, from the outside world, we have tokens, identities, from Microsoft, from Google, that try to come in, we're going to take those, we're going to inspect them, and then we immediately, if we like them, we're going to exchange them. Why? Because we want our internal network to only work with identities that we have under our control. We exactly know then what their format is. It makes everything a lot easier.
Enforcing policy, if you have control on what's inside the token, if it's name, first name, date of birth, or some other information, you have it under your control, you can enforce a policy, and it also makes verifying signatures and things like that on those tokens much easier, because it's your own signature. You don't need to trust no one. And believe me, I tried it. I set up an identity provider. I connected it to Microsoft and told Microsoft it should trust my identity provider. You know what the first thing is they do?
They take my tokens, they throw them away, they issue their own tokens, and inside the Microsoft network, you only see Microsoft tokens. It's the same way on how to handle these things.
Now, putting everything together in our network architecture, you now find that on top right, we have Microsoft and Google. We could add tons more up there. And what we're doing is on the outside, they're coming with their violet tokens. We don't like violet tokens. We exchange them to blue tokens. I don't even have to change the drawing down there, because the only thing I do is at the edge of my network, I say, hey, Microsoft tokens are okay once they're exchanged, and then those users coming in with the Microsoft token are acceptable.
And the second thing I'm adding is what I've already explained before in my example is using token exchange to protect backend security zones. I do it in the corporate network, locally on-premise, but I can also do it in the cloud. The only place where I can't add any security is where?
Well, with the SaaS service, it's not under my control. What I have in place is a contract that says, you guys have to make sure that my data, when I'm using your CRM system, is safe. Or with the partner, they run their own security. I don't have any control over what, or I only have legal control, contractual control over what they are doing, but I can't change it on the IT system side, because it's not my network. It's not my systems that we're running there.
So to conclude, there's modern protocols like OAuth, OpenID Connect, token exchange, and we can use that to manage identities across hybrid setups. It doesn't matter where we're running our applications. It really only matters that we control the identities. If our policy enforcement not only covers filtering of traffic, making sure that there is no OAuth top 10 attacks, SQL injections, things like that happening, but we're also enforcing identity, then we're basically moving in the direction of the Zero Trust Network architecture. Zero Trust Network architecture is very simple.
Never trust, always verify. That's the paradigm that we're trying to achieve here. And if we do the implementation right and we put it on the infrastructure layer, we don't put any work on the applications that they have to do that, then we can actually reduce costs, we can reduce complexity, and of course our time to market is optimal. And last but not least, doing it right, we can actually do that without changing our applications, regardless on whether they're classic web applications or whether they're modern microservice architectures.
We can put the security measures, the additional security measures in place by using standard protocols, and you don't have to do it with Airlock. Those are standard protocols. There's other vendors out there, but if you'd really like to understand a little bit how this works and to understand more, then I'm here right now, maybe for a few questions, or later on outside in the hall where you see the Airlock banner, you can find me and my colleagues. So thank you. That's it from my side.
Thank you, Michael. We have time for one question. Anyone from the audience before we let Michael go? No? All right.
Thank you, Michael. Thank you very much.
