Apigateway-kong (vi) certification

Traffic to upstream services (APIs or microservices) is usually controlled by the application and configuration of various Kong certified plug-ins. Because the service entity of Kong represents the 1-to-1 mapping of its own upstream services, the simplest scenario is to configure the authentication plug-in on the selected service.

General Certifications

The most common scenario is that authentication is required, and no unauthenticated requests are allowed to be accessed. To achieve this, you can use any authentication plug-in. The common scenarios/processes for these plugins are as follows:

1. Add Auth plug-ins to an API or globally (it cannot be applied to consumer)
2. Create a consumer entity
3. Provide authentication credentials for a specific authentication plug-in scenario for consumer
4. Now, whenever a request is entered, Kong will check the credentials provided (depending on the auth type) and if the request cannot be verified it will block the request or add the user and credential details in the header and forward the request

The general process above is not always applicable, for example, when an external authentication (such as LDAP) is used, consumer is not recognized and only the credentials are added to the forwarded header (forwarded headers).

Specific elements and examples of the authentication method can be found in each plugin's documentation

Consumers

The simplest way to understand and configure consumer is to map it to the user one by one, however, this is not important. The core principle of consumer is that you can add plugins to it to customize the request behavior. So you may have a mobile app and define a consumer for each application or its version. or each platform has a consumer, such as Android consumers, iOS consumers and so on.

This is an opaque concept for Kong, so they are called "consumers" rather than "users".

Anonymous Access

Before the Kong 0.10.x release, you can configure the specified API to allow only authenticated access (implemented through plug-ins) or only anonymous access. That is, a specified API does not allow authentication for some consumer and anonymous access for another consumer.
These restrictions were canceled after the 0.10.x version. Kong can configure a given service to allow authentication and anonymous access, and you can use this configuration to grant access to anonymous users with a low rate limit and to grant access to authenticated users with a higher rate limit.

To configure the service in this way, you first apply the selected authentication plug-in, then create a new consumer to represent the anonymous user, and then configure your authentication plug-in to allow anonymous access.
Here is an example, assuming you have configured a service named Example-service and the corresponding route:

1. Create a sample service and Route

Issue the following curl request to create a example-service that points to mockbin.org, which responds to the request:

$ curl-i-X POST   --url http://localhost:8001/services/\  'name= Example-service 'url=http://mockbin.org/request'    

Add a route to the service:

$ curl-i-X POST   --url http://localhost:8001/services/example-service/routes \   'paths[]=/auth-sample'

URL http://localhost:8000/auth-sample will now respond to the content being requested

2. Configure the Key-auth plugin for the service

Perform the following Curl request to add a plug-in to the service:

$ curl-i-X POST   --url http://localhost:8001/services/example-service/plugins/\  'name=key-auth'

Remember to create the plugin ID, which is used in step 5.

3. Verify that the Key-auth plug-in is configured correctly

Issue the following curl request to verify that the Key-auth plug-in is properly configured on the service:

$ curl-i-X GET   --url http://localhost:8000/auth-sample

Because the required apikey is not specified in the header or parameter, and anonymous access has not been enabled , the response should be 403 Forbidden:

http/1.1403  Forbidden ... {  "message""No API key found in headers or querystring" }

4. Create an anonymous consumer

Each request by the Kong agent must be associated with the consumer. Now you will create a consumer named Anonymous_users (Kong will use it when proxy anonymous access) by issuing the following request:

$ curl-i-X POST   --url http://localhost:8001/consumers/\  " username=anonymous_users "

You will see a response similar to the following:

http/1.1 201createdcontent-type:application/Jsonconnection:keep-alive{"username":"anonymous_users",  "Created_at":1428555626000,  "ID":"BBDF1C48-19DC-4AB7-CAE0-FF4F59D87DC9"}

Remember this consumer ID and the following steps will be used.

5. Enable Anonymous Access

The Key-auth plug-in is now reconfigured to allow anonymous access by issuing the following request (replace the UUID values in steps 2 and 4 with the following example UUIDs)

$ curl-i-X PATCH   --url http://localhost:8001/plugins/<your-plugin-id> \  "config.anonymous=<your-consumer-id>"

config.anonymous = <your-consumer-id> parameter indicates that the Key-auth plugin on this service allows anonymous access and associate this access with the consumer ID that we received in the previous step. Provide a valid and pre-existing consumer ID in this step-when you configure anonymous access, the ID of the consumer is not verified, and if a non-existent or incorrect consumer ID is configured, the configuration error plug-in does not work correctly.

6. Verifying Anonymous Access

Confirm that your service now allows anonymous access by issuing the following request:

$ curl-i-X GET   --url http://localhost:8000/auth-sample

This is the same as the request made in step #, but the request should succeed because anonymous access is enabled in step # #.

Response roughly include these fields:

{  ...  "Headers": {    ...    "X-consumer-id":"713c592c-38b8-4f5b-976f-1bd2b8069494",    "X-consumer-username":"anonymous_users",    "X-anonymous-consumer":"true",    ...  },  ...}

The request returned successfully, but was anonymously accessed.

Multiple authentication

Kong supports multiple authentication plug-ins for a given service, allowing different clients to access a given service or route using different authentication methods.
When evaluating multiple authentication credentials, you can set the behavior of the Auth plug-in to perform a logical and or logical OR. The key to this behavior is to configure the Config.anonymous property.

• Config.anonymous is not set by default, and if this property is not set (empty), the validation plug-in will always perform validation and, if not verified, returns a 40x response. This results in a logical and when multiple auth plug-ins are called.
• The config.anonymous is set to a valid consumer ID. In this case, the Auth plugin performs authentication only if it is not yet authenticated. When authentication fails, it does not return a 40x response, but instead sets the anonymous consumer to consumer. When more than one validation plug-in is invoked, or+ is used anonymously.

Note1: All or any of the authentication plug-ins can be configured to make anonymous access. However, if you want to mix the authentication plug-in, the configuration for anonymous access needs to be screened, or there will be confusion.

Note2: If you use the and logic, the last validation plug-in will be the one that passes the validation information to the upstream service. When using the or logic, the plug-in that is passed to the upstream service validation information will be the first plug-in that successfully verifies the consumer, or the last plug-in that is configured with anonymous access.

Note3: When using the OAuth2 plug-in with and, the OAUTH2 endpoint used to request tokens will also need to be authenticated by other configured auth plug-ins.

Attention:

When multiple authentication plug-ins are enabled in or on a given service and you want anonymous access to be disabled, you should configure the Request-termination plugin on the anonymous consumer, or it will allow unauthorized requests.

Apigateway-kong (vi) certification