Kiểm soát truy cập dựa trên vai trò (RBAC) so với kiểm soát truy cập dựa trên yêu cầu (CBAC) trong ASP.NET MVC

Những lợi ích chính của việc sử dụng CBAC so với RBAC là gì? Khi nào thì tốt hơn khi sử dụng CBAC và khi nào thì sử dụng RBAC tốt hơn?

Tôi đang cố gắng hiểu các khái niệm chung về mô hình CBAC nhưng ý tưởng chung vẫn chưa rõ ràng đối với tôi.

Tôi sẽ cố gắng chỉ ra làm thế nào bạn có thể hưởng lợi từ Yêu cầu kiểm soát truy cập dựa trên yêu cầu trong bối cảnh ASP.NET MVC.

Khi bạn đang sử dụng xác thực dựa trên Vai trò, nếu bạn có hành động tạo khách hàng và bạn muốn rằng những người trong vai trò 'Bán hàng' có thể làm điều đó, thì bạn hãy viết mã như thế này:

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

Sau đó, bạn nhận ra rằng, đôi khi, những người từ vai trò 'Tiếp thị' có thể tạo ra Khách hàng. Sau đó, bạn cập nhật phương thức Hành động của mình như thế

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

Bây giờ, bạn nhận ra rằng, một số người tiếp thị không thể tạo Khách hàng, nhưng không thể chỉ định một vai trò khác cho những người đang làm Marketing. Vì vậy, bạn buộc phải cho phép tất cả những người tiếp thị tạo ra Khách hàng.

bạn phát hiện ra một vấn đề khác, bất cứ khi nào bạn quyết định rằng những người tiếp thị nên được phép tạo khách hàng, bạn phải cập nhật tất cả các phương thức Hành động MVC của bạn Ủy quyền thuộc tính, biên dịch ứng dụng của bạn, kiểm tra và triển khai. Vài ngày sau, bạn quyết định, không tiếp thị nhưng một số vai trò khác sẽ được phép thực hiện nhiệm vụ, vì vậy bạn tìm kiếm trong cơ sở mã của mình và xóa tất cả 'Tiếp thị' khỏi thuộc tính Authorize và thêm tên vai trò mới của bạn trong thuộc tính Authorize ... Không phải là giải pháp lành mạnh. Tại thời điểm đó, bạn sẽ nhận ra nhu cầu Kiểm soát truy cập dựa trên quyền.

Quyền kiểm soát truy cập dựa trên quyền là cách gán các quyền khác nhau cho nhiều người dùng khác nhau và kiểm tra xem người dùng có quyền thực thi một hành động từ mã trong thời gian chạy hay không. Sau khi bạn gán nhiều quyền cho nhiều người dùng khác nhau, bạn nhận ra rằng bạn cần cho phép một số người dùng thực thi một số mã nếu người dùng có một số thuộc tính như "Người dùng Facebook", "Người dùng lâu năm", v.v. Hãy để tôi đưa ra một ví dụ. Giả sử bạn muốn cho phép truy cập vào một trang cụ thể nếu người dùng đăng nhập bằng Facebook. Bây giờ, bạn có tạo quyền 'Facebook' cho người dùng đó không? Không, 'Facebook' không giống như một sự cho phép. Phải không ? Thay vào đó có vẻ như một yêu cầu. Đồng thời, Quyền cũng có thể giống như Yêu cầu bồi thường !! Vì vậy, tốt hơn là kiểm tra khiếu nại và cho phép truy cập.

Bây giờ, hãy quay lại ví dụ cụ thể về kiểm soát truy cập dựa trên yêu cầu.

Bạn có thể xác định một số nhóm yêu cầu như thế này:

"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer" .. vv ..

