Certificate Based Authentication in a Cloud Native Environment - a Migration Journey from Handcrafted XML Signing to OpenID Connect

Yeah. Nice. Nice afternoon, everyone. Thanks for joining me here in the basement.

Actually, I was a little surprised, but at least it's cool here. Let me quickly introduce myself. You've probably already read it. My name is tolai. I'm an it architect for roughly 10 years now. I'm mainly working in eHealth intro tech, actually insurance, but I keep saying intro tech because that's much cooler and financial services. And currently I'm a managing director at L 20 ones, L 20 ones. We are a consulting company. Basically what we always say is we help people bring the digital strategy from paper to production. So we understand it on paper and we are able to implement it.

And why am I telling you this a little bit as a disclaimer? Because I wouldn't consider myself an expert on identity and security and stuff like that. I'm really more like a practitioner. So when me and my team, when we built cool digital products with our clients, we often come across these authentication topics and we have to solve it some way. And finally, a lot of developers don't like the topics, so I kind of got into it because no one else is doing it.

And so, yeah, that's, that's just my point. And, and also I'm not selling you any products today. I really just want to tell you a story and, and maybe get some feedback from you guys. So what actually is the story? We are talking about certificate certificate based authentication in the cloud native environment. The client we were working with came from the financial services sector. They had some, yeah, pretty old APIs wanted to move these to the cloud. And the old APIs were using certificates for authentication and they wanted to do that same thing in the cloud environment.

And I just wanna share some insights from our journey today with you and yeah. See what, what you think about it. First question, and this, this question, I think always comes up, whether you're talking to a five year old or to a manager and a 5,000 person organization, the first question is always why, so why are we so eager on that certificate thing? Why do we want certificate based authentication? And honestly, I think for this audience here, the benefits are pretty clear, but still let me give you some context on, on what that client was doing.

So already said that I think they are in the financial services industry. And basically what they're doing is they're selling market data via API API. So they have a lot of data. They have some insights on that and they are selling that to mostly banks. And then what's critical about this. This data sometimes contains personally identifiable information. So that means that they obviously have some high security requirements and they really need to make sure that this, this data is only accessed by the people who are allowed to access it.

And then the last thing that is also relevant to consider in this context is we are talking mostly about machine to machine communication. So essentially a piece of software talking to another piece of software. So that means all these let's say fancy interactive mechanisms are not gonna kick it here. And all these reasons that led to the conclusion that what they are doing today with certificate kind of makes sense. And we need to find a way to move that to the cloud. So what problem were we exactly trying to solve? And I've written it up there.

Basically the problem is the client is too successful to make any changes. So at the core, I already told you, they have a lot of data. They are gathering that data and, and they are processing that data and they are really good at it. And then comes the point where they actually make money. They sell that data to other organizations, and this is where it gets a little messy because as I said, they are super successful. They are working with the same clients, basically since the 1980s. And as they say, never changed a running system. They are also using the same APIs since the 1980s.

And that's that worked for quite a long time. I mean, they are still making great money with that, but now new players are coming around.

So I, I call them FinTech customers, or actually they are potential customers. So it's something like think of new banks, like N 26 or something they are coming around and they're saying, okay, we want to buy this data. The data you have is really, really cool, but we have one problem. Your APIs are older than our developers. So we will not be able to access these APIs. And that's where we came into play and where we help the customer basically build rest API on top of their existing XML API. And I'm saying XML here, it's not. So it's really something they made up.

And yeah, basically we build a rest API on top of that and yeah, worked out all the quirks of the old API and, and kind of built something that has a great developer experience and the dis usable for the FinTech customers. And now authentication because as I said, the old mechanism, something like they had, they had some hand rolled mechanism. How do you sign the request in the XML body? That was all really strange. And then we, we tried to work out a new way of authentication together with our customer and our customers counterpart.

He always had one principle whenever we presented a solution. And we came up with, I can tell you really elaborate solutions. His question was always, can I Google it? And if he couldn't that to him meant, well, then the developer experience can be that great. So that naturally, and to be honest, I really like that principle. I think it makes a lot of sense and yeah, that pushed us in the direction of finding something standard space.

