 Hello everyone, my name is Claudio Coviva and I'm a software architect here at Conq. This is the first video in a series of four where I'll be showing the integration of Conq Connect, Enterprise and Nocta IdentiProvider to implement some of the main OpenID Connect-based authentication and authorization use cases. The Conq Connect and Nocta integration topology is depicted here in this diagram. As you can see the gateway has been split in two sub-layers. The first one up there is the control plane, used by admins to create new APIs and policies. And then the control plane responsible for publishing those APIs and policies to the data plane, which is the second sub-layer responsible for the actual request processing and API consumption. My topology has two data planes. The first one running locally and the second running as a stocker container in an AWS EC2 instance. The integration is possible because Conq provides a specific plugin to implement the OAuth OpenID Connect flows from the gateway side. So in this sense the consumer will be submitted to Nocta's authentication processes before being allowed to consume the API. I have chosen the following use cases for this series. The first one, client credentials for application authentication, second one, authorization code for user authentication, third one, introspection for token validation, and access control based on Nocta's groups and planes. Again today I'm going to demo the client credentials flow, typically used for application authentication. Let's get started. Initially a brief description of Conq Connect Enterprise. Connect is a cloud native connectivity platform that has been hosted as a service and can take care of all connectivity use cases across any environment including virtual machines and Kubernetes for both gateway and mesh and for both north, south, east, west traffic. So here's the Conq Connect Enterprise control plane admin GUI showing the service I have created before in the SEVSE Hub. SEVSE Hub is the harder Conq Connect. It stores all existing services definitions and allows admins and developers to search, discover, consume, and reuse those services. So let's check the service. The service here has only one version, but if necessary you can define multiple versions with different definitions and policies. If we click on the version we're going to see that the service is already being exposed by some routes. Today we're going to consume and protect the slash OIDC route. However, no policy is enabled to it, so anyone can start consuming the route without any restriction. And then in this sense it will be very, very critical to define and apply policies in order to control its consumption. And these policies in our case again will be openly Conq Connect based. Besides Conq Connect, my demo environment has some previously created octa applications. As a matter of fact, they are two of them. For today's session, we're going to use the Conq Connect credentials app. So now it's time to create our Conq Connect data plane running on an AWS EC2 instance as a Docker container. The EC2 is already running and Docker is already installed. The control plane has a specific component called runtime manager, which is responsible for monitoring the data planes we have instantiated so for. If we click on configure runtime, we're going to see the script it should run to instantiate a Docker based data plane. So here's my EC2 terminal here. And now we're going to run the script in order to get our first data plane up and running. I have already updated the script in order to use my Conq Connect credentials. So we are pulling the conq Docker image and ready to launch and join the flight. So data plane is not just deployed, but all the APIs, they are already available for me from the API consumption perspective. So if we try to consume it, sending a request for 8,000 to OIDC route slash get, we consuming the route as expected. However, since we don't have any policy in place to control the route consumption, I'm able to send as many requests as I want. So let's go back to connect control plane to define the open interconnect based policy and control the route consumption, the version, the route, the open interconnect plugin and configure to protect the route. Here's the open interconnect plugin. The plugin is expecting four parameters in order to integrate the octa. First of all, the client ID parameter, which is here issued by octa. The second is the client secret. The third, I would say the most important one, that's the issuer. That's the octas endpoint. So the data plane will be able to connect to it and then implement the open interconnect authentication process. Finally, the last one is the scope. I have created the scope one scope for these them over here. So now we're able to save our settings, new settings. And then now we can see the client credentials route has got a plugin able to it, the open interconnect plugin. And 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 credentials. So if we try to send the same request, but this time, including our credentials, again the client ID and client secret, we'll be able to consume the route. In fact, if we take this token here, if we use it in this JWT.io website, we'll be able to decode the token and check all the fields inside of it. So one last capability I'd like to show you today, provided by the open interconnect plugin, is what we call upstream header injection. That means I'm going to extend the request with extra headers based on the token issued by Octa. In this sense, the upstream or microservice behind the data plane, we'll be able to receive more information about the authentication process. As an exercise, I'm going to inject a header based on the ISS field, which is Octa's issuer endpoint. So again, let's go back one more time to conconnect control plane in order to set an extra open interconnect plugin parameters. This time will be upstream headers claims with ISS field, and then we're going to call our new header as issuer header. Let's consume the route one more time. That concludes my first Kong and Octa demo. Hope you see you in the next video. Thanks a lot.