Kong Destination: Zero-Trust, 24 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Securing APIs with OpenID Connect

Description

With Kong OpenID Connect, you don't have to rewrite or maintain the code over and over for API gateway security. And that makes it faster for the developers of the upstream services to get their work done. For more information, view the blog post: https://bit.ly/3pSE2Pv

Check out all the recordings from this event: https://konghq.com/resources/?video-category=destination-zero-trust

A

A

Ideas is rather simple with zero-trust.

A

once you're inside the corporate network in a perimeter,, nobody has trust.

A

You should assume that anyone that you're talking to is not trustworthy.

A

So then, the immediate question: is, ok, well,. How do you establish trust?.

A

And one of those mechanisms to establish trust is openid connect.

A

So we will discuss its history, its applications and do a small demonstration where we show three use cases for openid connect.

A

So to begin with, what is openid connect?.

A

Well,, it is a standard., it is based or built on top of oauth and jwt (json web tokens)..

A

Chances are you've already used it today. any time you've used any application or product or service out there that says, hey,. Would you like to sign in with your linkedin account or with your google account or with.

A

Your yahoo! or facebook, or any account whatsoever?.

A

Chances are you've, used, oauth and openid connect.. What is usually happening here is that you're authorizing someone to use something that belongs to you.

A

For example, linkedin could say: say, hey,. Would you like me to invite people that you know ?.

A

Or would you like linkedin to go ahead and get your contacts from your yahoo!.

A

Account, for example, and send them an invitation to connect.

A

So this is you authorizing someone to do something with resources that belongs to you.

A

Openid connect takes this a step further and introduces authentication,, which means now it's almost like a password.

A

I get to know who you are., and this has some useful applications as well.

A

Additionally, the standard introduces some other functionality,, such as establishing a session.

A

That way,, if you're accessing resources once or twice, in this case, an api, for example,, you don't need to give that authentication authorization. Every single time.

A

That is convenient.. It does have this session management, in addition to a log out.

A

All right,, let's continue.,.

A

What can it do for you?

A

on the context of protecting apis,, we can tell the apis, who you are.

A

So you can find out who you are as a proxy between you, as a gateway between you,, the consumer and the apis.

A

And then we can also help those microservices and apis figure out what you can or cannot do.

A

So why is this good for api security??

A

There are other mechanisms we can use certificates, for example.

A

We already heard of using api keys of all the caveats that comes with.

A

Well, the number one is: it is a widely adopted standard that a lot of providers out there,, I'm sure you've heard of them on something like active directory or cognito or.

A

Authzero and the like. so because there are quite a few implementations and it's ubiquitously available,, you will improve the security.

A

With it being standard and improve the chances of it being adopted.

A

And with an identity provider, usually centralize all the access, controls.

A

That means that we don't have to define our access controls and all the consumers over and over in the api gateway and all the systems that we have instead are centralized.

A

For example,, if someone leaves the company,, we can go to one place and say, well, all the access that person has is now gone.

A

Furthermore,, we reduce the risk.- I just mentioned using api keys, for example,, and that will be a thing of the past.

A

Instead, with openid connect, you'll typically have the token issued to you,, which is a short-lived credential that is used for a period of time and then is.

A

No longer useful., so let's say it leaked by chance.

A

well, that token only has a certain amount of lifetime and once it's over, it's it's not something that can be exploited.

A

So here is a sample use case that shows one of the many flows that openid connect can helpyou implement.

A

You take a look at this diagram, you'll see the actors in the flow.

A

A consumer that wants to consume some type of api,. Usually we call it an upstream.

A

An upstream is the name that we use interchangeably with an api or microservice.

A

And the gateway is typically where we do all of the protections for those upstream services.

A

And we introduce this player called the identity provider that will help the proxy figure out if the consumer can or cannot access. Those upstream.

A

Services. and the authorization code flow would go something like this.

A

The client comes to the gateway and says,. I would like to access and make this request.

A

The gateway says, ok,, please go to the idp, so the idp can figure out who you are and let me know.

A

You go ahead and get directed to the idp..

A

You exchange. Whatever information you would like,, maybe even you apply two-factor authentication, for example, and then you redirect it back to the gateway. With that token,.

A

That we talked about. that token is taken by the gateway and validated from the idp.

A

And finally, we let you through to access the upstream service.

A

Now, this is one flow., there are a few others. and we will demonstrate those today.. I will begin by showing you the authorization code flow.

A

And then we will switch from there to a bearer token,, which is another mechanism that a consumer can use to identify themselves through the gateway.

A

And finally, we'll do something interesting,, which is we are going to inject a header, which is a bit of information that can be useful.

