Quyền / mô hình đúng / mẫu cho ứng dụng .NET


9

Tôi cần triển khai linh hoạt VÀ đơn giản (nếu điều đó tồn tại) và đồng thời sử dụng các phương tiện tích hợp nếu có thể

Cho đến nay tôi đã thực hiện MemberhipProvider và RoleProviders. Điều này thật tuyệt nhưng tôi sẽ đi đâu tiếp theo?

Tôi cảm thấy mình cần thêm thuật ngữ "Đặc quyền" và mã hóa cứng hơn những ứng dụng bên trong ứng dụng. Người dùng sẽ định cấu hình vai trò để thêm Privilidges vào Vai trò và gán Vai trò cho người dùng.

Nghe có vẻ như là một mô hình tốt? Tôi có nên nghĩ về việc thêm các đặc quyền ở cấp độ Người dùng lên trên việc thêm chúng vào Vai trò không? Tôi có thể nhưng tôi hình dung các vấn đề với thiết lập (khó hiểu) và làm theo hỗ trợ.

Nếu tôi không làm điều đó và một số người dùng cụ thể sẽ cần các đặc quyền ít hơn - quản trị viên sẽ phải tạo một vai trò khác, v.v.

Bất kỳ viên đạn bạc cho hệ thống như thế này? Và tại sao Microsoft không đi xa hơn chỉ là nhà cung cấp Thành viên và Vai trò?

Một ý tưởng khác: Rời khỏi vai trò là người nắm giữ "đặc quyền" và mã hóa chúng. Sau đó, tôi có thể mã hóa các vai trò đó trong ứng dụng bằng cách sử dụng tất cả các đánh dấu / thuộc tính có sẵn, v.v. - tất cả Microsoft.

Thêm "Nhóm" thực thể mới và tạo mối quan hệ như thế này

  • Người dùng
  • Các nhóm người sử dụng
  • Các nhóm
  • Nhóm vai trò
  • Vai trò

Bằng cách này, tôi có thể thu thập các Vai trò thành các nhóm và gán các nhóm đó cho Người dùng. Âm thanh tuyệt vời và phù hợp với các mẫu phần mềm khác. Nhưng sau đó tôi thực sự không thể thực hiện những thứ bên trong RoleProvider như:

  • AddUsersToRoles
  • RemoveUsersFromRoles

Và một số thứ không thực sự có ý nghĩa nữa bởi vì chúng sẽ được mã hóa cứng

  • XóaRole
  • Tạo

Câu trả lời:


5

Nếu ủy quyền dựa trên vai trò không đủ chi tiết cho bạn thì hãy xem xét sử dụng Ủy quyền dựa trên yêu cầu .

Khiếu nại mô tả tài nguyên và hoạt động - giống như một mục trong ACL, nhưng linh hoạt hơn, vì "tài nguyên" không phải là một đối tượng vật lý, nó có thể là bất cứ thứ gì bạn muốn và có thể chứa bất kỳ thông tin nào bạn muốn.

Trong mô hình này, một yêu cầu tương đương với những gì bạn gọi là "đặc quyền" và nhóm bạn yêu cầu bồi thường thành các nhóm yêu cầu, tương đương với những gì bạn gọi là "vai trò". Tất cả các API này và hơn thế nữa đã có trong System.IdentityModelkhông gian tên.

Tất nhiên bạn đề cập MembershipProviderRoleProvidervà nếu bạn đang cố gắng nhồi nhét tất cả vào mô hình thành viên ASP.NET (như những cái tên đó ngụ ý), thì hãy quên nó đi. Nếu bạn muốn sử dụng các API của nhà cung cấp đó thì bạn phải thực hiện theo cách của họ và cách của họ không có nhiều chi tiết hơn khái niệm về vai trò.

Thay vào đó, trong ASP.NET, khái niệm "đặc quyền" thực sự được mã hóa ở cấp độ hành động hoặc hoạt động , nơi bạn tuyên bố vai trò nào được phép thực hiện hành động đó. Điều này thực sự dễ dàng hơn rất nhiều để xử lý trong ASP.NET MVC khi bạn chỉ cần vỗ [AuthorizeAttribute]vào bộ điều khiển hoặc hành động của bộ điều khiển; trong ASP.NET "trường học cũ", bạn đang xử lý các sự kiện, do đó, ủy quyền có xu hướng hoặc là đột xuất hoặc ở cấp độ trang (hoặc cả hai).


Rất nhiều thông tin tuyệt vời, cảm ơn! Ứng dụng thực sự là ứng dụng Silverlight với một phần máy chủ được hiển thị dưới dạng dịch vụ WCF RESTful. Dựa trên yêu cầu có vẻ thú vị nhưng tôi không nhận thấy khái niệm về người dùng và quyền tự động bên trong nó. Bài viết thú vị tôi vừa tìm thấy: geekswithbloss.net/shahed/archive/2010/02/05/137795.aspx
katit

@katit: Hầu như tất cả xác thực / ủy quyền trong .NET đều dựa trên giao diện IPrincipal . Nếu bạn đang làm tuyên bố dựa trên uỷ quyền sau đó bạn sử dụng một IClaimsPrincipal cho rằng, và cast IPrincipalđể IClaimsPrincipalkhi bạn muốn làm kiểm tra tuyên bố. Bạn sẽ viết rất nhiều mã của riêng bạn nếu bạn muốn điều chỉnh nó bằng (ví dụ) Xác thực mẫu, nhưng rõ ràng nó có thể được thực hiện (theo liên kết).
Aaronaught

câu hỏi là .. Có thể dễ dàng hơn khi chỉ thêm một cấp độ "Nhóm" khác cho các nhà cung cấp thành viên / vai trò hoặc viết nhà cung cấp riêng? Khá nhiều công việc tương tự như triển khai Microsoft
katit

3
@katit: Lời cuối nổi tiếng. Đừng phát minh ra của riêng bạn trừ khi bạn có lý do rất chính đáng để phát minh của riêng bạn ("có vẻ dễ hơn" không phải là lý do chính đáng; nó chỉ có vẻ dễ hơn khi bạn không có kinh nghiệm trực tiếp và do đó không có khả năng phán đoán khối lượng công việc cần thiết).
Aaronaught
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.