本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

使用 Application Load Balancer 來驗證使用者身分

您可以設定 Application Load Balancer，以在使用者存取應用程式時安全地驗證使用者身分。這可讓您將驗證使用者的工作卸載到您的負載平衡器，使得您的應用程式可以專注在商業邏輯上。

準備使用 OIDC 合規 IdP

如果您使用 OIDC 合規 IdP 搭配 Application Load Balancer，請執行下列動作：

準備使用 Amazon Cognito

如果您使用與 Amazon Cognito 使用者集區搭配 Application Load Balancer，請執行下列動作：

應用程式用戶端設定中的回呼 URL 必須全都使用小寫字母。

若要讓使用者設定負載平衡器以使用 Amazon Cognito 來驗證使用者身分，您必須授予使用者呼叫 cognito-idp:DescribeUserPoolClient 動作的許可。

準備使用 Amazon CloudFront

如果您在應用 Application Load Balancer 前面使用 CloudFront 散發，請啟用下列設定：

設定使用者身分驗證

您透過為一個或多個接聽程式規則建立驗證動作來設定使用者身分驗證。authenticate-cognito 和 authenticate-oidc 動作類型僅支援使用 HTTPS 接聽程式。如需對應欄位的說明，請參閱 E lastic Load Balancing API 參考版本 2015-12- 01 AuthenticateOidcActionConfig中的AuthenticateCognitoActionConfig和。

負載平衡器會傳送工作階段 Cookie 給用戶端，以維護驗證狀態。此 Cookie 永遠包含 secure 屬性，因為使用者驗證需要 HTTPS 接聽程式。此 Cookie 包含具有 CORS (跨來源資源共享) 請求的 SameSite=None 屬性。

對於支援需要獨立用戶端身分驗證之多個應用程式的負載平衡器，每個具有身分驗證動作的接聽程式規則都應具有唯一的 Cookie 名稱。這可確保用戶端在路由傳送至規則中指定的目標群組之前，一律會使用 IdP 進行驗證。

Application Load Balancer 不支援 URL 編碼的 Cookie 值。

依預設，SessionTimeout 欄位會設為 7 天。如果您需要較短的工作階段，您可以將工作階段逾時設定為最短至 1 秒。如需詳細資訊，請參閱 工作階段逾時。

根據您的應用程式適當地設定 OnUnauthenticatedRequest 欄位。例如：

負載平衡器必須能夠與 IdP 字符端點 (TokenEndpoint) 和 IdP 使用者資訊端點 (UserInfoEndpoint) 通訊。驗證您的負載平衡器的安全群組和您的 VPC 的網路 ACL 允許對這些端點的傳出存取。驗證您的 VPC 具有網際網路存取。如果您有面對內部的負載平衡器，請使用 NAT 閘道來啟用負載平衡器對這些端點的存取。如需詳細資訊，請參閱《Amazon VPC 使用者指南》中的 NAT 閘道基本概念。

使用以下 create-rule 命令來設定使用者驗證。

aws elbv2 create-rule --listener-arn listener-arn --priority 10 \
--conditions Field=path-pattern,Values="/login" --actions file://actions.json

以下是指定 authenticate-oidc 動作和 forward 動作的 actions.json 檔案範例。AuthenticationRequestExtraParams 可讓您在身分驗證期間將額外的參數傳遞至 IdP。請依照身分提供者提供的文件來判斷受支援的欄位

[{
    "Type": "authenticate-oidc",
    "AuthenticateOidcConfig": {
        "Issuer": "https://idp-issuer.com",
        "AuthorizationEndpoint": "https://authorization-endpoint.com",
        "TokenEndpoint": "https://token-endpoint.com",
        "UserInfoEndpoint": "https://user-info-endpoint.com",
        "ClientId": "abcdefghijklmnopqrstuvwxyz123456789",
        "ClientSecret": "123456789012345678901234567890",
        "SessionCookieName": "my-cookie",
        "SessionTimeout": 3600,
        "Scope": "email",
        "AuthenticationRequestExtraParams": {
            "display": "page",
            "prompt": "login"
        },
        "OnUnauthenticatedRequest": "deny"
    },
    "Order": 1
},
{
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id",
    "Order": 2
}]

