Kong（v1.0.2）認證

介紹

上游服務(api或微服務)的流量一般由各類Kong的authentication plugins的應用程序和配置控制。因爲Kong的服務實體表示您本身的上游服務的一對一映射，因此最簡單的場景是在您選擇的服務上配置身份驗證插件。

通用認證

最多見的場景是須要身份驗證，不容許對任何未經身份驗證的請求進行訪問。要實現這一點，可使用任何身份驗證插件。這些插件的通常方案/流程以下:

1. 將身份驗證插件應用於服務，或全局(您不能將其應用於使用者)
2. 建立consumer實體
3. 爲consumer提供特定身份驗證方法的身份驗證憑據
4. 如今，每當請求進入Kong時，它將檢查提供的憑證(取決於身份驗證類型)，若是沒法驗證，它將阻塞請求，或者在header中添加使用者和憑證詳細信息並轉發請求

上面的通用流並不老是適用的，例如在使用LDAP之類的外部身份驗證時，就沒有要標識的使用者，而且只在轉發的頭中添加憑證。

在每一個插件的文檔plugin’s documentation中均可以找到特定於身份驗證方法的元素和示例。

消費者

對於consumer最簡單的方法是將他們一對一地映射到用戶。然而，這對KOng來講並不重要。對於使用者來講，核心原則是能夠將插件附加到它們上，從而定製請求行爲。你可能有移動應用，爲每一個應用定義一個消費者，或它的版本。或者每一個平臺都有一個消費者，例如android消費者、iOS消費者等等。

對於Kong來講，這是一個不透明的概念，所以他們被稱爲「consumers」，而不是「users」。

匿名訪問

Kong可以配置給定的服務，以容許身份驗證和匿名訪問。您可使用此配置將訪問權限授予具備較低速率限制的匿名用戶，並將訪問權限授予具備較高速率限制的通過身份驗證的用戶。

要配置這樣的服務，首先應用所選的身份驗證插件，而後建立一個新的使用者來表示匿名用戶，而後配置身份驗證插件以容許匿名訪問。下面是一個示例，它假設您已經配置了一個名爲example- Service的服務和相應的路由:

一、建立示例服務和路由

發出如下cURL請求，建立example-service指向mockbin.org，該服務將響應該請求:

 

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

Add a route to the Service:

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

The url http://localhost:8000/auth-sample will now echo whatever is being requested.

 

 

2、爲您的服務配置key-auth插件

發出如下cURL請求，將插件添加到服務中:

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

請務必注意建立的插件id——在步驟5中須要它。

三、驗證key-auth插件配置正確

發出如下cURL請求，驗證key-auth插件是否在服務上正確配置:

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

因爲您沒有指定所需的apikey頭文件或參數，而且您尚未啓用匿名訪問，所以響應應該是403禁止的:

 HTTP/1.1 403 Forbidden  ... { "message": "No API key found in headers or querystring" } 

四、建立匿名consumer

Kong代理的每一個請求都必須與一個consumer相關聯。如今，經過發出如下請求，您將建立一個名爲anonymous_users的使用者(Kong將在代理匿名訪問時使用該使用者):

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

You should see a response similar to the one below:

 HTTP/1.1 201 Created  Content-Type: application/json  Connection: keep-alive { "username": "anonymous_users", "created_at": 1428555626000, "id": "bbdf1c48-19dc-4ab7-cae0-ff4f59d87dc9" } 

請務必注意consumer id——您將在下一個步驟中須要它。

五、容許匿名訪問

您如今將從新配置key-auth插件，經過發出如下請求來容許匿名訪問(將下面的示例uuid替換爲步驟2和步驟4中的id值):

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

配置config.anonymous=<your-consumer-id> 參數指示此服務上的key-auth插件容許匿名訪問，並將這種訪問與咱們在上一步中接收到的consumer id關聯起來。在這一步中，您須要提供一個有效且預先存在的consumer id——在配置匿名訪問時，當前不會檢查consumer id的有效性，而且提供一個不存在的consumer id將致使不正確的配置。

六、匿名訪問

經過發出如下請求，確認您的服務如今容許匿名訪問:

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

這是您在步驟3中發出的相同請求，可是此次請求應該成功，由於您在步驟5中啓用了匿名訪問。

響應(即Mockbin接收到的請求)應該包含如下元素:

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

它顯示請求成功，可是是匿名的。

Multiple身份驗證

Kong支持針對給定服務的多個身份驗證插件，容許不一樣的客戶機使用不一樣的身份驗證方法訪問給定的服務或路由。

能夠將身份驗證插件的行爲設置爲邏輯與、邏輯或在評估多個身份驗證憑據時執行。行爲的關鍵是配置config.anonymous屬性。

• config.anonymous not set 

若是未設置此屬性(空)，則身份驗證插件將始終執行身份驗證，若是未驗證，則返回40x響應。這將在調用多個auth插件時產生一個邏輯插件。

• config.anonymous set to a valid consumer id

在這種狀況下，身份驗證插件只會在還沒有驗證的狀況下執行身份驗證。當身份驗證失敗時，它將不返回40x響應，而是將匿名使用者設置爲使用者。當多個身份驗證插件被調用時，這將致使一個邏輯或+「anonymous access」。

注1:必須爲全部auth plugin或所有都不配置anonymous access。若是它們是混合的，則行爲是未定義的。

注2:在使用AND方法時，最後執行的插件將設置傳遞給上游服務的憑證。使用OR方法，最後傳遞上游服務憑證將是將是第一個成功驗證consumer的插件，或者最後一個plugin將是傳遞上游服務憑證，若是其已配置的anonymous consumer.。

注3:當以一種AND的方式同時使用OAuth2插件時，用於請求令牌的OAuth2端點等也須要經過其餘配置的auth插件進行身份驗證。

若是在給定的服務上以某種方式啓用多個身份驗證插件，而且但願禁止匿名訪問，那麼應該在匿名使用者上配置請求終止插件。不這樣作將容許未經受權的請求。