Đăng nhập một lần cho một ứng dụng web

Question

Tôi đã cố gắng hiểu cách vấn đề này được giải quyết trong hơn một tháng nay. Tôi thực sự cần phải đưa ra một cách tiếp cận chung có hiệu quả. Tôi có một lý thuyết, nhưng tôi không chắc đó là cách tiếp cận dễ nhất (hoặc chính xác) và tôi không thể tìm thấy bất kỳ thông tin nào để hỗ trợ cho ý tưởng của tôi.

Đây là kịch bản:

1) Bạn có một ứng dụng web phức tạp cung cấp nội dung an toàn trên cơ sở đăng ký.

2) Người dùng được yêu cầu đăng nhập vào ứng dụng của bạn bằng tên người dùng và mật khẩu.

3) Bạn bán cho các tập đoàn lớn, đã có công nghệ xác thực của công ty (ví dụ: Active Directory).

4) Bạn muốn tích hợp với cơ chế xác thực của công ty để cho phép người dùng đăng nhập vào ứng dụng web của bạn mà không phải nhập tên người dùng và mật khẩu của họ.

Bây giờ, bất kỳ giải pháp bạn đưa ra sẽ phải cung cấp một cơ chế cho:

• thêm người dùng mới
• loại bỏ người dùng
• thay đổi thông tin người dùng
• cho phép người dùng đăng nhập

Lý tưởng nhất, tất cả những điều này sẽ xảy ra "tự động" khi khách hàng của công ty thực hiện các thay đổi tương ứng với xác thực của riêng họ. Bây giờ, tôi có một lý thuyết rằng cách để làm điều này (ít nhất là cho Active Directory) sẽ cho tôi để viết một ứng dụng phía máy khách tích hợp với Active Directory của khách hàng để theo dõi các thay đổi được nhắm mục tiêu, và sau đó giao tiếp những thay đổi đó đối với Ứng dụng web của tôi. Tôi nghĩ rằng nếu giao tiếp này được thực hiện thông qua các dịch vụ Web do ứng dụng web của tôi cung cấp, thì nó sẽ duy trì mức độ bảo mật không thể ngăn chặn, rõ ràng là yêu cầu đối với các khách hàng doanh nghiệp này.

Tôi đã tìm thấy một số thông tin về sản phẩm của Microsoft được gọi là Dịch vụ Liên kết Thư mục Họat động (Active Directory Federation Service - ADFS) có thể có hoặc không phải là cách tiếp cận phù hợp với tôi. Nó có vẻ hơi cồng kềnh và có một số yêu cầu có thể không hoạt động cho tất cả khách hàng.

Đối với các trường hợp ID hiện tại khác (như Athens và Shibboleth), tôi không nghĩ rằng ứng dụng khách là cần thiết. Nó có lẽ chỉ là một vấn đề của buộc vào các dịch vụ ID hiện có.

Tôi sẽ đánh giá cao bất kỳ lời khuyên nào về bất cứ điều gì tôi đã đề cập ở đây. Đặc biệt, nếu bạn có thể cho tôi biết nếu lý thuyết của tôi là chính xác về việc cung cấp một ứng dụng phía máy khách giao tiếp với các dịch vụ Web phía máy chủ, hoặc nếu tôi hoàn toàn đi sai hướng. Ngoài ra, nếu bạn có thể chỉ cho tôi tại bất kỳ trang web hoặc bài viết nào giải thích cách thực hiện điều này, tôi thực sự đánh giá cao nó. Nghiên cứu của tôi đã không bật lên nhiều cho đến nay.

Cuối cùng, nếu bạn có thể cho tôi biết về bất kỳ ứng dụng web nào hiện đang cung cấp dịch vụ này (đặc biệt là gắn với Thư mục Họat động của công ty), tôi sẽ rất biết ơn. Tôi tự hỏi nếu các ứng dụng Web B2B khác như salesforce.com, hoặc hoovers.com cung cấp một dịch vụ tương tự cho khách hàng doanh nghiệp của họ.

Tôi ghét ở trong bóng tối và sẽ đánh giá cao mọi ánh sáng bạn có thể đổ ...

Jeremy

Answer 1

Shibboleth được thiết kế để hỗ trợ chính xác trường hợp này. Tuy nhiên nó sẽ dựa vào các công ty của khách hàng của bạn thực hiện các cơ chế cung cấp danh tính. Hiện tại, điều này chỉ thực sự phổ biến ở các trường đại học. Hơn nữa, nếu bạn muốn thông tin người dùng (không chỉ là từ định danh bí danh), bạn cần công ty đồng ý giải phóng các thuộc tính đó cho bạn.

Tôi thấy khó tin rằng nhiều công ty sẽ mở hệ thống xác thực của công ty cho bạn, chỉ để cung cấp SSO.

Bạn có thể thấy tốt hơn là dựa vào OpenID hoặc tương tự và sử dụng cookie "nhớ tôi" để giảm nhu cầu nhập mật khẩu.

Answer 2

Một vấn đề cơ bản với cách tiếp cận của bạn là bạn đang xem xét cách ly ứng dụng web của mình. Nhân viên tại công ty của khách hàng của bạn sẽ không yêu cầu SSO cho ứng dụng web của bạn mà còn một số/vài/nhiều người khác và mở rộng phương pháp tiếp cận của bạn sẽ yêu cầu triển khai riêng biệt cho từng người trong số đó để cho phép truy cập.

Do đó, việc áp dụng rộng rãi OpenAthens và Shibboleth trong cộng đồng thư viện học thuật để thúc đẩy việc sử dụng thông tin đăng nhập được cấp địa phương. Một trường đại học trung bình/lớn điển hình có thể đăng ký nhiều sản phẩm/dịch vụ khác nhau từ hơn 50 nhà xuất bản khác nhau và bằng cách triển khai OpenAthens/Shibboleth họ có thể tận dụng tiêu chuẩn mở SAML (SAML là giao thức mà Shibboleth sử dụng). không chỉ trong lĩnh vực học thuật mà còn trong lĩnh vực thương mại.

Câu trả lời của John ở trên chỉ ra một vấn đề khác: có một số tiêu chuẩn mở gần đây đã xuất hiện, SAML và OpenID trong số đó. Vì vậy, các nhà cung cấp nội dung phải quyết định xem họ có muốn thực hiện một số hoặc tất cả các nguyên bản này hay không, nhưng họ sử dụng các ngăn xếp công nghệ riêng biệt và do đó chi phí triển khai và hỗ trợ có thể được nhân đôi.

Khá nhiều nhà xuất bản chính đã triển khai OpenAthens vì điều này hỗ trợ Athens, SAML/Shibboleth và OpenID trong một nền tảng duy nhất, với các tùy chọn để cắm các công nghệ khác hoặc viết mô-đun tùy chỉnh để cho phép ứng dụng nội bộ kết nối. một hệ thống ghi hóa đơn hoặc quyền lợi mà người dùng của khách hàng đang đăng nhập.

Lĩnh vực quản lý truy cập này chắc chắn sẽ chuyển sang tiêu chuẩn mở, do đó, không cho phép truy cập vào ứng dụng của bạn cho một số lượng lớn người dùng