Простой центральный сервис аутентификации — навигация между сервисами
У меня есть несколько сервисов, доступных в разных доменах, каждый со своими пользовательскими таблицами.
Я работаю над внедрением простой унифицированной системы аутентификации и единого входа.
До сих пор я разработал рабочий процесс, чтобы заставить пользователей зарегистрироваться / войти в систему на странице CAS и перенаправить их на выбранную службу вместе с кодом авторизации.
Затем служба обменивает код на access_token и получает информацию о пользователе, создает / обновляет пользователя и регистрирует их.
Я хочу разрешить пользователям переходить между службами после проверки подлинности для одной из служб.
Цель состоит в том, чтобы предложить плавную навигацию между несколькими службами.
Когда пользователь переходит к другому сервису, очевидно, что сервис должен будет выполнить свою собственную транзакцию авторизации с сервером CAS, хотя и не уверен, как будет выглядеть природа этой транзакции.
Как создать перекрестную одинаковую навигацию между службами между службами, когда все службы используют центральную службу проверки подлинности и единый вход.
Решение
Если все ваши службы интегрированы с CAS, каждая служба должна связаться с CAS, чтобы получить какой-либо токен / билет, а затем попросить CAS подтвердить его, чтобы получить профиль пользователя. Фактический акт аутентификации выполняется только один раз, чтобы CAS мог установить сеанс единого входа, но задача получения и проверки заявок обычно выполняется по одному на приложение, когда приложение решает аутентифицировать пользователя (потому что его сеанс истекает и т. Д.).
Одна и та же концепция работает более или менее одинаково независимо от протокола аутентификации. (OAuth, CAS и т. Д.). Это более или менее предполагает, что ваши сервисы доступны через Интернет, где задействован браузер. Если у вас есть сервисы, проксирующие другие серверные сервисы, то это же решение будет немного сложнее.
Другие решения
Других решений пока нет …