And then also we had the requirements from our development team who said, okay, if we now build that new API, if we build that in the cloud, we are probably gonna build that as microservices and in the end, that meant for us, okay. It will be a solution that is based on tool or on ID connect, because that's something you can Google. That's something standards based that works great in a cloud environment. Pretty cool. But now the next question, how so, how does this even work or does it even works or certificates and my Deconnect or, or, or two, does this even work?

And again, I mean, you, I, I've probably given you the answer already when I said, can I Google it because the answer generally is yes, generally you can do it because the O L spec does not really dictate what type of credential to use. So the, your spec in general just says, use something that is secure and secret.

So, and I've linked you the respective RC. So I'm not making this up. This is really what they say.

And okay, now you can say, generally, a certificate is secure and secret, so might work. And then the good thing is there's even an official extension to the, or standard that specifically describes how to use or of with certificates. So we were onto something because that's all stuff you can Google, that's all standardized. So that's pretty cool.

And I, I just wanna take you, take you on the journey and give you some details. And now this is really where it gets a little technical. I hope we're not losing too many people. So this is the two options that the ol standards brings for certificate based authentication. And you can read the names up there, mutual TLS client authentication until a certificate bound access. Talkings.

These names are pretty cryptic, but I put them up there so you can Google it because that's the official names, but I will explain a little bit and you can see, I think for everyone, who's kind of familiar with ol the, the general pattern is pretty clear. So if we look at the, at the left on option one, we have the client, the client somehow needs to present a certificate to the authorization server, gets back a token and uses this talking to make a call to the resource server and to receive the resource. I think that's pretty standard workflow. If you're familiar with it.

The only thing really that specialist that up there, we are presenting a certificate. How we do that. I will come to it in a mid minute. And then on the right side, the option two, the Ts certificate bound access tokens. This is pretty much the same. I've highlighted the difference for you.

So the, the first part is really the same. You are requesting a talking from the authorization server with a certificate, getting back your talking, that's it. But then whenever you want to use that token, you again, need to present the certificate. You originally used to obtain that token. So really the token is bound to the certificate. You cannot use the token without presenting the certificate. And that obviously adds an additional layer of security because if somehow someone steals that token, and I think we actually heard some great talks on that.

Not sure in this room, but definitely in this building. So this is, this is just an additional layer of security. And now the question, what did our client do? What did we choose? This is I think the pretty old question insecurities. So you are weighing convenience versus security you need. I think what's, what's really convenient about that. Option. One is you can very cleanly separate between obtaining the talking and then using the talking. So you really only need to handle the certificate when you obtain the talking. And after that, the talking is just a string.

You can pass it around, can do whatever you want. And then obviously number two has the added benefit of more security because a stolen token cannot be used without a certificate. But number two also means every resource server needs to be able to handle the certificate. So that's not only less convenient for the client because they always need to have the certificate present. It's also much more technical complexity on your side because every resource server, and if that is the microservice architecture, that might be many needs to be able to handle that certificate.

So, and that is, that is the main reason why I, our client chose to go with option one because they said, okay, we are happy with the security that option one provides. And we are, we would be unhappy with the additional complexity that option two imposes on us. Okay. Now you remember probably I said, we take stuff like that from paper to production. So that is paper. Let me zoom in on the paper. And let's quickly think about what would actually happen if you wanted to implement that, or maybe to understand that what does it even mean? I am presenting a certificate. What is that? Essentially?

It means we are making the certificate part of the TLS handshake. So most of you might know, during the TLS handshake, not only can the server present a certificate, but the server can also ask the client to present a certificate. And that's a perfectly standardized mechanism. So this is what is used here. And this is also where just a little bit more complexity comes into play. When you wanna take that from paper to production, because this is perfectly fine. The picture is perfectly fine from a electrical perspective.

