2011-11-02 46 views
6

Tôi có ứng dụng C# .net phục vụ cả người dùng nội bộ và khách hàng bên ngoài của công ty. Tôi cần phải thực hiện ủy quyền chi tiết như những người truy cập tài nguyên nào. Vì vậy, tôi cần một cái gì đó như dựa trên tài nguyên hoặc dựa trên thuộc tính chứ không phải là ủy quyền dựa trên vai trò.Ủy quyền chi tiết cho các ứng dụng web

gì nói đến cái tâm của tôi là một trong hai:

  1. Thực hiện cơ chế ủy quyền của riêng tôi và bảng sql cho các ứng dụng .net tôi
  2. Sử dụng/thực hiện một cơ chế tiêu chuẩn, giống như một phần mềm mà đã thực hiện XACML (Ví dụ Axiomatics)

Vấn đề với phương pháp đầu tiên là nó không được tập trung và tiêu chuẩn để các hệ thống khác không thể sử dụng nó để ủy quyền.

Vấn đề với phương pháp thứ hai là nó có khả năng chậm hơn (do các cuộc gọi bổ sung cần thiết cho mỗi tài nguyên). Ngoài ra, tôi không chắc chắn việc một ủy quyền chuẩn như XACML được hỗ trợ bởi các ứng dụng trên thị trường như thế nào để làm cho việc tích hợp trong tương lai trở nên dễ dàng hơn.

Vì vậy, nói chung thực tiễn tốt cho ủy quyền chi tiết cho các ứng dụng web có nhiệm vụ phục vụ cả người dùng nội bộ và khách hàng bên ngoài là gì?

+0

Quyền truy cập có thể được thể hiện dưới dạng chính sách (quy tắc chung bao gồm nhiều tình huống) hay là quyết định chia sẻ của người dùng giữa nhau và về cơ bản tùy ý? – kgilpin

+0

@kgilpin: Quyền truy cập có thể vừa là chung và cụ thể. Nói chung như trong "chỉ nhóm A có thể đọc hóa đơn" và cụ thể như trong "người dùng X đã đọc quyền truy cập vào tài khoản Alpha". – kaptan

+0

Tôi nghĩ rằng có một số nhầm lẫn những ngày này về những gì dựa trên vai trò kiểm soát truy cập (RBAC) thực sự là. Trong hình dung chính thức của nó, RBAC là rất nhiều khả năng làm những gì bạn mong muốn. Bạn đã mô tả hai vai trò: "người đọc hóa đơn" và "người đọc của tài khoản Alpha". Bạn có hai câu trả lời dưới đây là từ các nhà cung cấp kiểm soát truy cập dựa trên thuộc tính, nhưng các quy tắc bạn mô tả ở trên không có thuộc tính dựa trên thuộc tính đối với tôi. Có một nhận thức rằng "RBAC không thể làm điều này", bởi vì mọi người nhầm lẫn hình thức của RBAC với một số triển khai khá yếu của RBAC. – kgilpin

Trả lời

8

Tôi chắc chắn sẽ cho phép ủy quyền bên ngoài. Nó không có nghĩa là nó sẽ chậm hơn. Điều đó có nghĩa là bạn đã tách biệt kiểm soát truy cập khỏi logic nghiệp vụ.

Tổng quan XACML là một cách hay để thực hiện. TC rất tích cực và các công ty như Boeing, EMC, Quản trị Cựu chiến binh, Oracle và Axiomatics đều là thành viên tích cực.

Kiến trúc XACML đảm bảo bạn có thể nhận được hiệu suất bạn muốn. Kể từ khi thực thi (PEP) và công cụ quyết định (PDP) được kết hợp lỏng lẻo, bạn có thể chọn cách họ giao tiếp, giao thức nào họ sử dụng, cho dù sử dụng nhiều quyết định, v.v. Điều này có nghĩa là bạn có sự lựa chọn phù hợp với nhu cầu hiệu suất của bạn.

Ngoài ra còn có giao diện PDP chuẩn được xác định trong cấu hình SAML cho XACML. Điều đó đảm bảo bạn kiểm soát truy cập 'tương lai-proof', nơi bạn không bị khóa vào bất kỳ giải pháp nhà cung cấp cụ thể.

Kiểm soát truy cập cho các ứng dụng web Bạn chỉ cần thả PEP cho các ứng dụng web .Net bằng cách sử dụng Bộ lọc HTTP trong ISAPI và ASP.NET. Axiomatics đã có một off-the-shelf cho điều đó.