下列是會指定 authenticate-cognito 動作和 forward 動作的 actions.json 檔案的範例。

[{
    "Type": "authenticate-cognito",
    "AuthenticateCognitoConfig": {
        "UserPoolArn": "arn:aws:cognito-idp:region-code:account-id:userpool/user-pool-id",
        "UserPoolClientId": "abcdefghijklmnopqrstuvwxyz123456789",
        "UserPoolDomain": "userPoolDomain1",
        "SessionCookieName": "my-cookie",
        "SessionTimeout": 3600,
        "Scope": "email",
        "AuthenticationRequestExtraParams": {
            "display": "page",
            "prompt": "login"
        },
        "OnUnauthenticatedRequest": "deny"
    },
    "Order": 1
},
{
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id",
    "Order": 2
}]

如需詳細資訊，請參閱 接聽程式規則。

身分驗證流程

下列網路圖是 Application Load Balancer 如何使用 OIDC 驗證使用者身分的視覺化表示。

下面的帶編號項目著重解釋在前述網路圖中顯示的元素。

每個新的請求都會經歷步驟 1 到 11，而後續的請求則會經歷步驟 9 到 11。也就是說，只要 Cookie 尚未過期，每個後續請求都會從步驟 9 開始。

使用者在 IdP 進行身分驗證之後，系統會將 AWSALBAuthNonce Cookie 新增至請求標頭。這並不會變更 Application Load Balancer 處理來自 IdP 重新導向請求的方式。

如果 IdP 在 ID 字符中提供有效的重新整理字符，負載平衡器會儲存該重新整理字符，並在每次存取字符過期時使用它來重新整理使用者宣告，直到工作階段逾時或 IdP 重新整理失敗。如果使用者登出，重新整理會失敗，並且負載平衡器會將使用者重新導向至 IdP 授權端點。這可讓負載平衡器在使用者登出後捨棄工作階段。如需詳細資訊，請參閱 工作階段逾時。

使用者宣告編碼和簽章驗證

負載平衡器成功驗證使用者之後，它會將從 IdP 收到的使用者宣告傳送到目標。負載平衡器會簽署使用者宣告，讓應用程式可以驗證簽章並驗證宣告是由負載平衡器傳送。

存取權杖和使用者宣告與 ID 權杖不同。存取權杖和使用者宣告僅允許存取伺服器資源，而 ID 權杖會附帶其他資訊來對使用者進行身分驗證。應用程序負載平衡器在對用戶進行身份驗證時創建一個新的訪問令牌，並僅將訪問令牌和聲明傳遞給後端，但是它不會傳遞 ID 令牌信息。

這些字符採用 JWT 格式，但不是 ID 字符。JWT 格式包含使用 base64 URL 編碼的標頭、承載和簽章，而且尾端包含填補字元。Application Load Balancer 會使用 ES256 (使用 P-256 和 SHA256 的 ECDSA) 來產生 JWT 簽章。

JWT 標頭是 JSON 物件，具有下列欄位：

{
   "alg": "algorithm",
   "kid": "12345678-1234-1234-1234-123456789012",
   "signer": "arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id", 
   "iss": "url",
   "client": "client-id",
   "exp": "expiration"
}

JWT 承載為 JSON 物件，其中包含從 IdP 使用者資訊端點收到的使用者宣告。

{
   "sub": "1234567890",
   "name": "name",
   "email": "alias@example.com",
   ...
}

由於負載平衡器不會加密使用者宣告，我們建議您將目標群組設定為使用 HTTPS。如果將您的目標群組設定為使用 HTTP，請務必使用安全群組限制對您的負載平衡器的流量。

