Kong Kong Tutorials, 13 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Okta and Kong Konnect Part 1: Implementing Client Credentials

Description

Learn how to set up client credentials flow for application authentication with Okta and Kong Konnect. Learn more about Konnect and start a free trial: https://bit.ly/3vDuUBz

• Konnect and Okta Integration Topology (0:23)
• Set Up Konnect Service and Route (2:23)
• Set Up Okta (3:42)
• Create Konnect Data Plane (4:10)
• Consume the Route without a Policy (5:10)
• Add OpenID Connect Plugin (5:44)
• Test the OpenID Connect Plugin (7:23)
• Upstream Header Injection (8:06)

Using Kong’s OpenID Connect (OIDC) plugin, Kong and Okta work together to solve three significant application development challenges:
1. Connectivity
2. Authentication
3. Authorization

The OIDC plugin enables Kong, as the API gateway, to communicate with Okta via the OAuth/OIDC flows. That way, your app teams don’t have to configure and diagnose authentication and authorization for each service individually. With these challenges solved, app teams have more time to build and innovate.

This series will show you how to implement service authentication and authorization for Kong Konnect and Okta using the OIDC plugin. In this tutorial, we’ll cover client credentials flow for application authentication. Parts 2-4 will cover:
• Authorization code for user authentication
• Integral introspection for token validation
• Access control based on Okta's groups and planes

Read the full tutorial blog post: https://bit.ly/3eJd62p

Contact us if you have any questions as you’re getting set up: https://support.konghq.com/support/s/

Once you’ve set up Konnect and Okta, you may find these other tutorials helpful:
• 3 Ways Kong Helps With API Gateway Governance: https://bit.ly/3ujZDCY
• Getting Started with Kong Mesh and Open Policy Agent: https://bit.ly/3o8Cq4U
• Protect Your APIs With Kong Konnect and Fastly (Signal Sciences): https://bit.ly/3ogiVr1

#Okta #OIDC #API #OpenIDConnect #Konnect #APIsecurity #OAuth

A

Hello, everyone,, my name is claudio aquavivia and I'm a software architect here at kong.

A

This is the first video in a series of four, where I'll be showing the integration of kong, konnect enterprise and okta identity provider to implement some of the main openid.

A

Connec-Based authentication and authorization use cases.

A

The kong konnect and okta integration topology is depicted here in this diagram.

A

As you can see,, the gateway has been split in two sublayers.

A

The first one up there is the control plane used by admins to create new apis and policies.

A

And then the control plane responsible for publishing those apis and policies to the data plane,, which is the second sublayer responsible for the actual request, processing.

A

And api conception., my topology has two data: points,, the first one running locally and the second running as a docker container in an aws ec2 instance.

A

., the integration is possible because kong provides a specific plugin to implement the oauth openid connect flows from the gateway side.

A

So in this sense, the consumer will be submitted to okta's authentication processes before being allowed to consume the api.

A

I have chosen the following use: cases for this series.

A

The first one, client credentials for application authentication.

A

Second, one authorization code for user authentication.

A

Third, one integral introspection for token validation.

A

And access control based on okta's groups and planes.

A

Again, today, I'm going to demo the client credentials, flow, typically used for application. Authentication.

A

Let's get started. initially, a brief description connecting kong konnect enterprise.

A

Konnect is a cloud native connectivity platform that has been hosted as a service and can take care of all connectivity use cases.

A

Across any environment,, including virtual machines and communities for both gateway and mesh, and for both north,.

A

South,, east-west traffic., so here's the kong konnect enterprise admin, gui admin gui, showing the service I have created before in the servicehub.

A

Service hub is the heart of kong konnect..

A

It stores all existing service definitions and allows admins and developers to search, discover,, consume, and reuse. Those services.

A

So, let's check the service..

A

The service here has only one version,, but if necessary, you can't define multiple versions with different definitions and policies.

A

If we click on the server on the version,, we're going to see that a service is already being exposed by some routes.

A

Today, we're going to consume and protect the /oidc route.

A

However,, no policy is enabled to it.

A

So anyone can start consuming the route without any restriction.

A

And then, in this sense, you be very, very critical to define and apply policies in order to control this consumption.

A

And these policies in our case, again, will be openid connect, based.

A

Besides kong konnect,, my demo environment has some previously created okta applications.

A

As a matter of fact,, there are two of them.

A

for today's session, we're going to use the kong client credentials. App.

A

So now it's time to create our konnect data plane running on an aws ec2 instance on a docker container.

A

The ec2 is already running, and docker is already installed.

A

The control plane has a specific component called run time, manager,, which is responsible for monitoring the data.

A

Planes we have instantiated so far.

A

If click on configure runtime.

A

We're going to see the script ??

A

to instantiate a docker-based data plane.

A

So here's my ec2 terminal, here.

A

And now you're going to run the script in order to get our first data plane up and running.

A

I have already updated the script in order to use my kong konnect credentials.

A

So we are pulling from kong, docker image.

A

And ready to launch, enjoy the flight.

A

So data plane is not not just deployed, but all the apis,. They are already available for me from the api consumption perspective.

A

So if we try to consume it.

A

Sending a request to port 8000 to oidc route /get.

A

We're consuming the route as expected.

A

However,, since we don't have any policy in place to control the route consumption,, I'm able to send many requests. As I want.

A

. so let's go back to konnect control plane to define the openid connect-based policy control, the route consumption.

A

So here the version.

A

A

and then we're going to add the openid connect plugin.

A

And configured to protect the route is the openid connect, plugin.

A

The plugin is expecting four parameters in order to to integrate with okta.

A

First of all,, the client id parameter.

A

Which is here issued by okta.

A

The second is the client secret.

A

The third,, I would say the most important one,, that's the issuer and okta's end point.

A

So the data plane will be able to connect to it and then implement the openid connect, authentication, process.

A

Finally,, the last one is the scope.

A

I have created the scope for these over here.

A

So now we're able to save our settings, new settings.

A

And then now you can see the client credentials throughout is ??.

A

The openid connect plugin.

A

If we go back to our terminal and try to consume the route, this time, the api gateway won't allow us, because we're not providing the.

A

Credentials., so if we try to send the same request,, but this time,, including our credentials, again,, the client, id and client.

A

Secret, we'd be able to consume the route.

A

In fact,, if you take this token here, issued by okta, and then we use.

A

It in the jwt.io website we will be able to decode the token and check all the fields inside of it.

A

So one last capability, I'd like to show you today provided by the openid connect plugin, is what we call upstream header injection.

A

That means I'm going to extend the request with extra headers, based on the token issued by okta.

A

This sends the upstream or microservice behind the data plane will be able to receive more information about the authentication, process.

A

As an exercise,, I'm going to inject a header based on the iss field,, which is okta's issuer endpoint.

A

So, again,: let's go back one more time to kong, konnect control, plane.

A

In order to set an extra openid connect, plugin parameters.

A

This time will be upstream headers, claim.

A

Headers claims with iss viewed, and then we were going to call our new header.

A

As issuer header., then we're going to update the plugin again.

A

That's consumed the route, one more time.

A

And then,, as you can see,, we got a brand new header injected in our request.

A

That concludes my first kong and okta demo.

A

I hope to see you in the next video. thanks a lot.