Проверить токен ST Apereo CAS в службе REST (без сохранения состояния)

Question

Приношу свои извинения за мой плохой английский sh.

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

Ps: этот API будет доступен по внешнему интерфейсу и службам без внешнего интерфейса, поэтому я не смогу использовать куки.

Диаграмма последовательности, чтобы проиллюстрировать мою идею:

введите описание изображения здесь

Спасибо.

Answer 1

Ваше клиентское приложение должно запросить у CAS-сервера аутентификацию прокси.

Одним из наиболее распространенных случаев использования прокси-аутентификации является возможность получить билет для внутренней службы [на основе REST], которая также защищена CAS. Сценарий обычно таков:

• Пользователь сталкивается с приложением A, которое защищено CAS.
• Приложение A на внутреннем сервере должно связаться со службой S для получения данных.
• Сама служба S защищена самим CAS.

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

Маршрут трассировки может выглядеть следующим образом:

• Браузер переходит на внешний интерфейс.
• Внешний интерфейс перенаправляет на CAS.
• CAS выполняет проверку подлинности и перенаправляет обратно на внешний интерфейс с помощью ST.
• Внешние попытки проверяет ST и запрашивает PGT.
• CAS подтверждает проверку ST и выдает билет PGT с предоставлением прокси-сервера.
• Front-end просит CAS создать PT для внутреннего API , предоставляя PGT в своем запросе.
• CAS создает PT для внутреннего интерфейса API.
• Внешний интерфейс связывается с конечной точкой службы S, передавая PT в запросе.
• backend API пытается проверить PT через CAS.
• CAS проверяет PT и выдает успешный ответ.
• Backend API получает ответ и создает данные для внешнего интерфейса.
• A получает и отображает данные в Электронный браузер.

Подробнее см. .