Nguon: Microsoft Learn · .NET 8.0

Xác thực và Phân quyền trong YARP (YARP Authentication and Authorization)

Nguồn: YARP Authentication and Authorization

Giới thiệu

Reverse proxy (proxy ngược) có thể được sử dụng để xác thực (authenticate) và phân quyền (authorize) các yêu cầu trước khi chúng được proxy đến các server đích. Điều này có thể giảm tải cho các server đích, thêm một lớp bảo vệ và đảm bảo các policy nhất quán được triển khai trên các ứng dụng của bạn.

Mặc định

Không có xác thực hay phân quyền nào được thực hiện trên các yêu cầu trừ khi được bật trong cấu hình route hoặc ứng dụng.

Cấu hình

Các policy phân quyền có thể được chỉ định cho từng route thông qua RouteConfig.AuthorizationPolicy và có thể được liên kết từ phần Routes của file cấu hình. Giống như các thuộc tính route khác, điều này có thể được sửa đổi và tải lại mà không cần khởi động lại proxy. Tên policy không phân biệt chữ hoa/thường.

Ví dụ:

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

Các policy phân quyền là một khái niệm của ASP.NET Core mà proxy sử dụng. Proxy cung cấp cấu hình ở trên để chỉ định một policy cho mỗi route và phần còn lại được xử lý bởi các thành phần xác thực và phân quyền ASP.NET Core hiện có.

Các policy phân quyền có thể được cấu hình trong ứng dụng như sau:

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

Trong Program.cs, thêm middleware Authentication (xác thực) và Authorization (phân quyền):

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

app.MapReverseProxy();

Xem tài liệu Authentication để thiết lập loại xác thực mong muốn.

Các giá trị đặc biệt

Ngoài tên policy tùy chỉnh, có hai giá trị đặc biệt có thể được chỉ định trong tham số phân quyền của route: default và anonymous. ASP.NET Core cũng có cài đặt FallbackPolicy áp dụng cho các route không chỉ định policy.

DefaultPolicy

Chỉ định giá trị default trong tham số phân quyền của route có nghĩa là route đó sẽ sử dụng policy được định nghĩa trong AuthorizationOptions.DefaultPolicy. Policy đó được cấu hình sẵn để yêu cầu người dùng đã xác thực.

Anonymous (Ẩn danh)

Chỉ định giá trị anonymous trong tham số phân quyền của route có nghĩa là route đó sẽ không yêu cầu phân quyền bất kể cấu hình nào khác trong ứng dụng như FallbackPolicy.

FallbackPolicy

AuthorizationOptions.FallbackPolicy là policy sẽ được sử dụng cho bất kỳ yêu cầu hoặc route nào không được cấu hình với policy. FallbackPolicy không có giá trị mặc định, bất kỳ yêu cầu nào cũng được phép.

Truyền thông tin xác thực (Flowing Credentials)

Ngay cả sau khi yêu cầu được phân quyền ở proxy, server đích vẫn có thể cần biết người dùng là ai (xác thực) và họ được phép làm gì (phân quyền). Cách bạn truyền thông tin đó sẽ phụ thuộc vào loại xác thực đang được sử dụng.

Các loại xác thực này đã truyền giá trị của chúng trong các header yêu cầu và chúng sẽ được chuyển đến server đích theo mặc định. Server đó vẫn cần xác minh và phân giải các giá trị đó, gây ra một số công việc trùng lặp.

OAuth2, OpenIdConnect, WsFederation

Các giao thức này thường được sử dụng với các identity provider (nhà cung cấp danh tính) từ xa. Quá trình xác thực có thể được cấu hình trong ứng dụng proxy và sẽ dẫn đến một authentication cookie (cookie xác thực). Cookie đó sẽ được chuyển đến server đích như một header yêu cầu bình thường.

Windows, Negotiate, NTLM, Kerberos

Các loại xác thực này thường được liên kết với một kết nối cụ thể. Chúng không được hỗ trợ như phương tiện xác thực người dùng ở server đích phía sau YARP proxy (xem issue #166). Chúng có thể được sử dụng để xác thực yêu cầu đến cho proxy, nhưng thông tin danh tính đó sẽ phải được truyền đến server đích theo một dạng khác. Chúng cũng có thể được sử dụng để xác thực proxy đến các server đích, nhưng chỉ với tư cách là người dùng của chính proxy, việc mạo danh client không được hỗ trợ.

Client Certificates (Chứng chỉ client)

Chứng chỉ client là một tính năng TLS (Transport Layer Security) và được thương lượng như một phần của kết nối. Chứng chỉ có thể được chuyển tiếp đến server đích dưới dạng HTTP header bằng cách sử dụng transform (biến đổi) ClientCert.

Hoán đổi loại xác thực

Các loại xác thực như Windows không truyền tự nhiên đến server đích sẽ cần được chuyển đổi trong proxy sang một dạng thay thế. Ví dụ, một JWT bearer token có thể được tạo với thông tin người dùng và đặt trên yêu cầu proxy.

Các hoán đổi này có thể được thực hiện bằng cách sử dụng custom request transforms (biến đổi yêu cầu tùy chỉnh). Các ví dụ chi tiết có thể được phát triển cho các kịch bản cụ thể nếu có đủ sự quan tâm của cộng đồng.