Các lựa chọn thay thế cho xác thực Java là gì?

Tốt hơn là một thứ tích hợp tốt với mặt trước Flex. Có những người bảo mật Spring nói điều này là có thể, nhưng tất cả các ví dụ dường như sử dụng các thư viện thẻ jsp cũ làm cho chúng trở nên vô dụng làm ví dụ. Tôi không muốn dành một tháng để thiết lập và học cách sử dụng một công cụ bảo mật. Tôi muốn một công cụ hỗ trợ sử dụng chú thích (@RolesAllowed, v.v.), MINIMAL XML và các tính năng 'nhớ-tôi' (không dựa trên cookie).Các lựa chọn thay thế cho xác thực Java là gì?

Apache Shiro dường như cũng hỗ trợ Flex/Silverlight/Swing nhưng tôi muốn biết nếu có bất kỳ lựa chọn thay thế nào khác KHÔNG chứa cụ thể.

Nguồn

2010-05-08 Manius

Tôi đang đề xuất loại ghi nhớ nào khi bạn nói bạn không muốn cookie dựa trên? Trong một phiên, bạn có thể sử dụng các tham số trong url, nhưng giữa các phiên tôi sẽ không biết cách lưu trữ thông tin đăng nhập mà không có cookie (flash). –

Couldn't SharedObject làm điều đó? http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/SharedObject.html Tôi không biết hậu cần của việc thực hiện điều này sẽ là gì, nhưng sẽ rất tuyệt khi quản lý hoàn toàn việc quản lý phiên chứa container bằng cách sử dụng thứ gì đó KHÔNG CẦN container (như Shiro?) Tôi muốn có thể triển khai tới các thùng chứa J2EE mà không lo lắng rằng chức năng bảo mật/phiên của tôi sẽ bị hỏng mỗi lần, nhưng tôi cũng không muốn chi tiêu 1/3 của thời gian phát triển của tôi thiết lập bảo mật như vậy lên. Đó không phải là một mục tiêu đáng giá sao? – Manius

Biến ra Apache Shiro thực sự là giải pháp đơn giản và dễ học hơn bảo mật mùa xuân. Và không có cấu hình xml ngu ngốc nào tốt đẹp.

Nguồn

2010-12-19 19:37:46 Manius

Tôi không hiểu tại sao Flex nên xác thực bất cứ điều gì, sau khi tất cả đó là phía khách hàng. Whats ngăn ai đó giải mã flash/flex của bạn?

Đối với hầu hết mọi người, Apache Shiro là quá mức cần thiết và họ chỉ cần tự cuộn. Đó không phải là ý tưởng tốt nhất để trung thực. Tôi đã thấy rất nhiều hệ thống xác thực khủng khiếp trong những năm qua. Cookies có nghĩa là để theo dõi các phiên cho khách hàng, tại sao sử dụng bất cứ điều gì khác?

Chỉnh sửa: Sử dụng bí mật mùa xuân để xác thực.

Nguồn

2010-05-08 18:01:08 rook

Tôi nghĩ rằng bạn hiểu lầm, tôi không muốn Flex tự xác thực bất cứ điều gì (và swf hacking là chính xác lý do tôi đang tìm kiếm thực sự, bảo mật phía máy chủ).Nó chỉ tham gia là một thực tế rằng remoting (RemoteObject) các cuộc gọi thông qua Blaze hoặc Granite DS đang được sử dụng chứ không phải là trình đơn mẫu đơn giản, có nghĩa là các ví dụ thẻ jsp không phải là ví dụ tốt như vậy. – Manius

Ngoài ra tôi tin rằng các tài liệu Spring Security nói về một thay thế cho sự kiên trì dựa trên cookie an toàn hơn (tôi quên nó gọi là gì nhưng tôi tin nó sử dụng cơ sở dữ liệu), và tôi không cảm thấy cookie tích hợp tốt với ứng dụng Flex . Và một điều nữa - xác thực không quá khó (JAAS) nhưng ủy quyền dường như có vấn đề hơn. – Manius

@Crusader bạn hơi bối rối. Đó là một yêu cầu tuyệt đối mà bạn chuyển id phiên tới máy chủ web để duy trì trạng thái phiên. Thời tiết mà tiểu bang đang được giữ bởi một Session Bean hoặc sử dụng cơ sở dữ liệu là không thích hợp về mặt secuirty. Nếu id phiên này bị rò rỉ cho kẻ tấn công mặc dù xss hoặc đánh hơi, thì tài khoản đó bị xâm phạm. Đây là lý do tại sao OWASP A3: xác thực bị hỏng và quản lý phiên yêu cầu sử dụng HTTPS trong toàn bộ phiên. – rook

Bảo mật mùa xuân là công cụ tốt nhất hiện nay.

BlazeDS không có phép thuật. Nó cuối cùng chỉ là một cuộc gọi đến máy chủ qua HTTP. Ứng dụng Blaze chỉ là một tập tin chiến tranh và có các url truyền thống. Vì vậy, để bảo vệ các dịch vụ, bạn phải bảo vệ các url trong tệp cấu hình web.xml/spring của bạn.

Về cơ bản, hãy đọc tài liệu về Spring Security/JAAS và thay thế jsps bằng các url của dịch vụ blaze của bạn.

Bảo mật mùa xuân cũng có hỗ trợ Vai trò và ủy quyền. Nó cũng có chức năng nhớ-tôi, nhưng hoàn toàn sử dụng cookie. Bạn không thể có chức năng nhớ-tôi mà không có cookie.

Về xác thực, có thể chuyển mã thông báo xác thực làm thông số yêu cầu thay vì cookie. Nhưng cookie được khuyến khích và dễ dàng hơn nhiều để có được quyền.

Và cuối cùng, bảo mật là vô nghĩa mà không cần sử dụng https. Bạn hoàn toàn phải sử dụng https trong toàn bộ đơn đăng ký của mình nếu bạn quan tâm đến bảo mật.

Nguồn

2010-05-08 21:10:45

Tôi không hiểu tại sao mọi người lại nói rằng Spring Security thật tuyệt vời (hoặc Shiro là "quá mức cần thiết" khi Spring Security có một danh sách lớn các phụ thuộc và một đường cong học tập dốc. Mục tiêu của Shiro là "dễ sử dụng nhất", gần như KHÔNG có phụ thuộc và địa ngục, và cấu hình rất ít. Tương phản với tôn sùng mùa xuân xml Tôi chỉ không hiểu làm thế nào ai đó có thể nói rằng Shiro là quá mức cần thiết. Nếu bất cứ điều gì Spring Security có thể có nhiều tính năng hơn, nhưng cũng có nhiều cồng kềnh hơn. Có vẻ như đây là hai lựa chọn thay thế duy nhất ... – Manius

Các lựa chọn thay thế cho xác thực Java là gì?

Trả lời

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