微服務Kong（九）——認證參考

　　客戶端訪問上游API服務，一般由Kong的認證插件及其配置參數來控制。

 

通用認證

　　通常狀況下，上游API服務都須要客戶端有身份認證，且不容許錯誤的認證或無認證的請求經過。認證插件能夠實現這一需求。這些插件的通用方案/流程以下：

　　　　一、向一個API或全局添加AUTH插件（此插件不做用於consumers）；

　　　　二、常見一個consumer對象；

　　　　三、爲consumer提供指定的驗證插件方案的身份驗證憑據；

　　　　四、如今，只要有請求進入Kong，都將檢查其提供的身份驗證憑據（取決於auth類型），若是該請求沒法被驗證或者驗證失敗，則請求會被鎖定，不執行向上有服務轉發的操做。

　　可是，上述的通常流程並非老是有效的。譬如，當使用了外部驗證方案（好比LDAP）時，KONG就不會（不須要）對consumer進行身份驗證。

 

Consumers

　　最簡單的理解和配置consumer的方式是，將其於用戶進行一一映射，即一個consumer表明一個用戶（或應用）。可是對於KONG而言，這些都無所謂。consumer的核心原則是你能夠爲其添加插件，從而自定義他的請求行爲。因此，或許你會有一個手機APP應用，併爲他的每一個版本都定義一個consumer，又或者你又一個應用或幾個應用，併爲這些應用定義統一個consumer，這些都無所謂。這是一個模糊的概念，他叫作consumer，而不是user！萬萬要區分開來，且不可混淆。

 

匿名訪問

　　在Kong 0.10.x版本以前，你能夠將指定的API配置爲僅容許通過身份驗證的訪問（經過插件來實現）或只容許匿名訪問。也就是說，一個指定的API，不容許對於某些consumer實行身份驗證，而對於另外的consumer實行匿名訪問。

　　在0.10.x版本之後，這些限制取消了--同一個API能夠同時實現驗證和匿名兩種訪問方式。你可使用他的這種特性，爲一個API提供兩種服務方式：以較低的速率提供匿名訪問權限，以較高的速率實現驗證訪問權限。爲指定API提供一個用戶試用體驗。

　　要配置這樣的API，您首先應用所選的認證插件，而後建立一個新的consumer來表示匿名用戶，而後配置你的身份驗證插件以容許匿名訪問。這裏有一個示例，它假設您已經配置了一個名爲example-api的API：

　　一、建立example-api：

$ curl -i -X POST \
  --url http://localhost:8001/apis/ \
  --data 'name=example-api' \
  --data 'uris=/auth-sample' \
  --data 'upstream_url=http://mockbin.org/request' 

　　　　此時，不管什麼樣的請求，http://localhost:8000/auth-sample 都會有輸出信息。

　　二、配置 key-auth 插件：

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

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

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

　　　　此時，因爲你並未在請求參數或請求頭裏使用apikey，因此這個請求會報403錯誤：

HTTP/1.1 403 Forbidden
...

{
  "message": "No API key found in headers or querystring"
}

　　四、建立一個匿名consumer：

　　　　每一次的KONG的代理請求，都會有一個對應的consumer對象。這裏建立一個anonymous_consumer來測試API的匿名請求：

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

　　　　你會獲得如下的返回信息：

HTTP/1.1 201 Created
Content-Type: application/json
Connection: keep-alive

{
  "username": "anonymous_users",
  "created_at": 1428555626000,
  "id": "bbdf1c48-19dc-4ab7-cae0-ff4f59d87dc9"
}

　　五、開啓API的匿名請求：

　　　　您如今將從新配置密鑰驗證插件，以容許匿名訪問:

$ curl -i -X PATCH \
  --url http://localhost:8001/apis/example-api/plugins/4a223b63-c44a-40e5-9102-b23335f594ca \
  --data "config.anonymous=bbdf1c48-19dc-4ab7-cae0-ff4f59d87dc9"

　　　　這裏的兩個uuid，分別是第2步和第4步中產生的uuid。具體請參考兩步操做中返回參數id。

　　　　config.anonymous = <consumer uuid>參數表示該API上的密鑰驗證插件容許匿名訪問，並將此訪問與上一步中收到的consumer的ID相關聯。在此步驟中，您須要提供有效的consumerID - 當進行匿名配置時，不會對consumer的id進行檢驗，若是配置了一個不存在的或錯誤的consumerid，則會致使插件不能正常運行。

　　六、驗證匿名訪問：

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

　　　　這個訪問請求和第三步中的同樣，然而，此時的訪問是經過的，只由於你在第五步中配置了匿名訪問。返回內容大體是：

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

　　　　這顯示，請求經過了，而且是以匿名的方式。

 

多重驗證

　　Kong 0.10.x擴展了爲給定API應用多個驗證插件的能力，並容許不一樣的客戶端使用不一樣的身份驗證方法來訪問給定的API服務。在評估多個身份驗證憑據時，能夠將驗證插件的行爲設置爲邏輯AND或邏輯OR。該行爲的關鍵是配置config.anonymous屬性。

　　· config.anonymous 默認爲未設置。若是此屬性未設置（空），則auth插件將始終執行身份驗證，並返回40x響應（若是未驗證）。當調用多個驗證插件時，會致使邏輯AND。

　　· config.anonymous 設置爲有效的consumer ID。在這種狀況下，auth插件只有在還沒有認證的狀況下才會執行身份驗證。當身份驗證失敗時，它不會返回40x響應，而是將匿名consumer設置爲consumer。當調用多個驗證插件時，會使用OR+匿名。

 

備註1：全部的或任何一個驗證插件均可配置爲可以使匿名訪問的。可是，若是要混合使用驗證插件，則對於匿名訪問的配置就須要進行甄選，不然會出現混亂。

備註2：若是使用AND邏輯，則最後一個執行的驗證插件將是把驗證信息傳遞給上游服務的那個。當使用OR邏輯時，傳遞給上游服務驗證信息的那個插件，將會是第一個成功驗證consumer的那個插件，或者是最後一個配置了匿名訪問權限的那個插件。

ps：若是對API使用多個驗證插件，且插件間的邏輯配置爲OR的話，最好不要爲每一個插件開啓匿名訪問，這樣才能保證最終能成功請求的consumer是預期的那個。不然會有不可預期的結果出現。