AWS EC2 enabling

What are JWT claims

The JWT Claims Set represents a JSON object whose members are the claims conveyed by the JWT.  The Claim Names within a JWT Claims Set MUST be unique; JWT parsers MUST either reject JWTs with duplicate Claim Names or use a JSON parser that returns only the lexically last duplicate member name

The following Claim Names are registered in the IANA "JSON Web Token   Claims" registry established by Section 10.1. 

4.1.1.  "iss" (Issuer) Claim

The "iss" (issuer) claim identifies the principal that issued the

   JWT.  The processing of this claim is generally application specific.

   The "iss" value is a case-sensitive string containing a StringOrURI

   value.  Use of this claim is OPTIONAL.

4.1.2.  "sub" (Subject) Claim

The "sub" (subject) claim identifies the principal that is the

   subject of the JWT.  The claims in a JWT are normally statements

   about the subject.  The subject value MUST either be scoped to be

   locally unique in the context of the issuer or be globally unique.

   The processing of this claim is generally application specific.  The

   "sub" value is a case-sensitive string containing a StringOrURI

   value.  Use of this claim is OPTIONAL.

4.1.3.  "aud" (Audience) Claim

The "aud" (audience) claim identifies the recipients that the JWT is

   intended for.  Each principal intended to process the JWT MUST

   identify itself with a value in the audience claim.  If the principal

   processing the claim does not identify itself with a value in the

   "aud" claim when this claim is present, then the JWT MUST be

   rejected.  In the general case, the "aud" value is an array of case-

   sensitive strings, each containing a StringOrURI value.  In the

   special case when the JWT has one audience, the "aud" value MAY be a

   single case-sensitive string containing a StringOrURI value.  The

   interpretation of audience values is generally application specific.

   Use of this claim is OPTIONAL.

4.1.4.  "exp" (Expiration Time) Claim

The "exp" (expiration time) claim identifies the expiration time on

   or after which the JWT MUST NOT be accepted for processing.  The

   processing of the "exp" claim requires that the current date/time

   MUST be before the expiration date/time listed in the "exp" claim.

   Implementers MAY provide for some small leeway, usually no more than

   a few minutes, to account for clock skew.  Its value MUST be a number

   containing a NumericDate value.  Use of this claim is OPTIONAL.

4.1.5.  "nbf" (Not Before) Claim

The "nbf" (not before) claim identifies the time before which the JWT

   MUST NOT be accepted for processing.  The processing of the "nbf"

   claim requires that the current date/time MUST be after or equal to

   the not-before date/time listed in the "nbf" claim.  Implementers MAY

   provide for some small leeway, usually no more than a few minutes, to

   account for clock skew.  Its value MUST be a number containing a

   NumericDate value.  Use of this claim is OPTIONAL.

4.1.6.  "iat" (Issued At) Claim

 The "iat" (issued at) claim identifies the time at which the JWT was

   issued.  This claim can be used to determine the age of the JWT.  Its

   value MUST be a number containing a NumericDate value.  Use of this

   claim is OPTIONAL.

4.1.7.  "jti" (JWT ID) Claim

The "jti" (JWT ID) claim provides a unique identifier for the JWT.

   The identifier value MUST be assigned in a manner that ensures that

   there is a negligible probability that the same value will be

   accidentally assigned to a different data object; if the application

   uses multiple issuers, collisions MUST be prevented among values

   produced by different issuers as well.  The "jti" claim can be used

   to prevent the JWT from being replayed.  The "jti" value is a case-

   sensitive string.  Use of this claim is OPTIONAL.

references:

https://www.rfc-editor.org/rfc/rfc7519#section-4

Kong plugin - Modules required

In its purest form, a plugin consists of two mandatory modules:

simple-plugin

├── handler.lua

└── schema.lua

handler.lua: the core of your plugin. It is an interface to implement, in which each function will be run at the desired moment in the lifecycle of a request / connection.

schema.lua: your plugin probably has to retain some configuration entered by the user. This module holds the schema of that configuration and defines rules on it, so that the user can only enter valid configuration values

Advanced plugin modules

Some plugins might have to integrate deeper with Kong: have their own table in the database, expose endpoints in the Admin API, etc. Each of those can be done by adding a new module to your plugin. Here is what the structure of a plugin would look like if it was implementing all of the optional modules:

complete-plugin

├── api.lua

├── daos.lua

├── handler.lua

├── migrations

│   ├── init.lua

│   └── 000_base_complete_plugin.lua

└── schema.lua

Below is a possible full list of modules 

MODULE NAME REQUIRED DESCRIPTION

admin-api.lua No Defines a list of endpoints to be available in the Admin API to interact with the custom entities handled by your plugin.

daos.lua No Defines a list of DAOs (Database Access Objects) that are abstractions of custom entities needed by your plugin and stored in the data store.

handler.lua Yes An interface to implement. Each function is to be run by Kong at the desired moment in the lifecycle of a request / connection.

migrations/*.lua No The database migrations (e.g. creation of tables). Migrations are only necessary when your plugin has to store custom entities in the database and interact with them through one of the DAOs defined by daos.lua.

schema.lua Yes Holds the schema of your plugin’s configuration, so that the user can only enter valid configuration values.

references:

https://docs.konghq.com/gateway/latest/plugin-development/file-structure/

Kong Plugin Implementing custom Logic

A Kong Gateway plugin allows you to inject custom logic (in Lua) at several entry-points in the life-cycle of a request/response or a tcp stream connection as it is proxied by Kong Gateway. To do so, the file kong.plugins.<plugin_name>.handler must return a table with one or more functions with predetermined names. Those functions will be invoked by Kong Gateway at different phases when it processes traffic.

The first parameter they take is always self. All functions except init_worker can receive a second parameter which is a table with the plugin configuration.

main entry points are

init_worker

certificate

rewrite

access -> Executed for every request from a client and before it is being proxied to the upstream service.

ws_handshake -> Executed for every request to a WebSocket service just before completing the WebSocket handshake.

response -> Executed after the whole response has been received from the upstream service, but before sending any part of it to the client.

header_filter -> Executed when all response headers bytes have been received from the upstream service.

ws_client_frame -> Executed for each WebSocket message received from the client.

ws_upstream_frame -> Executed for each WebSocket message received from the upstream service

body_filter -> Executed for each chunk of the response body received from the upstream service. Since the response is streamed back to the client, it can exceed the buffer size and be streamed chunk by chunk. This function can be called multiple times if the response is large

log -> Executed when the last response byte has been sent to the client.

ws_close -> Executed after the WebSocket connection has been terminated.

 

references:

https://docs.konghq.com/gateway/latest/plugin-development/custom-logic/ 

How Does Kong Configurations work

Pretty much at high level, it is explained here.

The configurations are stored in kong.conf file.

# -----------------------

# Kong configuration file

# -----------------------

#

# The commented-out settings shown in this file represent the default values.

#

# This file is read when `kong start` or `kong prepare` are used. Kong

# generates the Nginx configuration with the settings specified in this file.

#

# All environment variables prefixed with `KONG_` and capitalized will override

# the settings specified in this file.

# Example:

#   `log_level` setting -> `KONG_LOG_LEVEL` env variable

#

# Boolean values can be specified as `on`/`off` or `true`/`false`.

# Lists must be specified as comma-separated strings.

#

# All comments in this file can be removed safely, including the

# commented-out properties.

# You can verify the integrity of your settings with `kong check <conf>`.