Triển khai hiện tại Nếu bạn kiểm tra trang khách hàng của Axiomatics, bạn sẽ thấy họ có Paypal, Bell Helicopter và hơn thế nữa. Vì vậy XACML thực sự là một thực tế và nó có thể giải quyết các triển khai rất lớn (hàng trăm triệu người dùng).

Ngoài ra, Datev eG, nhà cung cấp dịch vụ tài chính hàng đầu đang sử dụng triển khai .P PDP của Axiomatics cho các dịch vụ/ứng dụng của nó. Kể từ khi PDP .Net được nhúng trong trường hợp đó, hiệu suất là tối ưu.

Nếu không, bạn luôn có thể chọn từ PEP có sẵn cho .Net tích hợp với bất kỳ PDP nào - ví dụ dịch vụ ủy quyền XACML dựa trên SOAP.

mức cao hiệu suất với XACML Tháng Bảy năm ngoái tại Gartner "Catalyst" hội nghị, Axiomatics công bố việc phát hành sản phẩm mới nhất của họ, Reverse Query Axiomatics giúp bạn giải quyết những 'tỷ kỷ lục thách thức'. Nó nhắm mục tiêu kiểm soát truy cập cho các nguồn dữ liệu cũng như RIA. Nó sử dụng một giải pháp XACML thuần túy để nó vẫn tương thích với các giải pháp khác.

Như một vấn đề của thực tế, Kuppinger Cole sẽ tổ chức một hội thảo trên web về chủ đề này rất sớm: http://www.kuppingercole.com/events/n10058

Kiểm tra các Axiomatics ARQ thông cáo báo chí quá ở đây: http://www.axiomatics.com/latest-news/216-axiomatics-releases-new-reverse-query-authorization-product-a-breakthrough-innovation-for-authorization-services.html

3

Chắc chắn tìm kiếm một thả trong giấy cho phép mô-đun cho ứng dụng ASP.NET của bạn. Tôi không chỉ nói rằng bởi vì tôi triển khai hệ thống xác thực thả xuống tại BiTKOO, nhưng bởi vì tôi đã phải làm việc với các triển khai thực hiện auth được trồng tại nhà trong quá khứ. Xây dựng hệ thống ủy quyền của riêng bạn cho một ứng dụng duy nhất thực sự không phải là việc sử dụng thời gian hoặc tài nguyên của bạn tốt trừ khi bạn có ý định thực hiện sự nghiệp trong việc triển khai các hệ thống bảo mật.

Bên ngoài quyết định cấp phép từ ứng dụng của bạn là ý tưởng hay từ quan điểm kiến ​​trúc. Bên ngoài quyết định authz cung cấp cho bạn một số lượng lớn tính linh hoạt để thay đổi các tiêu chí truy cập của bạn mà không phải tắt dịch vụ web của bạn hoặc cấu hình lại máy chủ web. Việc tách giao diện web khỏi công cụ authz cho phép bạn mở rộng quy mô độc lập theo tải và mẫu lưu lượng truy cập của ứng dụng và cho phép bạn chia sẻ công cụ authz trên nhiều ứng dụng.

Có, thêm cuộc gọi mạng vào ứng dụng web sẽ thêm một số phí vào phản hồi web của bạn so với không có ủy quyền nào hoặc sử dụng cơ sở dữ liệu cục bộ trên máy chủ web. Đó không phải là lý do không xem xét ủy quyền bên ngoài. Bất kỳ sản phẩm ủy quyền nghiêm trọng nào bạn xem xét sẽ cung cấp một số loại khả năng lưu bộ nhớ đệm để giảm thiểu số lượng cuộc gọi mạng yêu cầu cho mỗi yêu cầu web hoặc thậm chí mỗi phiên người dùng trên nhiều yêu cầu web.

Trong hệ thống Keystone của BiTKOO, ví dụ, thuộc tính người dùng có thể được lưu trữ trên máy chủ web trên mỗi phiên người dùng, . Yêu cầu trang tiếp theo (trong vòng đời của thông tin đăng nhập được lưu trong bộ nhớ cache, thường là 5 phút hoặc lâu hơn) có thể được xử lý bởi máy chủ web mà không cần phải nhấn lại dịch vụ authz. Điều này cũng tốt trong các trang web trên đám mây và được xây dựng dựa trên các tiêu chuẩn XACML.

Các vấn đề liên quan