Các phương pháp hay nhất cho vai trò so với xác nhận quyền sở hữu trong ASP.NET Identity


94

Tôi hoàn toàn mới với việc sử dụng claimsin ASP.NETIdentityvà muốn có ý tưởng về các phương pháp hay nhất trong việc sử dụng Roles and/or Claims.

Sau tất cả bài đọc này, tôi vẫn có những câu hỏi như ...

Q: Chúng tôi không còn sử dụng Vai trò nữa?
Q: Nếu vậy, tại sao các Vai trò vẫn được cung cấp?
H: Chúng tôi có nên chỉ sử dụng Xác nhận quyền sở hữu không?
H: Chúng ta có nên sử dụng Vai trò & Xác nhận quyền sở hữu cùng nhau không?

Suy nghĩ ban đầu của tôi là chúng ta "nên" sử dụng chúng cùng nhau. Tôi xem Claimsnhư các danh mục phụ Rolesmà họ hỗ trợ.

VÍ DỤ:
Vai trò:
Tuyên bố kế toán : CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger

Q: Chúng có ý định loại trừ lẫn nhau không?
H: Hay tốt hơn là chỉ sử dụng Thông báo xác nhận quyền sở hữu và "hoàn toàn đủ điều kiện" mà bạn yêu cầu?
Q: Vậy các phương pháp hay nhất ở đây là gì?

VÍ DỤ: Sử dụng Vai trò & Yêu cầu cùng nhau
Tất nhiên, bạn sẽ phải viết logic Thuộc tính của riêng mình cho việc này ...

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

VÍ DỤ: Hoàn toàn đủ điều kiện khi yêu cầu của bạn

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

1
Vì vậy, tôi đang đối mặt với vấn đề tương tự bây giờ, cách bạn giải quyết nó và cách bạn có thể SubRole Quyền trong ứng dụng?
Loai

Câu trả lời:


77

Vai trò là một danh mục tượng trưng tập hợp những người dùng có cùng mức đặc quyền bảo mật. Ủy quyền dựa trên vai trò trước tiên yêu cầu xác định người dùng, sau đó xác định các vai trò mà người dùng được chỉ định và cuối cùng so sánh các vai trò đó với các vai trò được cấp quyền truy cập tài nguyên.

Ngược lại, một xác nhận quyền sở hữu không dựa trên nhóm, mà nó dựa trên danh tính.

từ tài liệu của Microsoft :

Khi danh tính được tạo, nó có thể được gán một hoặc nhiều xác nhận quyền sở hữu do một bên đáng tin cậy đưa ra. Xác nhận quyền sở hữu là một cặp giá trị tên đại diện cho những gì chủ thể là, không phải những gì chủ thể có thể làm.

Kiểm tra bảo mật sau đó có thể xác định quyền truy cập tài nguyên dựa trên giá trị của một hoặc nhiều xác nhận quyền sở hữu.

Bạn có thể sử dụng cả hai trong buổi hòa nhạc hoặc sử dụng một loại trong một số tình huống và loại kia trong các tình huống khác. Nó chủ yếu phụ thuộc vào hoạt động liên kết với các hệ thống khác và chiến lược quản lý của bạn. Ví dụ: người quản lý có thể dễ dàng quản lý danh sách người dùng được chỉ định cho một vai trò hơn là quản lý người đã chỉ định một Yêu cầu cụ thể. Các xác nhận quyền sở hữu có thể rất hữu ích trong một tình huống RESTful, nơi bạn có thể chỉ định một xác nhận quyền sở hữu cho một ứng dụng khách và sau đó khách hàng có thể trình bày yêu cầu đó để ủy quyền thay vì chuyển Tên người dùng và Mật khẩu cho mọi yêu cầu.


6
Tôi không tin điều này là hoàn toàn chính xác. Tôi tin rằng Tuyên bố chỉ ra danh tính, không phải sự ủy quyền. Những gì họ được phép làm được quản lý riêng biệt. Nghĩa là, họ có thể có một xác nhận quyền sở hữu có ngày sinh cho biết rằng họ trên 18 tuổi. Khiếu nại này sẽ được chuyển cho Người quản lý ủy quyền có thể chứa quy tắc cho biết "nếu trên 18 tuổi, họ có thể chỉnh sửa tài nguyên X", nhưng bản thân xác nhận quyền sở hữu không chỉ ra những gì họ có thể / không thể làm hoặc truy cập. Tương tự đối với các vai trò và các yêu cầu khác. Tuyên bố cho biết bạn là ai, và được sử dụng để xác định những gì bạn có thể làm, nhưng họ không nói với bạn trực tiếp
ChrisC

Tài liệu hỗ trợ cho @ChrisC là từ ủy quyền dựa trên Yêu cầu của Microsoft trong ASP.NET Core : "Yêu cầu là một cặp giá trị tên đại diện cho chủ thể là gì, không phải những gì chủ thể có thể làm."
DrGriff

@DrGriff Cảm ơn bạn đã cung cấp liên kết đó; Tôi đã thắc mắc một lúc về tính chính xác của mô tả mà tôi đã đưa ra; Tôi nghĩ rằng tôi đã làm rõ câu trả lời dựa trên liên kết đó ngay bây giờ.
Yêu cầu

29

