Аутентификация с помощью "дочернего" приложения через CAS

112
14

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


UPDATE


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

спросил(а) 2021-01-19T12:57:14+03:00 9 месяцев назад
1
Решение
65

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


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


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

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


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

ответил(а) 2021-01-19T12:57:14+03:00 9 месяцев назад
46

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

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

ответил(а) 2021-01-19T12:57:14+03:00 9 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема