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, LoginProvidervà ProviderKey.
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:
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:
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
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. :(
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 Rolevà Technician 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.
Có hai loại xác thực trong danh tính ASP.Net.
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.