SSO, неизвестное

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

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

В некотором смысле эта четвертая успокаивающая вещь уже выполняет, по крайней мере, половину требуемой работы.

Теперь нам нужно разрешить пользователям входить в webapp A, а затем следовать по ссылке (или просто набирать ее url) в webapp B (или просто набирать URL-адрес) и добираться там уже в журнале (или наоборот).

Я много читал о CAS и openID или даже оауте, но на самом деле не могу понять это. Является ли этот шаблон централизованным? Децентрализованные?

Мой взгляд в десять тысяч футов предполагает, что мне как-то просто нужно добавить эту "недостающую функцию" на наш спокойный сервер api.

Но как?

ps: эти 3 полностью разделены. развернуты на разных машинах (2 из них работают на стеклянной рыбке, другая работает на котле). разные домены.

pps: все они основаны на пружинах webapps (следовательно, они используют Spring -Security)

ppps: на сегодняшний день существуют другие webapps, использующие наш restul api (non spring, non java). это решение sso должно быть готово к тому, чтобы справиться с ними.

+1
источник поделиться
2 ответа

Да, похоже, вам нужен "истинный" единый знак в системе, а не только централизованный репозиторий учетных данных. Как вы упомянули, есть несколько вариантов:

  1. OpenId - больше подходит для приложения типа интернет, в котором вы хотите разрешить пользователям входить в ваши системы с учетными данными, которые поддерживаются третьей стороной. Stackoverflow - классический пример. Вы можете войти в свою учетную запись google и т.д.

  2. Oauth обеспечивает псевдо аутентификацию и sso, тогда как OpenId говорит: "Это пользователь x". Oauth говорит, что "у этого пользователя есть доступ к информации x"... поэтому вы можете предположить, что пользователь x.

  3. CAS, Cloudsal, OpenAM и т.д. Обеспечивают единый вход и подходят для среды интрасети или экстрасети. CAS и Cloudsal имеют особенно хорошую поддержку Spring.

+4
источник
  • Надежный сайт (полагающаяся сторона (RP) в белом списке - приложение a, b, c в вашем случае) делает запрос (перенаправление) на главный сайт (поставщик - "четвертое отдельное приложение") с обратным адресом.
  • Основной сайт убедитесь, что запрос (returnURL) - из белого списка доменов
  • Зарегистрировать пользователя (если он не зарегистрирован, отображающий форму входа), пометить пользователя как зарегистрированную в базе данных и добавить временный токен в пользовательскую базу данных.
  • Возврат основного сайта (перенаправление) на RP с помощью токена.
  • RP загляните в базу данных, используя токен, регистрирует пользователя и удаляет токен.

SSOff также легко: просто проверьте каждый запрос в пользовательской базе данных на запись bool (userLogged). НЕТ ПЕРЕДАЧ. При выходе из системы просто измените запись (userLogged) на false, и каждый сайт узнает.

0
источник

Посмотрите другие вопросы по меткам или Задайте вопрос