為了確保安全性，您必須在根據宣告執行任何授權之前驗證簽章，並驗證 JWT 標頭中的signer欄位是否包含預期的 Application Load Balancer ARN。

若要取得公有金鑰，請從 JWT 標頭取得金鑰 ID，並用其在端點查閱公有金鑰。每個 AWS 區域的端點如下：

https://public-keys.auth.elb.region.amazonaws.com/key-id

對於 AWS GovCloud (US)，端點如下：

https://s3-us-gov-west-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-west-1/key-id
https://s3-us-gov-east-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-east-1/key-id

下列範例顯示如何在 Python 3.x 中取得金鑰 ID、公有金鑰和承載：

import jwt
import requests
import base64
import json

# Step 1: Validate the signer
expected_alb_arn = 'arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id'

encoded_jwt = headers.dict['x-amzn-oidc-data']
jwt_headers = encoded_jwt.split('.')[0]
decoded_jwt_headers = base64.b64decode(jwt_headers)
decoded_jwt_headers = decoded_jwt_headers.decode("utf-8")
decoded_json = json.loads(decoded_jwt_headers)
received_alb_arn = decoded_json['signer']

assert expected_alb_arn == received_alb_arn, "Invalid Signer"

# Step 2: Get the key id from JWT headers (the kid field)
kid = decoded_json['kid']

# Step 3: Get the public key from regional endpoint
url = 'https://public-keys.auth.elb.' + region + '.amazonaws.com/' + kid
req = requests.get(url)
pub_key = req.text

# Step 4: Get the payload
payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])

下列範例顯示如何在 Python 2.7 中取得金鑰 ID、公有金鑰和承載：

import jwt
import requests
import base64
import json

# Step 1: Validate the signer
expected_alb_arn = 'arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id'

encoded_jwt = headers.dict['x-amzn-oidc-data']
jwt_headers = encoded_jwt.split('.')[0]
decoded_jwt_headers = base64.b64decode(jwt_headers)
decoded_json = json.loads(decoded_jwt_headers)
received_alb_arn = decoded_json['signer']

assert expected_alb_arn == received_alb_arn, "Invalid Signer"

# Step 2: Get the key id from JWT headers (the kid field)
kid = decoded_json['kid']

# Step 3: Get the public key from regional endpoint
url = 'https://public-keys.auth.elb.' + region + '.amazonaws.com/' + kid
req = requests.get(url)
pub_key = req.text

# Step 4: Get the payload
payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])

逾時

工作階段逾時

重新整理字符和工作階段逾時的共同運作方式如下所示：

用戶端登入逾時

用戶端必須在 15 分鐘內啟動並完成身分驗證程序。如果用戶端無法在 15 分鐘的限制內完成身分驗證，則會從負載平衡器收到 HTTP 401 錯誤。此逾時限制無法變更或移除。

例如，如果使用者透過 Application Load Balancer 載入登入頁面，則必須在 15 分鐘內完成登入程序。如果使用者在 15 分鐘逾時過期後嘗試登入，負載平衡器會傳回 HTTP 401 錯誤。使用者必須重新整理頁面並嘗試再次登入。

身分驗證登出

當應用程式需要將已驗證的使用者登出時，您應該將驗證工作階段 Cookie 的過期時間設定為 -1，並將用戶端重新導向至 IdP 登出端點 (如果 IdP 有支援)。為了防止使用者重複使用已刪除的 Cookie，建議您將存取字符設定為合理的簡短過期時間。如果用戶端向負載平衡器提供的工作階段 Cookie 具有過期的存取權杖 (具有非 NULL 重新整理權杖)，負載平衡器會聯絡 IdP 以判斷使用者是否仍處於登入狀態。

用戶端登出登陸頁面是未經驗證的頁面。這表示其不能位於需要身分驗證的 Application Load Balancer 規則之後。