Các khiếu nại trong Nhận dạng .NET .NET là gì


174

Ai đó có thể giải thích, cơ chế khiếu nại có nghĩa gì trong ASP.NET Identity Core mới không?

Như tôi có thể thấy, có một AspNetUserLoginsbảng chứa UserId, LoginProviderProviderKey.

Nhưng, tôi vẫn không thể hiểu hoặc tìm thấy bất kỳ thông tin nào khi dữ liệu được thêm vào AspNetUserClaimsbảng và tình huống mà bảng này được sử dụng cho?

Câu trả lời:


207

Cơ chế xác nhận nghĩa là gì trong ASP.NET Identity Core mới?

Có hai cách tiếp cận ủy quyền phổ biến dựa trên Vai trò và Yêu cầu bồi thường.

Bảo mật dựa trên vai trò

Người dùng được gán cho một hoặc nhiều vai trò thông qua đó người dùng có quyền truy cập. Ngoài ra, bằng cách gán người dùng cho một vai trò, người dùng ngay lập tức nhận được tất cả các quyền truy cập được xác định cho vai trò đó.

Bảo mật dựa trên yêu cầu bồi thường

Một danh tính dựa trên yêu cầu là tập hợp các yêu cầu. Khiếu nại là một tuyên bố mà một thực thể (người dùng hoặc ứng dụng khác) tự đưa ra, đó chỉ là một tuyên bố. Ví dụ: danh sách khiếu nại có thể có tên người dùng, e-mail của người dùng, tuổi của người dùng, ủy quyền của người dùng cho một hành động. Trong Bảo mật dựa trên vai trò, người dùng trình bày thông tin đăng nhập trực tiếp cho ứng dụng. Trong mô hình dựa trên khiếu nại, người dùng trình bày các khiếu nại chứ không phải thông tin đăng nhập cho ứng dụng. Để một yêu cầu có giá trị thực tế, nó phải đến từ một thực thể mà ứng dụng tin tưởng.

Các bước dưới đây minh họa trình tự xảy ra trong mô hình bảo mật dựa trên khiếu nại:

  1. Người dùng yêu cầu một hành động. Ứng dụng bên dựa (RP) yêu cầu mã thông báo.
  2. Người dùng trình bày thông tin đăng nhập cho cơ quan cấp phát hành mà ứng dụng RP tin tưởng.
  3. Cơ quan phát hành phát hành mã thông báo đã ký với các khiếu nại, sau khi xác thực thông tin đăng nhập của người dùng.
  4. Người dùng trình bày mã thông báo cho ứng dụng RP. Ứng dụng xác nhận chữ ký mã thông báo, trích xuất các khiếu nại và dựa trên các khiếu nại, chấp nhận hoặc từ chối yêu cầu.

Nhưng, tôi vẫn không thể hiểu và tìm thấy bất kỳ thông tin nào, khi dữ liệu thêm vào AspNetUserClaims và tình huống mà bảng này sử dụng cho?

Khi bạn ở trong tình huống Bảo mật dựa trên vai trò không được sử dụng và bạn đã chọn sử dụng Bảo mật dựa trên yêu cầu, bạn sẽ cần sử dụng bảng AspNetUserClaims. Để biết cách sử dụng Yêu cầu bồi thường trong Nhận dạng ASP.NET, hãy xem liên kết bên dưới để biết thêm thông tin.

http://kevin-junghans.blogspot.com/2013/12/USE-claims-in-aspnet-identity.html

Cập nhật

Thời gian nào tôi phải sử dụng bảo mật dựa trên vai trò và khi dựa trên yêu cầu? Bạn có thể vui lòng viết một vài ví dụ?

Không có một tình huống rất rõ ràng khi bạn sẽ hoặc không sử dụng Bảo mật dựa trên vai trò hoặc Yêu cầu dựa trên vai trò, Không giống như trường hợp bạn sẽ sử dụng A thay vì B.

Nhưng, kiểm soát truy cập dựa trên yêu cầu cho phép tách tốt hơn các quy tắc ủy quyền khỏi logic kinh doanh cốt lõi. Khi quy tắc ủy quyền thay đổi, logic kinh doanh cốt lõi vẫn không bị ảnh hưởng. Sẽ có những tình huống mà bạn có thể thích sử dụng phương pháp Yêu cầu dựa trên yêu cầu.

Đôi khi yêu cầu không cần thiết. Đây là một từ chối trách nhiệm quan trọng. Các công ty có một loạt các ứng dụng nội bộ có thể sử dụng Xác thực Windows tích hợp để đạt được nhiều lợi ích được cung cấp bởi khiếu nại. Active Directory thực hiện rất tốt việc lưu trữ danh tính người dùng và vì Kerberos là một phần của Windows, các ứng dụng của bạn không phải bao gồm nhiều logic xác thực. Miễn là mọi ứng dụng bạn xây dựng có thể sử dụng Xác thực Windows tích hợp, bạn có thể đã đạt đến danh tính không tưởng. Tuy nhiên, có nhiều lý do tại sao bạn có thể cần một cái gì đó ngoài xác thực Windows. Bạn có thể có các ứng dụng đối mặt với web được sử dụng bởi những người không có tài khoản trong miền Windows của bạn. Một lý do khác có thể là công ty của bạn đã sáp nhập với một công ty khác và bạn ' đang gặp sự cố khi xác thực trên hai khu rừng Windows không (và có thể không bao giờ) có mối quan hệ tin cậy. Có lẽ bạn muốn chia sẻ danh tính với một công ty khác có ứng dụng .NET không phải là .NET hoặc bạn cần chia sẻ danh tính giữa các ứng dụng chạy trên các nền tảng khác nhau (ví dụ: Macintosh). Đây chỉ là một vài tình huống trong đó nhận dạng dựa trên yêu cầu có thể là lựa chọn phù hợp cho bạn.

