kong-konga-keycloak:在docker中安装kong，keycloak和konga并测试API身份验证的简短教程

# Kong / Konga / Keycloak: securing API through OIDC ## Credits [Securing APIs with Kong and Keycloak - Part 1](https://www.jerney.io/secure-apis-kong-keycloak-1/) by Joshua A Erney ## Requirements - [**docker**](https://docs.docker.com/install/) - [**docker-compose**](https://docs.docker.com/compose/overview/) - [**jq**](https://stedolan.github.io/jq/) - [**curl** cheatsheet ;)](https://devhints.io/curl) - Patience - :coffee: ## Installed versions - Kong 2.0.4 - alpine - Konga 0.14.7 - Keycloak 10.0.2 ## Goal of this tutorial The goal of this tutorial is to be able to protect, through the configuration of kong and keycloak, an API resource. More in details, let's consider the following request flow:  1. The user application sends a request to the API gateway (kong). However, the request is either not authenticated (or contains an invalid authentication). 2. The gateway API responds to the client indicating the lack of authentication. 3. The application therefore needs to log in. Therefore it sends a specific request for login to the Single Sign On (Keycloak), including the user's credentials and the specific client-id assigned to the application itself. 4. If the credentials are valid, the SSO (Keycloak) issues to the application a token (and the related refresh token), with which to authenticate the requests to the Gateway API (Kong) 5. The application then repeats the request adding the valid token as an authorization 6. Behind the scenes, the gateway API will proceed to verify (through introspection) that the token in question corresponds to a session on the Single Sign On (Keycloak). 7. The result of the introspection is returned to Kong, who will handle the application request accordingly 8. If the outcome of introspection is positive, Kong will handle the request. Alternatively we will be in step 2 (the request is refused) Note: The application can log in to keycloak even before sending the first request. Indeed it is normally so, if we think of the case of a mobile app: once the credentials have been entered, the user may have chosen to remain connected (so at most the application will request a new valid token using the refresh token). --- ## 0. Introduction I reviewed the content of this page, and I decided to turn it into a complete guide and translate it from Italian to English to make it universal to read: the previous version was a summary of the article indicated among the credits (whose reading is useful for understanding what follows). I also advise you to read the various reference links, as they are useful for further investigation. The _docker-compose.yml_ file already contains the entire "infrastructure" described in the article. The purpose of this README is to adapt the content of the article to the current versions of the applications and possibly add some informative details where necessary. :danger: _Warning_- Inside the _docker-compose.yml_ there are default credentials and the installation you get is not a _production-ready_ system. ## 1. Create the image of Kong + Oidc [kong-oidc](https://github.com/nokia/kong-oidc) is a kong plugin that allows you to implement OpenID Connect RP (Relying Party). ### 1.1 Brief introduction to OIDC OpenID is a simple level of identity implemented above the OAuth 2.0 protocol: it allows its Clients to verify the identity of the end user, based on the authentication performed by an Authorization Server, as well as to obtain basic information on the user profile. With a Security Token Service (STS), the RP is redirected to an STS, which authenticates the RP and issues a security token that grants access, instead of the application that directly authenticates the RP. Claims are extracted from tokens and used for identity-related activities. The OpenID standard defines a situation in which a cooperating site can act as an RP, allowing the user to access multiple sites using a set of credentials. The user benefits from not having to share access credentials with multiple sites and the operators of the collaborating site must not develop their own access mechanism. :point_right: Useful Links - [Relying Party](https://en.wikipedia.org/wiki/Relying_party) - [Claims based identity](https://en.wikipedia.org/wiki/Claims-based_identity) - [OpenID](https://en.wikipedia.org/wiki/OpenID) ### 1.2 Construction of the docker image Compared to the setting proposed by the author of the article from which we started, we will proceed to implement an image based on alpine linux. We will just have to give the command: ```bash docker-compose build kong ``` and wait for the image to build. ## 2. Kong DB + Database Migrations Kong uses a database server (postgresql in our case). For this reason it is necessary to initialize the database by launching the necessary migrations. First we start the kong-db service: ```bash docker-compose up -d kong-db ``` Let's launch kong migrations: ```bash docker-compose run --rm kong kong migrations bootstrap ``` :raised_hand: In case you're upgrading kong from previous versions, probably you may need to run migrations. In this case, you can give this command: ```bash docker-compose run --rm kong kong migrations up ``` At this point we can start kong: ```bash docker-compose up -d kong ``` Let's verify that you have the two services running: ```bash docker-compose ps ``` And finally, let's verify that the OIDC plugin is present on Kong: ```bash curl -s http://localhost:8001 | jq .plugins.available_on_server.oidc ``` The result of this call should be `true`. The presence of the plugin does not indicate that it is already active. ## 3. Konga Konga is an administration panel for Kong. It offers us a visual panel through which to carry out Kong's configurations (as well as inspect the configurations made from the command line). We start konga with the command: ```bash docker-compose up -d konga ``` Konga is listening on port 1337. Therefore we launch a browser and point to the url [http://localhost:1337](http://localhost:1337). The first time we log in to konga we will need to register the administrator account. For tests, use simple, easy-to-remember credentials. For production systems, use passwords that meet safety standards! After registering the administrator user, it will be possible to log in. Once logged in, we will need to activate the connection to Kong. Enter in "Name" the value "kong" and as "Kong Admin URL" the following address: `http://kong:8001` then save. At this point we will have our instance of Konga ready for use! ## 4. Creation of a service and a route To test the system, we will use [Mockbin](http://mockbin.org/) (a service that generates endpoints to test HTTP requests, responses, sockets and APIs). As a reference, please refer to [Kong's Admin API](https://docs.konghq.com/1.3.x/admin-api). ```bash $ curl -s -X POST http://localhost:8001/services \ -d name=mock-service \ -d url=http://mockbin.org/request \ | python -mjson.tool { "connect_timeout": 60000, "created_at": 1556145691, "host": "mockbin.org", "id": "46ddff80-4368-49fa-9f4b-b0f67f9296ad", ... } ``` Make a note of your service id (in the example it is e71c82d3-2e53-469b-9beb-a232a15f86d4) and use it to make the next call to kong's api that allows you to add a route to the service. ```bash $ curl -s -X POST http://localhost:8001/services/e71c82d3-2e53-469b-9beb-a232a15f86d4/routes -d "paths[]=/mock" \ | python -mjson.tool { "created_at": 1556146020, "destinations": null, "hosts": null, "id": "7990c9ee-7b30-4ff5-b230-e20f85a565d3", "methods": null, "name": null, "paths": [ "/mock" ], ... } ``` We verify that everything works: ```bash $ curl -s http://localhost:8000/mock { "startedDateTime": "2019-04-24T22:49:26.886Z", "clientIPAddress": "172.20.0.1", "method": "GET", "url": "http://localhost/request", "httpVersion": "HTT