But if you look at it from a technical perspective, it might look something more like this. So you have the client, you have the authorization server, and between that, you will have some kind of reverse proxy. So for example, if you are running this in a Kubernetes environment, as we did, the reverse proxy will be your Ingres controller. And usually in this kind of setup, you will have PS connection from the client to the reverse proxy. And then you will sometimes have plain HTTP from the reverse proxy to the authorization server. I don't know if you can see that in the back.

So the second block is actually open, but just a tiny bit. So, and this is, this is a problem, right? Because the certificate is part of the TLS handshake. And even if you re-encrypt between reverse proxy and authorization server, which you should probably do, if you have been in that other room and heard stuff about zero trust, even then the reverse proxy wouldn't have the key of the certificate and can't really present the certificate to the other authorization server. So what does it mean?

I mean, for this way, it's fine, right? The way back the talking is just a string. We passed that through no problem, but here we really have a problem. What do we do here? And again, we are not solving this together today, but I'm giving you stuff to Google. So the good thing is almost all reverse proxies, have that solved. So there is a kind of not really standard, probably more like a best practice that usually reverse proxies are able to take the certificate information. So the reverse proxy validates the certificate and then puts it into a certain header and how to do that.

You can find under these links and then the authorization server has some kind of verifying that it actually talks to the reverse proxy, right? Again, we're talking about zero trust. So if in the simple case, it's just in the same network, you probably wouldn't want to do that. And the authorization server and reads the certificate information from the rev, from the header and then does whatever it does on it. So in usually you would then verify information from the certificate and build the identity from that.

Okay, now that we got that down, how did we actually actually do it? So now we are really getting away from paper. What we did is we used key clock to build this. I don't know if you guys know this pretty, pretty big, pretty well known, open source identity provider, authorization, server, everything product, the cool thing is it supports both ways of handling certificates that we've just seen. So it supports the mutual TLS or, and the third bound talking.

And yeah, there's, there's something I just wrote that down. So we have it on the slide for documentation. If you do client authorization with that, or authentication with that, you need to make sure that you really read the right fields from your certificate, because sometimes it's a little hard, you cannot take any information from the certificate and turn that into an identity. You might need custom code for that, but that's really something. If you want to get in detail on that, then just ask me, okay.

And I'm, as I said, I'm a hands on guy. So I really want to, would love to give you a demo on that. What will you see in the demo? So just that it's not super overwhelming. I will. That's the bottom part. We will skip that. So we don't have a resource server here. That's something basically you can do at home. I really wanna focus on that top part on talking to the authorization server and to do that today, as it says in the name of that conference, we should use some cloud technologies.

So we have a DACA set running here that runs the key clock authorization server and the EngineX reverse proxy. And yeah, I, I just wanna show you how it works so you can get a feeling for it. And you can trust me that we really did that. And that is it's not just paper. Okay. So first thing I want to show you is, is the DACA set. This is a dock compost file. For those of you who don't know, what are we running?

We are running a key log and a, an engine X I've marked that here, there's some more stuff to automatically configure the key log, but you don't need to take care of that for the moment. Then we have a set of certificates here. So obviously we have a CA certificate that is the root of everything. And then we have a concrete certificate of a bank. So a client of our customer who wants to access our API. And what we do now is I told you we are running the key clock. We are running the engine X. We can have a brief look in the key clock. What you can see here.

I don't know if you guys are familiar with key clock, doesn't really matter. You can see here, I've created a client for the bank. And really the interesting part is here, because what we're doing here is we are saying, okay, we are using a certificate to authenticate. And then we are parsing information from that certificate. We know we can trust the certificate because it's signed by OSCA. And then we are taking specific information from that certificate to basically map that to our client, to, to the service account that should be able to access our API.

And this is really the point where it can sometimes get a little messy. So what information do you take from the certificate? Not so easy, just so that you've heard it and now to make it complete, we can have a quick look so we can issue a curl request. So this is kind of the client we are using. And the important part is really here in the bank. You can see, we are using that key from that bank, and we are using that certificate from that bank. And if we fire that off, you can see, we are actually getting back an access token. That was it. Questions.