Như @Claies đã giải thích một cách hoàn hảo, xác nhận quyền sở hữu có thể mang tính mô tả nhiều hơn và là một loại vai trò sâu sắc. Tôi nghĩ về họ như id vai trò của bạn. Tôi có id phòng tập thể dục, vì vậy tôi thuộc về vai trò thành viên. Tôi cũng đang tham gia các bài học kickboxing, vì vậy tôi có yêu cầu id kickboxing cho họ. Đơn đăng ký của tôi sẽ cần tuyên bố về vai trò mới để phù hợp với quyền thành viên của tôi. Thay vào đó, tôi có id cho từng nhóm nhóm mà tôi thuộc, thay vì rất nhiều loại thành viên mới. Đó là lý do tại sao các tuyên bố phù hợp hơn với tôi.

Có một video giải thích tuyệt vời về Barry Dorrans, nói về lợi thế của việc sử dụng xác nhận quyền sở hữu đối với vai trò. Ông cũng nói rằng các vai trò, vẫn còn trong .NET để tương thích ngược. Video cung cấp rất nhiều thông tin về cách thức hoạt động của xác nhận quyền sở hữu, vai trò, chính sách, ủy quyền và xác thực.

Bạn có thể tìm thấy nó ở đây: Ủy quyền cốt lõi ASP.NET với Barr Dorrans


8

Đã sử dụng các kỹ thuật xác thực và ủy quyền khác nhau trong nhiều thập kỷ, ứng dụng MVC hiện tại của tôi sử dụng phương pháp sau.

Yêu cầu bồi thường được sử dụng cho tất cả các ủy quyền. Người dùng được chỉ định một vai trò (có thể có nhiều vai trò nhưng tôi không cần điều này) - thêm bên dưới.

Như thông lệ, một lớp thuộc tính ClaimsAuthorize được sử dụng. Vì hầu hết các hành động của bộ điều khiển là CRUD, tôi có một quy trình trong quá trình tạo cơ sở dữ liệu đầu tiên là lặp lại tất cả các hành động của bộ điều khiển và tạo các loại xác nhận quyền sở hữu cho từng thuộc tính hành động của bộ điều khiển là Đọc / Chỉnh sửa / Tạo / Xóa. Ví dụ từ,

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

Để sử dụng trong Chế độ xem MVC, lớp bộ điều khiển cơ sở trình bày các mục túi xem

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

Đối với menu trang web và các hành động không phải của người điều khiển, tôi có các yêu cầu khác. Ví dụ: liệu người dùng có thể xem một trường tiền tệ cụ thể hay không.

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

Vậy Roles phù hợp ở đâu?

Tôi có một bảng liên kết Vai trò với tập hợp các xác nhận quyền sở hữu (mặc định). Khi đặt ủy quyền người dùng, mặc định là cung cấp cho người dùng xác nhận vai trò của họ. Mỗi người dùng có thể có nhiều hoặc ít xác nhận quyền sở hữu hơn mặc định. Để làm cho việc chỉnh sửa trở nên đơn giản, danh sách xác nhận quyền sở hữu được hiển thị theo bộ điều khiển và hành động (liên tiếp), sau đó sẽ liệt kê các xác nhận quyền sở hữu khác. Các nút được sử dụng cùng với một chút Javascript để chọn một tập hợp các hành động nhằm giảm thiểu "nhấp chuột" cần thiết để chọn xác nhận quyền sở hữu. Khi Lưu, các xác nhận quyền sở hữu của người dùng sẽ bị xóa và tất cả các xác nhận quyền sở hữu đã chọn sẽ được thêm vào. Ứng dụng web chỉ tải xác nhận quyền sở hữu một lần, vì vậy bất kỳ thay đổi nào cũng phải nhắc tải lại trong dữ liệu tĩnh này.

Do đó, người quản lý có thể chọn xác nhận quyền sở hữu nào ở mỗi vai trò và xác nhận quyền sở hữu nào mà người dùng có sau khi đặt họ thành vai trò và xác nhận quyền sở hữu mặc định đó. Hệ thống chỉ có một số lượng nhỏ người dùng nên việc quản lý dữ liệu này rất đơn giản


3

Để hiểu sự khác biệt giữa Vai trò và Xác nhận quyền sở hữu, bạn phải đối mặt với giới hạn của vai trò và để cảm nhận cách xác nhận quyền sở hữu đối với vấn đề này, vì vậy, tôi đưa ra cho bạn 2 tình huống để nhận ra sức mạnh của xác nhận quyền sở hữu mà vai trò không thể giải quyết vấn đề này:

1- trang web của bạn phải có hai mô-đun (trang, dịch vụ .. vv) mô-đun đầu tiên dành cho trẻ em (dưới 18 tuổi) mô-đun còn lại dành cho người lớn (trên 18 tuổi) danh tính người dùng của bạn có yêu cầu về ngày sinh

bạn cần tạo chính sách cho yêu cầu này để ủy quyền cho mỗi mô-đun sẽ được cấp trên giá trị này và nếu độ tuổi của người dùng trên 18 tuổi thì anh ta có thể chuyển đến mô-đun dành cho người lớn chứ không phải trước tuổi này

Vai trò là kiểu dữ liệu Boolean bạn có thể có hoặc không có vai trò vai trò không có giá trị ác tính

2- trang web của bạn có vai trò người dùng và bạn không được ngăn quyền truy cập của người dùng để thực hiện một số bảo trì mà không thay đổi mã

trong xác nhận quyền sở hữu, bạn có thể tạo chính sách UnderConstrain mà nếu người dùng thực sự không thể xem trang, hãy cấp quyền thuộc tính cho vai trò người dùng.

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.