Аутентификация из «дочернего» приложения через CAS

Question

У меня есть приложение портала, которое загружает внешний контент (виджеты) через iframe. Пользователи входят в систему CAS через сам портал. Однако существует несколько API-интерфейсов портала, которые необходимо вызывать из этого внешнего контента. Какую информацию я должен передать с портала в виджеты, которые виджеты могут использовать для совершения этих вызовов без отклонения CAS?

UPDATE

Чем больше я исследую, тем больше я думаю, что мой вопрос сводится к тому, как CAS на самом деле делает то, что должен делать. Другими словами, как я могу перейти с одного сайта, где я прошел аутентификацию, на другой и сказать, что я уже выполнил аутентификацию. Что за механизм стоит за этим и как я могу использовать его в веб-контексте.

Answer 1

Сценарий портала, который вы описываете, является именно тем, для чего была разработана служба прокси CAS. Мы используем его с системой веб-порталов на основе iframe, и она отлично работает.

Механизм создания билетов прокси-сервера CAS позволяет клиенту (вашему порталу) рассылать служебные билеты другим клиентам (виджетам, загруженным в фреймы вашего портала). Это экономит вашим пользователям поездку через сервер CAS для каждого виджета, который загружает их браузер. Проксирование также полезно, если вы пытаетесь использовать CAS для аутентификации веб-службы (т.е. когда одному веб-сервису необходимо подключиться к другому веб-сервису, защищенному CAS).

Обратите внимание, что для ваших целей продажа билетов через прокси не нужна. Настройка вашего портала-iframe должна работать без него. Но без использования прокси-серверов каждый виджет должен будет проходить через сервер CAS во время загрузки. По крайней мере, это замедлит время загрузки.

Некоторое время назад я написал руководство по настройке билетов CAS-прокси для RubyCAS-Client. Инструкции относятся к клиенту Ruby, но они должны дать вам хорошее представление о том, как работает прокси CAS. По общему признанию реализация немного сложна - главным образом из-за процесса согласования «Билета о предоставлении прокси»:

http://rubycas -client.rubyforge.org / файлы / README_txt.html (прокрутите вниз до раздела «Как действовать как прокси-сервер CAS» примерно на 2/3 вниз)

Answer 2

Похоже, я могу просить CAS сделать больше, чем он способен. Я думал об этом как о механизме единого входа, где данный сеанс может быть передан так, чтобы аутентификация происходила только один раз. Вместо этого кажется, что CAS изначально ориентирован на централизованную аутентификационную службу (да, я вижу иронию в том, что на самом деле это аббревиатура) Передавая запросы аутентификации на центральный сервер, этот сервер может прочитать один файл cookie. Таким образом, соединения без сохранения состояния, такие как API, не могут быть проверены таким образом.

Похоже, что прокси-билеты CAS могут дать надежду, но я пока не готов идти по этому пути.