У меня есть система, в которой я запускаю приложения, написанные на смеси Java и другого языка, и я ищу, чтобы был единый сеанс входа в систему приложения.
Под одним сеансом входа в систему я имею в виду
- Single Sign on
- Если сеанс активен, возможность беспрепятственного доступа к любой услуге
- Выход из одного приложения сделает недействительным сеанс для других сеансов
- Сессии будут иметь скользящее время ожидания экспорта и абсолютное время ожидания
- Активность в любом приложении будет поддерживать сеанс для любого другого приложения.
В настоящее время я использую CAS в качестве решения для единого входа.
Судя по моим исследованиям, CAS не предоставляет один сеанс. Хотя он имеет сеанс в форме TGT, этот сеанс является внутренним для приложений и не предназначен для использования клиентскими приложениями.
Если бы все приложения были на Java, то я мог бы использовать Spring Sessions, поддерживаемые чем-то вроде Redis, для достижения целей.
Однако некоторые из моих приложений написаны на других языках, поэтому я не смогу использовать сеансы Java.
У меня есть пара идей для решения
a) Используйте CAS и каким-то образом используйте сеанс TGT. Глядя на /7272919/tgt-istekaet-esli-my-ispolzuem-app1-i-ne-ispolzuem-drugie, кажется, что это будет трудно сделать.
b) Используйте CAS и используйте прокси PGT для получения доступа к TGT более контролируемым образом. Я не очень задумывался о том, дает ли это мне то, что я хочу, с точки зрения поддержания сеанса с помощью активности.
c) Использовать готовый механизм сеансов сторон, который предоставляет мне API для создания / расширения и завершения сеансов, а также записи хуков на каждом языке для использования этого сеанса. К сожалению, я не нашел такого механизма.
d) Использовать сеансы Java, а для приложений, не относящихся к Java, написать API, который позволяет проверять идентификатор JSESSION, и записать хуки на язык, отличный от JAVA, для чтения файла cookie JSESSION и выполнения вызовов API. Эффективно использовать Spring Sessions для написания собственной версии c)
e) Написать обратный прокси-сервер на Java для не-Java-приложений, который проверяет сеанс, а затем вызывает фактическую конечную точку http, добавляя заголовки, которые содержат информацию о сеансе (например, как JWT). Запишите в приложении хуки для чтения этих JWT и проверки их (например, с помощью HMAC).
Буду признателен за любой вклад в перечисленные выше варианты, поскольку я не нашел четкого решения вышеуказанных проблем при поиске в SO или Интернете.