Welcome to YARP - 5.身份驗證和授權

y發表於2023-11-09

目錄

Welcome to YARP - 1.認識YARP並搭建反向代理服務

Welcome to YARP - 2.配置功能

Welcome to YARP - 3.負載均衡

Welcome to YARP - 4.限流

Welcome to YARP - 5.身份驗證和授權

Welcome to YARP - 6.壓縮、快取

Welcome to YARP - 7.健康檢查

Welcome to YARP - 8.分散式跟蹤

介紹

說到認證授權,相信還是有很多小夥伴把這兩個東西搞混掉,畢竟兩個單詞也是很相近,AuthenticationAuthorization

  • 身份驗證 (我是誰?)是知道使用者的標識。 例如,Alice 使用她的使用者名稱和密碼登入,伺服器使用該密碼對 Alice 進行身份驗證。

    對於認證的結果會儲存在 HttpContext.User 中。常見的認證方式有:Cookie、JWT、Windows、等等,可參考 ASP.NET Core 身份驗證概述

  • 授權 (我有什麼許可權?)決定是否允許使用者執行操作。 例如,Alice 有權獲取資源,但無權建立資源。

    授權與身份驗證相互獨立。 但是,授權需要一種身份驗證機制。常見的授權策略有:基於角色的 RBAC,基於策略的PBAC等等,可參考 ASP.NET Core 授權簡介

有了上述瞭解,接下來我們看 YARP身份驗證授權

反向代理可用於在將請求代理到目標伺服器之前,對請求進行身份驗證和授權。這可以減少目標伺服器上的負載,增加一層保護,並確保在應用程式中實施一致的策略。 接下來讓我們看下如何開啟認證和授權。

如果有對 .NET 本身的身份驗證授權功能不瞭解的小夥伴,可以先去微軟檔案瞭解一下(身份驗證授權),再回來看可能會容易理解。因為 YARP 就是使用的 .NET 的認證和授權。提供策略,交給其中介軟體處理。

配置

可以透過 RouteConfig.AuthorizationPolicy 為每個路由指定授權策略,並且可以從配置檔案的 Routes 各個部分進行繫結。與其他路由屬性一樣,可以在不重新啟動代理的情況下修改和重新載入此屬性。策略名稱不區分大小寫。

示例:

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

授權策略使用的是 ASP.NET Core 的概念。代理提供上述配置來為每個路由指定一個策略,其餘部分由現有的 ASP.NET Core 身份驗證和授權元件處理。 是不是和上一章的限流是一個套路,都是 .NET 本身的功能,開箱即用。

配置授權策略,如下所示:

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


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

app.MapReverseProxy();

要了解如何設定首選的身份驗證型別,可以參閱身份驗證檔案

特殊值(內建策略):

除了自定義策略名稱之外,還可以在路由的授權引數中指定兩個特殊值: defaultanonymous 。這是兩個內建的策略名稱,用於簡化身份驗證和授權配置。

  • default 對應於使用者已經透過身份驗證的情況。如果使用者已經登入,那麼他們將滿足 default 策略的要求。這通常用於需要使用者已登入的資源或操作。 在路由的授權引數中指定值 default 意味著路由將使用 AuthorizationOptions.DefaultPolicy 中定義的策略。該策略已預先配置為要求經過身份驗證的使用者。

示例用法:

app.MapGet("/default", () =>
{
    return "hello";
}).RequireAuthorization();// 將具有指定名稱的授權策略新增到終結點。空 代表使用 default 策略

上述的RequireAuthorization() 方法沒給引數 預設就是用了 default 策略,已登入的使用者才能透過驗證。 而且還可以指定多個策略。他接收的是一個 params string[] policyNames 引數,你還可以新增其他策略。

YARP 中用法:

"Routes": {
      "DefaultAuthRoute": {
        "ClusterId": "cluster1",
        // 此路由使用內建的預設授權策略,該策略要求經過身份驗證的使用者
        "AuthorizationPolicy": "Default",
        "Match": {
          "Path": "/default"
        }
      }
}
  • anonymous 對應於未經身份驗證的使用者,即匿名使用者。如果使用者沒有登入,他們將滿足 anonymous 策略的要求。這通常用於允許未經身份驗證的使用者訪問資源或操作。 在路由的 authorization 引數中指定值 anonymous 意味著無論應用程式中的任何其他配置(如 FallbackPolicy)如何,路由都不需要授權。

示例用法:

app.MapGet("/public", () =>
{
	return "hello";
}).AllowAnonymous();

YARP 中用法:

"Routes": {
      "AnonymousRoute": {
        "ClusterId": "cluster1",
        // 此路由使用內建的預設授權策略,該策略要求經過身份驗證的使用者
        "AuthorizationPolicy": "Anonymous",
        "Match": {
          "Path": "/open/{*any}"
        }
      }
}

FallbackPolicy 回退策略

AuthorizationOptions.FallbackPolicy 用於處理未指定任何特定策略的路由。這是一個全域性預設策略,如果路由沒有指定特定策略,就會使用這個策略。通常情況下,FallbackPolicy 會採用預設策略,要求使用者已透過身份驗證。

示例用法:

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = new AuthorizationPolicyBuilder()
        .RequireAuthenticatedUser() // 預設情況下,要求使用者已透過身份驗證. 可以提成你需要的驗證
        .Build();
});

YARP 中用法:

"Routes": {
      "Other": {
        // 由於以下路由未定義授權策略,因此使用回退策略
        "ClusterId": "cluster1",
        "Match": {
          "Path": "{**catchall}"
        }
      }
}

Flowing Credentials 流動憑證

即使在代理中授權了請求後,目標伺服器可能仍需要知道使用者是誰(身份驗證)以及允許他們執行的操作(授權)。如何傳遞該資訊將取決於所使用的身份驗證型別。

這些身份驗證型別已經在請求頭中傳遞了它們的值,預設情況下這些值將流到目標伺服器。該伺服器仍然需要驗證和解釋這些值,這可能會造成一些雙重工作(代理也校驗,目標服務也校驗)

Windows, Negotiate, NTLM, Kerbereos

這些身份驗證型別通常繫結到特定連線。不支援將它們作為在 YARP 代理後面的目標伺服器中對使用者進行身份驗證的方法(參見 #166。它們可用於對代理的傳入請求進行身份驗證,但該身份資訊必須以另一種形式傳達給目標伺服器。它們還可用於向目標伺服器驗證代理,但只能作為代理自己的使用者,不支援模擬客戶端( YARP 無法代表客戶端進行目標伺服器的身份驗證)

Client Certificates 客戶端證書

客戶端證書是一項 TLS 功能,作為連線的一部分進行協商。有關其他資訊,請參閱這些檔案。可以使用 ClientCert 轉換將證書作為 HTTP 標頭轉發到目標伺服器。

替換身份驗證型別

Windows 這樣不自然流到目標伺服器的身份驗證型別需要在代理中轉換為其他形式。例如,可以使用使用者資訊建立 JWT 承載令牌,並在代理請求上進行設定。

可以使用自定義請求轉換來執行這些交換(看起來又要加一章 請求轉換 的篇章了 )。如果你有足夠的興趣,可以針對特定場景開發詳細示例,反饋給 YARP 讓他們瞭解您希望如何轉換和流動身份資訊的。

總結

本章我們介紹了 YARP 的認證和授權功能,概念比較多,此功能還是主要依賴於.NET 本身的認證和授權。如果有不了的可以先從微軟檔案學起,看起來相對會簡單一些。本章建議結合示例程式碼一起看理解起來會比較方便,示例程式碼已上傳GitHub
本章示例完整配置如下:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "ReverseProxy": {
    "Routes": {
      "DefaultAuthRoute": {
        "ClusterId": "cluster1",
        // 此路由使用內建的預設授權策略,該策略要求經過身份驗證的使用者
        "AuthorizationPolicy": "Default",
        "Match": {
          "Path": "/default"
        }
      },
      "ClaimsAuthRoute": {
        "ClusterId": "cluster1",
        // 自定義策略
        "AuthorizationPolicy": "myPolicy",
        "Match": {
          "Path": "/custom/{*any}"
        }
      },
      "AnonymousRoute": {
        "ClusterId": "cluster1",
        // 此路由使用內建的預設授權策略,該策略要求經過身份驗證的使用者
        "AuthorizationPolicy": "Anonymous",
        "Match": {
          "Path": "/open/{*any}"
        }
      },
      "Other": {
        // 由於以下路由未定義授權策略,因此使用回退策略
        // 程式中 設定為null,因此不需要身份驗證或宣告。
        "ClusterId": "cluster1",
        "Match": {
          "Path": "{**catchall}"
        }
      }
    },
    "Clusters": {
      "cluster1": {
        "Destinations": {
          "cluster1/destination1": {
            "Address": "https://www.baidu.com/"
          }
        }
      }
    }
  }
}

下篇文章我們繼續 壓縮快取 或者再補一篇 請求和響應轉換

相關文章