Xác thực CAS của dịch vụ web RESTful

Question

Ứng dụng của tôi cần truy cập vào dịch vụ web RESTful đang chạy trên một máy chủ khác. Dịch vụ web này sử dụng xác thực CAS và khi tiêu thụ thông qua trình duyệt, dịch vụ này sẽ chuyển hướng đến đăng nhập CAS nếu người dùng chưa được xác thực. Không có phương pháp để thực sự đăng nhập thông qua CAS. Ứng dụng của tôi cũng sử dụng CAS để người dùng sẽ được xác thực

Tôi muốn truy cập nó thông qua JQuery/Ajax, nhưng máy chủ dường như không được định cấu hình cho JSONP mà tôi hiểu là cần thiết vì vấn đề giữa nhiều miền .

Bây giờ, tôi có thể thực hiện các yêu cầu Ajax qua máy chủ của tôi, điều này dẫn đến câu hỏi của tôi: không có phương thức đăng nhập CAS cho máy chủ của tôi, làm cách nào tôi có thể 'biết' dịch vụ web được người dùng xác thực? Vì vậy, tôi cho rằng trước hết tôi muốn hiểu rõ những gì đang diễn ra giữa trình duyệt, CAS và dịch vụ RESTful, và cách thức ủy quyền được xử lý mà không cần phải thông qua các thông tin xác thực. Thứ hai, tôi muốn xem làm thế nào/nếu tôi có thể sao chép khi gọi dịch vụ từ máy chủ của tôi - nó sẽ không phải là phiên tương tự như yêu cầu từ trình duyệt vì vậy sẽ không có mã thông báo ủy quyền CAS, nhưng tôi không xem làm thế nào để có được một hoặc cung cấp nó.

Answer 1

Đối với câu hỏi 1 về cách xác thực/dấu hiệu duy nhất trên công trình:
Khi bạn đăng nhập máy chủ CAS (nói security.example.com) sẽ thiết lập một cookie trong trình duyệt của bạn cho miền security.example.com . Lưu lượng điển hình khi bạn truy cập các tệp được bảo mật thông qua trình duyệt trên một ứng dụng sử dụng bộ lọc xác thực và bộ lọc xác thực CAS chuẩn như sau:

1. Bộ lọc xác thực CAS được định cấu hình cho ứng dụng kiểm tra xem đối tượng người dùng có đang trong phiên không. Nếu có người dùng thông qua
2. Nếu không, bộ lọc Xác thực CAS sẽ chuyển hướng trình duyệt đến trang đăng nhập CAS. Trong một dấu hiệu trên kịch bản, máy chủ CAS nhận ra cookie của chính nó, kiểm tra xem ứng dụng đã được đăng ký và tham gia vào một dấu hiệu đơn chưa - nếu có chuyển hướng trình duyệt quay trở lại ứng dụng với một vé dịch vụ.
3. CAS lọc xác nhận cấu hình về việc áp dụng xác định vé dịch vụ và danh bạ CAS Server cho việc chứng thực vé và tạo ra sự khẳng định đối tượng

Đối với toàn bộ dòng chảy này để làm việc bạn cần cookie và xử lý phiên làm việc.

Đối với câu hỏi 2 về cách xử lý xác thực ở phía máy chủ:
Chúng tôi đã có một vấn đề tương tự trong ứng dụng của chúng tôi và sử dụng 2 cách khác nhau để có được xung quanh nó:

1. Sử dụng một người sử dụng hệ thống nội bộ và thực hiện truy cập máy chủ để truy cập máy chủ bằng thông tin xác thực của người dùng này bằng các tiêu đề xác thực cơ bản. Tất nhiên bạn cần phải có bộ lọc thích hợp được cấu hình để xử lý đăng nhập không tương tác với mã thông báo xác thực cơ bản. Điều này dễ thực hiện tuy nhiên có những nhược điểm rõ ràng như có người dùng hệ thống đặc biệt này, ứng dụng của bạn nhìn thấy mật khẩu người dùng, v.v.
2. Sử dụng proxy authentication. Trong cách tiếp cận này khi người dùng của bạn được xác thực cho ứng dụng1, nó cũng tạo ra một vé proxy được sử dụng bởi application2 (máy chủ đến cuộc gọi máy chủ). Vé ủy quyền này có thể được truyền trong máy chủ đến giao tiếp máy chủ để ứng dụng1 truy cập ứng dụng2 thay mặt cho người dùng

Answer 2

Tôi đang sử dụng thiết lập như vậy trong một trong các dự án của tôi. Một số triển khai CAS cho phép ủy quyền thông qua cuộc gọi còn lại. Thử thêm tiêu đề cấp quyền cơ bản (Mã hóa cơ sở 64 Tên người dùng và Mật khẩu). nó trông giống như

Tiêu đề này ("Cho Phép", "cơ bản")

Cũng cố gắng truy cập vào API REST sử dụng REST Client trên Mozilla cho mục đích gỡ lỗi. Nó sẽ thực sự giúp bạn hiểu các tiêu đề khác nhau, vv