Как объединить Single Sign Off и безгражданую аутентификацию

Question

Я пытаюсь добавить решение на основе единого входа/единого входа на основе SAML, позволяющее смешанной экосистеме веб-приложений придать конечному пользователю впечатление, что они взаимодействуют с одним приложением.

Стандартным подходом к этому, как представляется, является то, что IdP управляет аутентификацией пользователя (которая устанавливает сеанс IdP), а затем по мере необходимости выдает подписанный знак SAML на запросы для установления сеанса в каждом компонентном приложении.

Выйти можно с помощью SAML Single Sign Off, где при выводе IdP выдает обратный вызов канала каждому поставщику услуг, чтобы аннулировать сеанс.

Это отлично подходит для традиционных приложений, основанных на сеансах, но я пытаюсь выяснить, как мы интегрируем приложения, использующие токен JWT без имени, вместо сеанса на стороне сервера.

Знак на куске работает эквивалентно, мы просто выдаем JWT в ответ на знак SAML вместо того, чтобы устанавливать традиционную сессию. Выход из одной службы является практичным, просто удалив файл cookie.

Но есть ли способ достичь единого выхода? Единственный подход, который я вижу:

• Хост все лица без приложения на том же домене (или на LEST поддоменов)
• на сайт-аут, удалить все лица без куки аутентификации для этого домена, а не только один для индивидуальной заявки
• После очистки этих файлов cookie активируйте поток единого входа SAML для работы с приложениями statefull.

Есть ли более стандартный подход к этому или это всегда ручная работа?

В моих исследованиях я столкнулся с большим количеством использования токенов без гражданства для единого входа и регистрации использования единого знака из полностью заполненных приложений, используя либо домашний рост, либо стандарты, такие как SAML Sign Off. Но я не могу найти ничего более простого или более стандартного, чем то, что я описал для объединения двух в смешанной среде.

Ссылки:

• Single sign off using OAuth 2 - в то время как злоупотребление OAuth, аналогичная ситуация с тем, что я описываю, но решается за счет создания на стороне сервера для проверки состояния OAuth маркеров для достижения знака от
• Transparent user session over several sites (single sign-on + single sign-off) & How to do stateless (session-less) & cookie-less authentication? хорошо описывают тип потока аутентификации без учета состояния, который я очень хочу включить, но, похоже, полагаются либо на хранилище токенов, либо на общий сервер, либо просто полагаются на тайм-аут, а не на точный вывод

Answer 1

1 - Как провайдер идентификации пусть целевые приложения знают, что они не должны позволять пользователю войти в

В SAML это достигается с помощью единого Выход (SLO), который формализуется в протоколе. IdP может отправить сообщение SLO в целевое приложение, и целевое приложение может принять меры.Это подводит нас к

2 - Как целевое приложение не позволяет пользователю войти в при представлении с «действительным» JWT лексемами

Когда приложение генерирует маркер JWT, он должен сделать это в таком чтобы он мог отозвать этот токен позже. Практически это означает отслеживание выпущенных токенов через уникальный идентификатор, такой как JWT ID (jti). Если приложение генерирует токены, обратившись к третьему лицу, ответственному за управление этими токенами, вы надеетесь/настаиваете на том, что сторонний маркер-маркер предоставляет способ отменить токен.

Если заявка (или сторонний эмитент) не может отозвать токен, то вы все равно можете добиться этого, если истекают токены. Это решение недействительности маркера вашего бедняка.