Assume you have an in-house authentication which has already been used by your users. It can issue and validate JWT tokens and manage ACL but you still see yourself building custom code in each microservice to integrate with the custom auth service.
Leverage Kong with a custom plugin to centralize the integration and allow each microservice to focus on the business logic.
- Download or clone the repository under the directory
/usr/local/share/lua/5.1/plugins.
/usr/local/share/lua/5.1/kong/plugins
|-- custom-auth
|-- schema.lua
|-- handler.lua
|-- access.luaa
- Configure Kong to load the plugin by adding
custom-authto thepluginsproperty of yourkong.conf(usually in/etc/kong/kong.conf) or viaKONG_PLUGINSenvironment variable.
plugins = custom-auth
- If using Kong Enterprise you should be able to find the custom plugin at the bottom of the plugins page.
- If using a declarative configuration see the example below of how to enable this plugin in a service.
{
"_format_version": "2.1",
"_transform": true,
"services": [
{
"name": "example-service",
"url": "http://example.com",
"routes": [
{
"name": "example-route",
"paths": ["/"]
}
],
"plugins": [
{
"name": "custom-auth",
"config": {
"validation_endpoint": "http://example.com/auth/validate/token",
"token_header": "Authorization",
"ssl_verify": true,
},
},
],
},
],
"consumers": [
{
"username": "example-user"
},
],
}
config.validation_endpoint: your auth endpoint that check if the token passed in the Authorization header (or the one defined intoken_header) is valid.config.token_header: the name of the header where the token will be sent (defaults toAuthorization). If the token is not found in the defined header, the plugin will look for a cookie namedtokenand pass it as aAuthorizationheader to your auth service.config.ssl_verify: whether to perform SSL verification (see https://github.com/openresty/lua-nginx-module#tcpsocksslhandshake for details)
schema.lua: Schema of the plugin configuration fields.handler.lua: Interface declaring functions to run in the lifecycle of a request/connection.accecss.lua: This file is invoked byhandler.luaand has the actual authentication logic.