共用方式為

YARP 驗證和授權

介紹

反向代理可用來驗證和授權請求，再將請求代理到目的伺服器。 這可減少目的地伺服器上的負載、新增一層保護，並確保在您的應用程式中實作一致的原則。

違約

除非在路由或應用程式組態中啟用，否則不會對要求執行驗證或授權。

配置

授權原則可以透過 RouteConfig.AuthorizationPolicy 指定每個路由，而且可以從組態檔的 Routes 區段系結。 如同其他路由屬性，這可以修改和重載，而不需重新啟動 Proxy。 原則名稱不區分大小寫。

例：

{
  "ReverseProxy": {
    "Routes": {
      "route1" : {
        "ClusterId": "cluster1",
        "AuthorizationPolicy": "customPolicy",
        "Match": {
          "Hosts": [ "localhost" ]
        }
      }
    },
    "Clusters": {
      "cluster1": {
        "Destinations": {
          "cluster1/destination1": {
            "Address": "https://localhost:10001/"
          }
        }
      }
    }
  }
}

授權原則 是 Proxy 所使用的 ASP.NET 核心概念。 Proxy 會提供上述組態來指定每個路由的原則，其餘則由現有的 ASP.NET 核心驗證和授權元件處理。

您可以在應用程式設定授權原則，如下所示：

services.AddAuthorization(options =>
{
    options.AddPolicy("customPolicy", policy =>
        policy.RequireAuthenticatedUser());
});

在 Program.cs新增授權和驗證中間件。

app.UseAuthentication();
app.UseAuthorization();

app.MapReverseProxy();

請參閱 驗證 檔，以設定您慣用的驗證類型。

特殊值：

除了自訂原則名稱之外，還有兩個特殊值可以在路由的授權參數中指定：default 和 anonymous。 ASP.NET Core 也有適用於未指定原則之路由的 FallbackPolicy 設定。

預設政策

在路由的授權參數中指定值 default，表示路由將使用在 authorizationOptions.DefaultPolicy 中定義的原則。 該原則已預先設定為需要已驗證的使用者。

匿名

在路由的授權參數中指定值 anonymous 表示路由不需要授權，而不論應用程式中的任何其他組態，例如 FallbackPolicy。

後援策略

AuthorizationOptions.FallbackPolicy 是用於未設定原則之任何要求或路由的原則。 FallbackPolicy 預設沒有值，將會允許任何要求。

流動認證

即使在 Proxy 中授權要求之後，目的地伺服器可能仍然需要知道使用者是誰（驗證），以及他們允許執行的動作（授權）。 您流向該資訊的方式將取決於所使用的驗證類型。

這些驗證類型已在要求標頭中傳遞其值，而且這些類型預設會流向目的地伺服器。 該伺服器仍然需要驗證和解譯這些值，導致某些雙重工作。

OAuth2、OpenIdConnect、WsFederation

這些通訊協定通常與遠端識別提供者搭配使用。 您可以在 Proxy 應用程式設定驗證程式，並會導致驗證 cookie。 該 cookie 會以一般要求標頭的形式流向目的地伺服器。

Windows、Negotiate、NTLM、Kerberos

這些驗證類型通常會系結至特定連線。 不支援這些作為在 YARP 代理後方目的地伺服器上驗證使用者的方式（請參閱 #166）。 它們可用來向 Proxy 驗證傳入要求，但該身分識別信息必須以另一種形式與目的地伺服器通訊。 它們也可以用來將 Proxy 驗證到目的地伺服器，但僅能以 Proxy 本身的身份進行，不支援模擬用戶端。

客戶端憑證

客戶端憑證是 TLS 的一項功能，並作為連線協商的一部分。 如需詳細資訊，請參閱 這些文件。 您可以使用 ClientCert 轉換，將憑證轉送至目的地伺服器做為 HTTP 標頭。

交換驗證類型

必須將無法自然傳遞至目的伺服器的 Windows 驗證類型在代理伺服器中轉換為替代形式。 例如，可以使用使用者資訊建立 JWT 持有人令牌，並在 Proxy 要求上設定。

您可以使用 自訂要求轉換來執行這些交換。 如果有足夠的社群興趣，則可以針對特定案例開發詳細的範例。 我們需要更多社群意見反應，以瞭解如何轉換和流動身分識別資訊。

  • Last updated on