Để biết thêm thông tin, vui lòng truy cập http://msdn.microsoft.com/en-us/l Library / ff359101.aspx


6
Cảm ơn bạn đã trả lời, nhưng tôi vẫn không hiểu, thời gian nào tôi phải sử dụng bảo mật dựa trên vai trò và khi dựa trên yêu cầu? Bạn có thể vui lòng viết một vài ví dụ?
Maxim Zhukov

1
@ FSou1, thực sự không có trường hợp nào bạn sẽ sử dụng phương pháp dựa trên vai trò hoặc yêu cầu dựa trên vai trò. Xem câu trả lời cập nhật của tôi để rõ ràng hơn.
Lin

The user presents the credentials to the issuing authority that the RP application trusts.Những gì bạn có thể sử dụng như cơ quan / nhà phát hành này? Một số ví dụ sẽ tốt đẹp. Tôi đỏ bài viết trên trang web msDN (liên kết bạn cung cấp), nhưng họ chỉ liệt kê một ví dụ: ADFS, còn có lựa chọn nào khác không? Không thể tìm thấy thông tin này ở bất cứ đâu. :(
Jo Smo

1
Hướng dẫn về Nhận dạng và Kiểm soát truy cập dựa trên yêu cầu cung cấp giải thích đầy đủ về các cách tiếp cận dựa trên quyền truy cập dựa trên yêu cầu dựa trên vai trò (RBAC). Toàn bộ cuốn sách có sẵn miễn phí và trực tuyến thông qua tải xuống MS. goodreads.com/book/show/ từ
Chris Mylonas

2
Có thể tải xuống miễn phí cuốn sách Microsoft miễn phí được đề cập bởi @ChrisMylonas từ Microsoft tại đây: microsoft.com/en-us/doad/details.aspx?id=28362
OzBob

16

Chỉ để thêm nhiều hơn về những gì @Lin đã nói ở trên. Tôi đặc biệt đề cập đến câu hỏi:

Thời gian nào tôi phải sử dụng bảo mật dựa trên vai trò và khi dựa trên yêu cầu? Bạn có thể vui lòng viết một vài ví dụ?

Hãy xem xét một trường hợp bạn có một hệ thống đồng hồ nơi bạn có một kỹ thuật viên và một người quản lý. Vào cuối mỗi tuần, kỹ thuật viên phải sắp xếp các báo cáo với thông tin đồng hồ hiển thị giờ làm việc của các nghệ nhân làm việc trong tuần đó, được tổng hợp và sử dụng bởi bảng lương. Các hệ thống như vậy thường phải được sửa đổi hoặc sửa chữa trước khi báo cáo cuối cùng được gửi, bởi vì bạn không muốn trả quá cao hoặc trả lương thấp cho nhân viên của mình. Bạn có thể sử dụng Role-Basedcách tiếp cận cho Người quản lý và Kỹ thuật viên bằng cách tạo Manager RoleTechnician Role. Nhưng cái Manager Rolenày có khả năng truy cập và chỉnh sửa thông tin đồng hồ của các nghệ nhân. Mặt khác, bạn có thể cóTechnician Rolekhông có những khả năng này để truy cập thông tin đó. Nhưng đây là phần thú vị; Người quản lý có thể đưa ra yêu cầu và cho phép kỹ thuật viên truy cập Hệ thống Đồng hồ và báo cáo. Vì vậy, yêu cầu chỉ có thể được đưa ra để truy cập mà không cần chỉnh sửa hoặc có thể được thực hiện với khả năng truy cập và chỉnh sửa.

Nó giống như nói, Vâng, theo mặc định là người quản lý tôi có thể truy cập một số thông tin mà kỹ thuật viên của tôi không thể truy cập. Nhưng tôi không phải lúc nào cũng ở quanh văn phòng? Tôi có thể làm gì để anh ấy vẫn có thể làm việc ngay cả khi tôi không ở bên? Để giải quyết điều này, hệ thống có thể có tính năng cho người quản lý tạo khiếu nại cho mọi người mà không cần truy cập vào một số thông tin cụ thể. Chúng tôi thường thấy những thứ này ở mọi nơi trong hệ thống ERP của chúng tôi. Người dùng không có quyền truy cập vào một số mô-đun và khi được quảng cáo, họ cho phép nhiều mô-đun của hệ thống ERP hơn, đôi khi vẫn giữ nguyên vai trò người dùng.

Đây là một ví dụ bạn có thể xem xét để hiểu các yêu cầu và vai trò nhiều hơn.


0

Có hai loại xác thực trong danh tính ASP.Net.

  1. Dựa trên vai trò
  2. Yêu cầu dựa trên

Bạn có thể sử dụng một trong hai hoặc cả hai cùng một lúc. Sử dụng vai trò dựa trên khi bạn có những điều rất xác định. Ví dụ, bạn tạo hai giáo viên và học sinh rolea. Chỉ giáo viên có thể thêm môn học. Vì vậy, bạn đã chỉ định vai trò giáo viên cho những người dùng mà bạn muốn có quyền truy cập để thêm đối tượng.

Yêu cầu dựa trên là linh hoạt hơn. Giả sử bạn có một yêu cầu một số sinh viên cũng có thể thêm các môn học. Trong trường hợp này, bạn phải tạo thêm một vai trò có thể là sinh viên và truy cập để thêm chủ đề. Nhưng nếu bạn đang sử dụng yêu cầu dựa trên nó sẽ rất dễ dàng. Chỉ cần tạo khiếu nại như addSubject và gán nó cho bất kỳ người dùng nào bạn muốn truy cập để thêm aubject.

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.