A

To an upstream service, when they're dealing with the consumer, (header injection).

A

Now, before I jump into this,, I want to warn you that openid connect can be a little complex.

A

And this is just the short presentation, 20 minutes to give you an idea about it.

A

If you go and read any of the documentation or specifications out there.

A

Don't be surprised if you see these terms, idp,, as,, sts,, iss,, etc.

A

This basically defines the identity provider,, the resource owner,, the resource consumer, is the person trying to access something (in this case the api or micro.

A

Service), the resource server, where the api or microservice actually live.

A

And finally, the relying party, which in this case is the gateway.

A

And the gateway can also be thought of as a proxy resource server.

A

Ok, with all the foundation out of the way,, let's now go and do a demonstration.

A

I will first show you the gateway and where we can have configurations for an upstream service and how to protect it.

A

If you're not familiar with this user interface,, not to worry,, this is the administrative user interface for the kong gateway.

A

In here, we can register all the upstream services that we work with.

A

And then we can decide how to expose them.

A

And once we decide how to expose them,, we can say, right,, let's apply policies.

A

In this case, I'll show you a policy specifically for working with an identity provider called keycloak.

A

And this basically protects anyone who tries to access this stuff by saying, "?.". So if I click on view over here,.

A

You can see, I have the openid connect policy being enforced.

A

So, let's see this in action., a typical consumer will go to the gateway and say,. I would like to make this request. Oidc .

A

This is an example of a person to machine communication where this person will now be authenticated and authorized.

A

So I'll go ahead and put my username and my password.

A

Notice I got redirected from the proxy.

A

and once I log in.

A

it will redirect me back into the proxy.

A

And you will notice here we have this token..

A

This is basically the identity provider telling the proxy, "here you go.

A

Here is the information I know about this person.".

A

Let me show you what that looks. Like. it's using the standard, jwt certified copy from here.

A

I'll go to jwt.io., it's a.

A

Self-Contained envelope and you can see all the information that identifies the person who's trying to consume the service.

A

Notice, for example, that you can see the same email address that I put.

A

So this is a short example,. I repeat, once again, the consumer goes to the gateway,. The gateway says you cannot access this resource without knowing who you, we go to.

A

The idp, the idp, gives me that token,, the gateway sees the token, figures out, who you are ,and lets you in. well,. Let's take another example.

A

Let's assume, you already have a token and you want to come to the gateway, and then you want the gateway to once again let you through.

A

We'll use a different user interface to test this use. Case.

A

It's a classic tool.

A

I'm sure you've seen something like this.. This is called the insomnia. and you can use any others that you like. so in here,. What I will do,.

A

Is I'm going to the gateway and getting a token.

A

And then I'm using that token that I got from the idp and I will pass it to the gateway and.

A

I will do this in this step. Here. notice, I'm getting the response that I've gotten before.

A

same thing: happens., the gateway is able to take the token and figure out who I am and then let me through.

A

So let me go ahead and send this through.

A

And you can notice once again, I'm able to get a response.

A

So these are two use cases that we've done so far..

A

Let me switch back to the browser and then we'll do a third interesting use. Case.. Let's assume that there is.

A

Something in the information we know about the user that may be necessary for an upstream service to look at.

A

So if we take a look over in this token,, you will see that we have the scope.

A

We have information about this. User..

A

A scope is a way for me to say, well,. These are the application that this user has access, to.

A

Remember, we talked about the authentication and authorization.

A

Well,, here's a benefit right. There is what are you authorized to do?.

A

The gateway has access to this information..

A

What if we can extract this information and give it to a service upstream to say,, hey, look,? I authenticated this user and yes,. The token is available for me.

A

But also here, you go., here's some more information so that you as a service can take advantage of that.

A

So let me show you exactly how to do that right now, in the gateway we modified to inject this information.

A

I will make it visible in here.. Don't see right now, if I search, for example, for scope,, it is empty,, nothing there.

A

But I will modify our information in such a way that I can let that upstream service get that information.

A

So, let's head on over to the user interface that I showed you earlier.

A

And in here, I will make a small modification such that I can make this information available.

A

And we do have over here an option to specify what components of the token we want to make visible.

A

And what to name., it's called ?

A

and ?.. So let me save and update my configuration.

A

And I'm done. now, if I go and I try to access this information, again.

A

I will now have a scope available for me with this information,, which means that whatever upstream service I was working with now has this information.

A

The benefit of this is as obvious,. We don't have to write over and over,. We don't have to maintain it over and over,, and it makes it that much faster for the developers of the.

A

Upstream services that I have to get their work, done.

A

And that is all I covered the three use cases with their benefits.