Xác thực và ủy quyền tập trung cho một số dịch vụ web

Question

Có một số dịch vụ web khác nhau - chẳng hạn như Java, .NET, Python, Perl và có thể nhiều hơn trong tương lai - thuộc các tổ chức khác nhau và quyền truy cập các dịch vụ web đó phải bị hạn chế.

Ý tưởng là có máy chủ xác thực và ủy quyền trung tâm, chỉ chịu trách nhiệm cấp quyền truy cập cho từng WS.

Tôi đang tìm một hệ thống Đăng nhập một lần, trong đó người dùng xác thực một lần với máy chủ xác thực và được cấp quyền truy cập vào các dịch vụ web trong một khoảng thời gian giới hạn.

Yêu cầu bảo mật cao, do đó, bộ tên người dùng/mật khẩu không đủ. Trong một tìm kiếm nhanh, tôi đã tìm thấy nhiều giải pháp và cách tiếp cận khác nhau cho vấn đề này, nhưng tôi không biết giải pháp tốt nhất cho trường hợp này - một giải pháp độc lập, an toàn và đáng tin cậy về công nghệ.

Answer 1

Đây có phải là chính xác những gì OpenID dành cho không?

Bằng mọi cách, hãy sửa tôi nếu tôi sai.

Answer 2

Chúng tôi đã thực hiện một nghiên cứu lớn về chủ đề và không thể tìm thấy giải pháp phù hợp. (Một giải pháp gần như tốt, nhưng không quá nhiều cho các dịch vụ web là http://www.atlassian.com/software/crowd/)

Vì vậy, chúng tôi đã phát triển hệ thống quản lý người dùng trung tâm và sso cho các ứng dụng WS của chúng tôi (cũng là ứng dụng của bên thứ ba) nhưng không bán.

Nếu bạn kiểm tra các giải pháp, bạn nên kiểm tra hiệu suất của hệ thống, đặc biệt khi tải. Ban đầu hệ thống của chúng tôi chậm hơn 30 lần. Thông thường bạn sẽ tìm thấy sự chậm lại trong phân tích cú pháp xml và số lượng yêu cầu bạn phải làm (thông thường nơi bạn có một yêu cầu trong tương lai bạn sẽ có ít nhất 4). (Chúng tôi sử dụng jmeter để kiểm tra nó.) Và bạn nên thiết lập thất bại trên các hệ thống, bởi vì bạn sẽ tạo ra một lỗi điểm duy nhất với sso.

Answer 3

Vấn đề này đã được giải quyết phần lớn bởi WS-Trust, ít nhất là đối với các dịch vụ web dựa trên SOAP. WS-Trust là một giao thức được xác định rõ ràng để xác thực và trao đổi "các thẻ xác thực", và có thể được sử dụng trong các kịch bản nghiệp vụ chéo với các giao thức như WS-Federation được xây dựng trên nó.

Một trường hợp mẫu là yêu cầu khách hàng yêu cầu mã thông báo từ máy chủ WS-Trust, sau đó bao gồm mã thông báo đó trong tiêu đề SOAP cho máy chủ dịch vụ web. Mặt trái là bao gồm một cái gì đó đơn giản như <UsernameToken> trong yêu cầu tới máy chủ và có xác thực ủy nhiệm phía máy chủ cho máy chủ WS-Trust.

Có hỗ trợ khách hàng khá tốt cho WS-Trust - WCF có hỗ trợ ngoài hộp và nhiều nhà cung cấp khác có trình chặn chặn J2EE cho các dịch vụ web JAX-RPC và JAX-WS.

Trong khi trọng tâm của WS-Trust là xác thực, bạn có thể thực hiện ủy quyền chi tiết bằng cách sử dụng logic về thời điểm phát hành hoặc xác thực mã thông báo nhận được. Không phát hành/xác thực mã thông báo và quyền truy cập bị từ chối một cách hiệu quả. Ủy quyền chi tiết cho các dịch vụ web thường sẽ yêu cầu một số trình chặn chặn tùy chỉnh, cụ thể theo nhà cung cấp.

Tôi làm việc cho IBM Tivoli Security và chúng tôi có một vài sản phẩm trong không gian này. Đầu tiên là Tivoli Federated Identity Manager (TFIM). Một đồng nghiệp và bản thân tôi đã viết this article về việc tích hợp TFIM với các dịch vụ web dựa trên WSE và bao gồm tổng quan về giao thức WS-Trust.Sản phẩm thứ hai là Trình quản lý chính sách bảo mật Tivoli (TSPM), thực hiện ủy quyền chi tiết cho các dịch vụ web.

Có các triển khai mã nguồn mở của các giao thức tương tự, đó là ưu điểm của việc sử dụng giải pháp dựa trên tiêu chuẩn. Tôi tin rằng JBoss và WSO có triển khai có thể hữu ích.