Bây giờ, bạn có thể trang trí Phương thức hành động của mình như thế này:

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(xin lưu ý, [ClaimAuthorize (Permission = "CanCreateCustomer")] có thể không được tích hợp vào thư viện lớp MVC.

Bây giờ, bạn có thể thấy rằng, phương thức hành động của CreatCustomer sẽ luôn cần sự cho phép 'CanCreateCustomer' và nó sẽ không bao giờ thay đổi hoặc hầu như không thay đổi. Vì vậy, trong cơ sở dữ liệu của bạn, bạn tạo một bảng quyền (khiếu nại) và quan hệ cấp phép người dùng. Từ bảng quản trị của bạn, bạn có thể đặt quyền (yêu cầu) cho mỗi người dùng có thể làm gì. Bạn có thể chỉ định quyền (yêu cầu) của CanCreateCustomer cho bất kỳ ai bạn thích và chỉ người dùng được phép mới có thể tạo khách hàng và người dùng được phép sẽ chỉ có thể tạo khách hàng và không có gì khác (trừ khi bạn chỉ định các quyền khác cho cùng một người dùng).

Mô hình bảo mật này cung cấp cho bạn thực hành mã sạch. Ngoài ra, khi bạn viết Phương thức hành động, bạn không phải suy nghĩ về việc ai có thể sử dụng phương pháp này, thay vào đó bạn luôn có thể yên tâm rằng bất kỳ ai đang sử dụng phương pháp này sẽ có quyền (yêu cầu) phù hợp do Quản trị viên cung cấp. Sau đó, Admin có thể quyết định ai sẽ có thể làm gì. Không phải bạn là một nhà phát triển. Đó là cách logic kinh doanh của bạn được tách ra khỏi logic bảo mật.

Bất cứ khi nào ai đó đăng nhập, ứng dụng của bạn sẽ kiểm tra bất kỳ quyền nào có sẵn cho người dùng đó và bộ quyền (yêu cầu) đó sẽ có sẵn dưới dạng các thuộc tính bổ sung của người dùng hiện đang đăng nhập (thường là bộ yêu cầu được lưu dưới dạng cookie cho người dùng đã đăng nhập), vì vậy bạn không phải kiểm tra quyền đặt toàn bộ thời gian từ cơ sở dữ liệu. Điểm mấu chốt là, bạn có thêm quyền kiểm soát logic bảo mật trong ứng dụng của mình nếu bạn áp dụng quyền truy cập dựa trên yêu cầu thay vì truy cập dựa trên vai trò. Trên thực tế, Vai trò cũng có thể được coi là Khiếu nại.

Nếu ứng dụng của bạn là một ứng dụng rất nhỏ, trong đó sẽ chỉ có 2 vai trò: Khách hàng và Quản trị viên và không có khả năng Khách hàng có thể làm bất cứ điều gì khác ngoài những gì họ dự định làm trong ứng dụng của bạn, có lẽ, dựa trên Vai trò kiểm soát truy cập sẽ phục vụ mục đích, nhưng khi ứng dụng của bạn phát triển, bạn sẽ bắt đầu cảm thấy sự cần thiết của kiểm soát truy cập dựa trên yêu cầu tại một số điểm.

Tôi đã thực hiện các mô hình bảo mật nhiều lần và cũng phải quấn đầu xung quanh các khái niệm này. Đã làm điều đó nhiều lần, đây là sự hiểu biết của tôi về các khái niệm này.

Vai trò là gì

Vai trò = Sự kết hợp của Người dùng và Quyền.

Một mặt, Vai trò là tập hợp các Quyền. Tôi thích gọi nó là Hồ sơ cấp phép. Khi xác định Vai trò, về cơ bản, bạn sẽ thêm một loạt Quyền vào Vai trò đó để theo nghĩa đó, Vai trò là Hồ sơ Quyền.

Mặt khác, Vai trò cũng là một tập hợp Người dùng. Nếu tôi thêm Bob và Alice vào Vai trò "Người quản lý" thì "Người quản lý" hiện chứa một bộ sưu tập gồm hai Người dùng giống như một Nhóm.

Sự thật là Vai trò là MỘT bộ sưu tập Người dùng và bộ sưu tập Quyền được đặt cùng nhau. Trực quan điều này có thể được xem như một sơ đồ Venn.

Nhóm là gì

Nhóm = Bộ sưu tập của người dùng

"Nhóm" hoàn toàn là một bộ sưu tập Người dùng. Sự khác biệt giữa Nhóm và Vai trò là Vai trò cũng có bộ sưu tập Quyền nhưng Nhóm chỉ có bộ sưu tập Người dùng.

Giấy phép là gì

Quyền = Những gì một chủ đề có thể làm

Tập quyền là gì

Bộ quyền = Bộ sưu tập quyền

Trong một hệ thống RBAC mạnh mẽ, Quyền cũng có thể được nhóm lại như Người dùng. Trong khi các Nhóm chỉ là một bộ sưu tập của Người dùng, Bộ quyền chỉ là một tập hợp các Quyền. Điều này cho phép quản trị viên thêm toàn bộ bộ sưu tập Quyền vào Vai trò cùng một lúc.

Cách người dùng, nhóm, vai trò và quyền kết hợp với nhau

Trong hệ thống RBAC mạnh mẽ, Người dùng có thể được thêm vào Vai trò riêng lẻ để tạo bộ sưu tập Người dùng trong Vai trò hoặc Nhóm có thể được thêm vào Vai trò để thêm bộ sưu tập Người dùng vào Vai trò cùng một lúc. Dù bằng cách nào, Vai trò có được bộ sưu tập Người dùng từ việc thêm riêng lẻ hoặc bằng cách thêm Nhóm vào Vai trò hoặc bằng cách thêm kết hợp Người dùng và Nhóm vào Vai trò. Quyền có thể được nghĩ theo cùng một cách.

Quyền có thể được thêm vào Vai trò riêng lẻ để tạo bộ sưu tập Quyền bên trong Bộ vai trò hoặc quyền có thể được thêm vào Vai trò. Cuối cùng, một hỗn hợp các Quyền và Bộ quyền có thể được thêm vào Vai trò. Dù bằng cách nào, Vai trò có được bộ sưu tập Quyền của mình khi được thêm riêng lẻ hoặc bằng cách thêm Bộ quyền vào Vai trò.

Toàn bộ mục đích của Vai trò là kết hôn với Người dùng với Quyền. Do đó, Vai trò là ĐOÀN KẾT Người dùng và Quyền.

Khiếu nại là gì

Yêu cầu = Chủ đề "là gì"

Khiếu nại KHÔNG phải là Quyền. Như đã chỉ ra trong các câu trả lời trước, Yêu cầu bồi thường là điều mà một chủ đề "không phải là" chủ đề "có thể làm".

Khiếu nại không thay thế Vai trò hoặc Quyền, chúng là những phần thông tin bổ sung mà người ta có thể sử dụng để đưa ra quyết định Ủy quyền.

Khi nào nên sử dụng Yêu cầu bồi thường

Tôi đã thấy Khiếu nại là hữu ích khi cần đưa ra quyết định Ủy quyền khi Người dùng không thể được thêm vào Vai trò hoặc quyết định không dựa trên sự liên kết của Người dùng với Quyền. Ví dụ về một Người dùng Facebook gây ra điều này. Người dùng Facebook có thể không phải là người được thêm vào "Vai trò" ... họ chỉ là một số Khách truy cập được xác thực qua Facebook. Mặc dù nó không phù hợp với RBAC nhưng đây là một thông tin để đưa ra quyết định ủy quyền.

@CodingSoft đã sử dụng phép ẩn dụ câu lạc bộ đêm trong câu trả lời trước đó, mà tôi muốn mở rộng. Trong câu trả lời đó, Giấy phép Lái ​​xe đã được sử dụng làm ví dụ bao gồm một bộ Khiếu nại trong đó Ngày sinh đại diện cho một trong các Khiếu nại và giá trị của Khiếu nại DateOfBirth được sử dụng để kiểm tra quy tắc ủy quyền. Chính phủ cấp Giấy phép lái xe là cơ quan cung cấp tính xác thực cho Yêu cầu bồi thường. Do đó, trong một kịch bản câu lạc bộ đêm, người bouncer ở cửa nhìn vào Giấy phép lái xe của người đó, đảm bảo rằng nó được cấp bởi một cơ quan đáng tin cậy bằng cách kiểm tra xem đó có phải là ID giả hay không (nghĩa là phải có ID do chính phủ cấp hợp lệ), sau đó xem Ngày sinh (một trong nhiều khiếu nại về Bằng lái xe), sau đó sử dụng giá trị đó để xác định xem người đó có đủ tuổi để vào câu lạc bộ hay không. Nếu vậy,

Bây giờ, với cơ sở đó trong tâm trí tôi muốn mở rộng hơn nữa. Giả sử rằng tòa nhà nơi câu lạc bộ đêm chứa văn phòng, phòng, nhà bếp, các tầng khác, thang máy, tầng hầm, vv nơi chỉ có nhân viên của câu lạc bộ có thể vào. Hơn nữa, một số nhân viên có thể có quyền truy cập vào một số nơi nhất định mà nhân viên khác không thể. Ví dụ: Người quản lý có thể có quyền truy cập vào một tầng văn phòng phía trên mà các nhân viên khác không thể truy cập. Trong trường hợp này có hai Vai trò. Quản lý và nhân viên.

Mặc dù quyền truy cập của khách truy cập vào khu vực câu lạc bộ đêm công cộng được cho phép bởi một yêu cầu duy nhất như được giải thích ở trên, nhân viên cần có quyền truy cập theo Vai trò đối với các phòng hạn chế ngoài công cộng khác. Đối với họ, bằng lái xe là không đủ. Thứ họ cần là Huy hiệu nhân viên mà họ quét để vào cửa. Ở đâu đó có một hệ thống RBAC cấp huy hiệu trong quyền truy cập Vai trò người quản lý lên tầng trên cùng và huy hiệu trong Quyền truy cập vai trò của nhân viên vào các phòng khác.

Nếu vì bất kỳ lý do gì, một số phòng nhất định cần được thêm / xóa bởi Vai trò, điều này có thể được thực hiện bằng RBAC, nhưng nó không phù hợp với Yêu cầu bồi thường.

Quyền trong phần mềm

Mã hóa vai trò vào ứng dụng là một ý tưởng tồi. Điều này cứng mã mục đích của Vai trò vào ứng dụng. Những gì ứng dụng nên có chỉ là Quyền hoạt động như Feature Feature. Trong đó Cấu hình cờ có thể truy cập được bằng cấu hình, Quyền được truy cập bởi Bối cảnh bảo mật người dùng có nguồn gốc từ bộ quyền DISTINCT được thu thập từ tất cả các vai trò mà người dùng đã đặt. Đây là cái mà tôi gọi là "Quyền hiệu quả". Ứng dụng chỉ nên trình bày một menuQuyền có thể đối với các tính năng / hành động. Hệ thống RBAC sẽ thực hiện công việc kết hôn những Quyền đó với Người dùng thông qua Vai trò. Theo cách này, không có mã hóa cứng của các Vai trò và lần duy nhất Quyền thay đổi là khi nó bị xóa hoặc một mã mới được thêm vào. Khi Quyền được thêm vào phần mềm, nó sẽ không bao giờ bị thay đổi. Nó chỉ nên được gỡ bỏ khi cần thiết (tức là khi một tính năng bị ngừng trong một phiên bản mới) và chỉ những tính năng mới có thể được thêm vào.

Một lưu ý cuối cùng.

Cấp vs từ chối

Một hệ thống RBAC mạnh mẽ và thậm chí là một hệ thống CBAC cần phân biệt giữa Tài trợ và Từ chối.

Thêm một quyền cho một vai trò sẽ đi kèm với một GRANT hoặc DENY. Khi Quyền được chọn, tất cả Quyền được cấp phải được thêm vào danh sách Quyền của người dùng. Sau đó, sau khi hoàn thành, một danh sách Quyền DENIED sẽ khiến hệ thống xóa các Quyền đó khỏi danh sách Quyền có hiệu lực.

Điều này cho phép quản trị viên "điều chỉnh" Quyền cuối cùng của một chủ đề. Tốt nhất là Quyền cũng có thể được thêm trực tiếp vào Người dùng. Bằng cách này, bạn có thể thêm Người dùng vào Vai trò người quản lý và họ có quyền truy cập vào mọi thứ, nhưng có lẽ bạn muốn TÌM quyền truy cập vào Phòng vệ sinh của Lady vì Người dùng là nam. Vì vậy, bạn thêm Người dùng nam vào Vai trò người quản lý và thêm Quyền cho đối tượng Người dùng bằng DENY để nó chỉ lấy đi quyền truy cập phòng của Lady.

Trên thực tế, đây sẽ là một ứng cử viên tốt cho Yêu cầu bồi thường. Nếu Người dùng có Yêu cầu "giới tính = nam", thì trong Vai trò người quản lý sẽ có quyền truy cập vào tất cả các phòng nhưng phòng vệ sinh của Lady cũng yêu cầu Yêu cầu giới tính = nữ và nhà vệ sinh nam yêu cầu Yêu cầu giới tính = nam. Theo cách này, người ta sẽ không phải định cấu hình quyền DENY cho Người dùng nam vì việc thực thi Yêu cầu bồi thường đối với mọi người với một quy tắc ủy quyền duy nhất. Tuy nhiên, nó có thể được thực hiện một trong hai cách.

Vấn đề là với DENIAL of Rights, nó làm cho việc quản lý các Vai trò trở nên dễ dàng hơn vì các ngoại lệ có thể được thực hiện.

Dưới đây là một sơ đồ tôi đã thực hiện cách đây rất lâu cho thấy mô hình RBAC. Tôi không có đồ họa cho Khiếu nại nhưng bạn có thể tưởng tượng chúng chỉ là thuộc tính gắn liền với Người dùng mọi lúc mọi nơi. Ngoài ra, sơ đồ không hiển thị Nhóm (tôi cần cập nhật tại một số điểm).

Tôi hi vọng cái này giúp được.

Đây là sơ đồ của RBAC được mô tả ở trên

Cập nhật vào ngày 7 tháng 4 năm 2019 Dựa trên phản hồi từ @Brent (cảm ơn) ... đã xóa các tham chiếu không cần thiết cho các câu trả lời trước đó và giải thích cơ sở ban đầu của phép ẩn dụ "câu lạc bộ đêm" do @CodingSoft cung cấp để làm cho câu trả lời này dễ hiểu mà không cần phải có để đọc các câu trả lời khác.

Tôi không hoàn toàn đồng ý với câu trả lời của Emran

[Authorize(Roles="Sale")]

Là ngây thơ

Câu hỏi là làm thế nào

  [Authorize(Roles="CustomerCreator")]

la khac nhau tư

 [ClaimAuthorize(Permission="CanCreateCustomer")]

Nếu cả hai đều tốt như nhau, tại sao chúng ta cần yêu cầu bồi thường?

Tôi nghĩ bởi vì

Khái niệm xác nhận là chung chung hơn so với Vai trò

Trong bối cảnh của ví dụ trên, chúng ta có thể nói "CustomerCreator" là một yêu cầu của loại "vai trò" được cung cấp bởi "Asp.NETroleProvider"

Ví dụ bổ sung của yêu cầu bồi thường.

1. "AAA" là khiếu nại thuộc loại "MYExamSite.Score" được cung cấp bởi "MYExamSite.com"

2. "Vàng" là khiếu nại thuộc loại "MYGYM.Membershiptype" được cung cấp bởi "MYGYMApp"

Câu trả lời được chấp nhận xuất hiện để định vị Vai trò là một đối tượng cùn và Tuyên bố là một công cụ linh hoạt, nhưng mặt khác làm cho chúng có vẻ gần giống nhau. Thật không may, định vị này không đồng ý với khái niệm khiếu nại và về cơ bản có thể phản ánh một sự hiểu lầm nhỏ về mục đích của chúng.

Vai trò tồn tại và có ý nghĩa chỉ trong một phạm vi ngầm. Nói chung đó là một phạm vi ứng dụng hoặc tổ chức (ví dụ Vai trò = Quản trị viên). Mặt khác, yêu cầu bồi thường có thể được 'tạo ra' bởi bất kỳ ai. Ví dụ: xác thực Google có thể tạo khiếu nại bao gồm "email" của người dùng, do đó đính kèm email đó vào danh tính. Google đưa ra yêu cầu, ứng dụng chọn có hiểu và chấp nhận yêu cầu đó hay không. Bản thân ứng dụng sau đó có thể đính kèm một yêu cầu gọi là "xác thực" (giống như ASP.NET MVC Core Identity) với giá trị là "Google". Mỗi khiếu nại bao gồm một phạm vi để có thể xác định liệu khiếu nại có ý nghĩa bên ngoài, cục bộ hoặc cả hai (hoặc chi tiết hơn nếu cần.)

Điểm chính là tất cả các khiếu nại đều được đính kèm rõ ràng vào một danh tính và bao gồm một phạm vi rõ ràng. Những tuyên bố đó tất nhiên có thể được sử dụng để ủy quyền - và ASP.NET MVC cung cấp hỗ trợ cho điều đó thông qua thuộc tính Authorize, nhưng đó không phải là mục đích chính hoặc duy nhất thậm chí là chính cho Yêu cầu bồi thường. Nó chắc chắn không phân biệt nó với Vai trò, có thể được sử dụng theo những cách chính xác giống như cách ủy quyền trong phạm vi địa phương.

Vì vậy, người ta có thể chọn sử dụng Vai trò, hoặc Yêu cầu hoặc cả hai cho mục đích ủy quyền và có thể không tìm thấy lợi thế hoặc bất lợi cố hữu nào, miễn là các Vai trò và Khiếu nại đó nằm trong phạm vi cục bộ. Nhưng nếu, ví dụ, ủy quyền phụ thuộc vào khiếu nại nhận dạng bên ngoài, thì Vai trò sẽ không đầy đủ. Bạn sẽ phải chấp nhận yêu cầu bên ngoài và chuyển nó thành vai trò phạm vi cục bộ. Không nhất thiết có bất cứ điều gì sai với điều đó, nhưng nó giới thiệu một lớp không xác định và loại bỏ bối cảnh.

Rộng hơn, bạn nên xem xét kiểm soát truy cập dựa trên thuộc tính (ABAC). RBAC và ABAC đều là các khái niệm được định nghĩa bởi NIST, Viện Tiêu chuẩn và Công nghệ Quốc gia. CBAC, mặt khác, là một mô hình được thúc đẩy bởi Microsoft rất giống với ABAC.

Đọc thêm tại đây:

• Trang NIST kiểm soát truy cập dựa trên vai trò
• Trang NIST kiểm soát truy cập dựa trên thuộc tính

Cơ bản giữa RBAC và CBAC là:

RBAC : người dùng phải được gán cho một vai trò được ủy quyền để thực hiện một hành động.

CBAC : người dùng phải có khiếu nại với giá trị chính xác, như mong đợi của ứng dụng, để được ủy quyền. Kiểm soát truy cập dựa trên yêu cầu là thanh lịch để viết và dễ bảo trì hơn.

Bên cạnh đó, các khiếu nại được phát hành cho ứng dụng bởi một dịch vụ ủy quyền phát hành (Mã thông báo dịch vụ bảo mật STS) được ứng dụng của bạn (Relying Party) tin cậy

Vai trò chỉ là một loại Yêu cầu. Như vậy, có thể có nhiều loại yêu cầu khác, ví dụ tên người dùng là một trong những loại yêu cầu

Điều quan trọng trước tiên là phân tích những gì Xác thực được yêu cầu trước khi quyết định phương pháp nào là tốt nhất. Từ tài liệu của Microsoft dưới đây, có ghi "Yêu cầu bồi thường không phải là điều mà đối tượng có thể làm. Ví dụ: bạn có thể có bằng lái xe, do cơ quan cấp giấy phép lái xe địa phương cấp. Giấy phép lái xe của bạn có ngày sinh của bạn. tên khiếu nại sẽ là DateOfBirth, giá trị khiếu nại sẽ là ngày sinh của bạn, ví dụ ngày 8 tháng 6 năm 1970 và nhà phát hành sẽ là cơ quan cấp giấy phép lái xe. Đơn giản nhất, kiểm tra giá trị của khiếu nại và cho phép truy cập vào một tài nguyên dựa trên giá trị đó. Ví dụ: nếu bạn muốn truy cập vào câu lạc bộ đêm, quy trình ủy quyền có thể là: 6 "

Từ ví dụ này, chúng ta có thể thấy rằng việc truy cập vào một câu lạc bộ đêm với Ủy quyền dựa trên Yêu cầu sẽ khác với loại Ủy quyền sẽ được yêu cầu bởi các nhân viên làm việc trong câu lạc bộ đêm, trong trường hợp này, nhân viên của câu lạc bộ đêm sẽ yêu cầu Ủy quyền dựa trên vai trò không bắt buộc đối với khách tham quan câu lạc bộ đêm vì tất cả khách tham quan câu lạc bộ đêm đều có mục đích chung tại câu lạc bộ đêm do đó trong trường hợp này, Ủy quyền dựa trên yêu cầu phù hợp cho khách tham quan câu lạc bộ đêm.

Ủy quyền dựa trên vai trò https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 10/14/2016 Khi một danh tính được tạo, nó có thể thuộc về một hoặc nhiều vai trò. Ví dụ: Tracy có thể thuộc về vai trò Quản trị viên và Người dùng trong khi Scott chỉ có thể thuộc về vai trò Người dùng. Làm thế nào những vai trò này được tạo và quản lý phụ thuộc vào kho lưu trữ sao lưu của quy trình ủy quyền. Các vai trò được tiếp xúc với nhà phát triển thông qua phương thức IsInRole trên lớp ClaimsPrincipal.

Ủy quyền dựa trên yêu cầu https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims 14/10/2016 Khi một danh tính được tạo, nó có thể được chỉ định một hoặc nhiều khiếu nại do một bên đáng tin cậy đưa ra. Khiếu nại là cặp giá trị tên đại diện cho chủ đề là gì, không phải chủ thể có thể làm gì. Ví dụ: bạn có thể có bằng lái xe, do cơ quan cấp giấy phép lái xe địa phương cấp. Bằng lái xe của bạn có ngày sinh của bạn trên đó. Trong trường hợp này, tên yêu cầu sẽ là DateOfBirth, giá trị khiếu nại sẽ là ngày sinh của bạn, ví dụ ngày 8 tháng 6 năm 1970 và nhà phát hành sẽ là cơ quan cấp giấy phép lái xe. Ủy quyền dựa trên yêu cầu, đơn giản nhất, kiểm tra giá trị của khiếu nại và cho phép truy cập vào tài nguyên dựa trên giá trị đó. Ví dụ: nếu bạn muốn truy cập vào một câu lạc bộ đêm, quy trình ủy quyền có thể là:

Nhân viên an ninh cửa sẽ đánh giá giá trị ngày yêu cầu sinh của bạn và liệu họ có tin tưởng nhà phát hành (cơ quan cấp giấy phép lái xe) trước khi cấp cho bạn quyền truy cập hay không.

Một danh tính có thể chứa nhiều khiếu nại với nhiều giá trị và có thể chứa nhiều khiếu nại cùng loại.

Cũng có thể quản lý vai trò theo cách yêu cầu bồi thường.

Thay vì tạo các vai trò ủy quyền phản ánh vai trò kinh doanh, hãy tạo các vai trò phản ánh vai trò hành động, ví dụ: CreatCustomer, EditCustomer, DeleteCustomer. Chú thích các phương pháp theo yêu cầu.

Việc ánh xạ các cá nhân vào một tập hợp các vai trò hành động không phải là vấn đề đơn giản, đặc biệt khi danh sách vai trò ngày càng lớn. Do đó, bạn sẽ cần quản lý các vai trò kinh doanh ở mức độ chi tiết thấp hơn (ví dụ: Bán hàng, Tiếp thị) và ánh xạ Vai trò kinh doanh theo các vai trò hành động cần có. Tức là, thêm người dùng vào vai trò kinh doanh và nó ánh xạ họ đến các vai trò (hành động) bắt buộc trong bảng ủy quyền hiện có.

Bạn thậm chí có thể ghi đè vai trò kinh doanh và thêm một người vào vai trò hành động trực tiếp.

Vì bạn xây dựng dựa trên những gì đã hoạt động, bạn không hoàn tác quy trình Ủy quyền hiện có. Bạn chỉ cần thêm một vài bảng để thực hiện phương pháp này

Tôi nghĩ rằng câu hỏi này có thể được trả lời từ cơ sở dữ liệu tiềm năng. Nếu bạn nhận thấy các bảng liên quan đến việc cấy ghép này, bạn sẽ tìm thấy như sau

1. AspNetUsers: mỗi người dùng có một hàng với tất cả các thuộc tính được yêu cầu bởi tất cả người dùng như email, địa chỉ điện thoại, mật khẩu .....
2. AspNetRoles; xác định các vai trò khác nhau theo yêu cầu ứng dụng như GM, CTO, HRM, ADMIN, EMP. những gì mỗi vai trò định nghĩa là theo nhu cầu ứng dụng.
3. AspNetUserRoles: mỗi hàng liên kết AspNetUsers và AspNetRoles và liên kết hiệu quả giữa một người dùng và nhiều vai trò.
4. AspNetUserClaims: mỗi hàng có khóa cho AspNetUsers và một loại và giá trị. rất hiệu quả khi thêm một thuộc tính cho mỗi người dùng có thể được thêm / xóa trong thời gian chạy.

Việc sử dụng các bảng này có thể được điều chỉnh tại một thời điểm trong vòng đời của người dùng / ứng dụng để phù hợp với các nhu cầu cụ thể.

Hãy xem xét giai đoạn đầu của "Quản lý mua hàng" (PM), chúng ta có thể có ba cách tiếp cận

1. Ứng dụng điền vào AspNetUserRoles với một hàng để cấp quyền mua 'PM'. Để phát hành đơn đặt hàng với bất kỳ số tiền nào, người dùng chỉ cần vai trò "PM".

2. Ứng dụng cư trú với AspNetUserRoles với một hàng để cấp quyền mua 'PM' và điền vào AspNetUserCó yêu cầu loại TYPE 'Số tiền mua' và giá trị "<1000" để đặt giới hạn số lượng. Để phát hành đơn đặt hàng, người dùng cần phải có 'PM' và số tiền đặt hàng nhỏ hơn giá trị khiếu nại của yêu cầu TYPE 'Số tiền mua hàng'.

3. Ứng dụng điền vào AspNetUserCách yêu cầu loại TYPE 'Số tiền mua hàng' và giá trị "<1000". Bất kỳ người dùng nào cũng có thể phát hành đơn đặt hàng, với số tiền nhỏ hơn giá trị khiếu nại của yêu cầu LOẠI 'Số tiền mua hàng' cho người dùng này.

Như có thể nhận thấy, vai trò dựa trên các quyền cứng nhắc sẽ đơn giản hóa cuộc sống của người dùng ứng dụng theo quan điểm quản lý hệ thống. tuy nhiên, nó sẽ giới hạn khả năng của người dùng theo quan điểm yêu cầu kinh doanh. Mặt khác, yêu cầu dựa trên là các quyền rất tốt cần được chỉ định cho mỗi người dùng. dựa trên yêu cầu sẽ đẩy doanh nghiệp quá giới hạn, tuy nhiên sẽ làm cho việc quản lý hệ thống trở nên rất phức tạp.

Kiểm soát truy cập dựa trên vai trò (RBAC)

Trong tổ chức của bạn, bạn có thể có các vai trò sau

Nhân viên

Giám đốc

Nhân sự

Tùy thuộc vào vai trò hoặc vai trò mà người dùng đã đăng nhập thuộc về, bạn có thể hoặc không thể ủy quyền truy cập vào một số tài nguyên trong ứng dụng. Vì chúng tôi đang sử dụng Vai trò để thực hiện kiểm tra ủy quyền, nên điều này thường được gọi là Kiểm soát truy cập dựa trên vai trò (RBAC) hoặc Ủy quyền dựa trên vai trò.

Trong ASP.NET Core để thực hiện ủy quyền dựa trên vai trò, chúng tôi sử dụng thuộc tính Authorize với tham số Roles.

[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}

Kiểm soát truy cập dựa trên yêu cầu (CBAC)

Yêu cầu là gì? Một yêu cầu là một cặp tên-giá trị. Đó thực sự là một phần thông tin về người dùng, không phải những gì người dùng có thể và không thể làm. Ví dụ: tên người dùng, email, tuổi, giới tính, v.v ... đều là những yêu cầu. Cách bạn sử dụng các khiếu nại này để kiểm tra ủy quyền trong ứng dụng của bạn tùy thuộc vào yêu cầu ủy quyền và kinh doanh ứng dụng của bạn.

Ví dụ: nếu bạn đang xây dựng một cổng thông tin nhân viên, bạn có thể cho phép người dùng đăng nhập đăng ký nghỉ thai sản nếu giá trị yêu cầu giới tính là nữ. Tương tự, nếu bạn đang xây dựng một ứng dụng thương mại điện tử, bạn có thể cho phép người dùng đã đăng nhập gửi đơn đặt hàng nếu giá trị yêu cầu tuổi lớn hơn hoặc bằng 18.

Khiếu nại dựa trên chính sách. Chúng tôi tạo ra một chính sách và bao gồm một hoặc nhiều khiếu nại trong chính sách đó. Chính sách này sau đó được sử dụng cùng với tham số chính sách của thuộc tính Authorize để triển khai ủy quyền dựa trên khiếu nại.

[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}