Это основано на моем опыте:
Единый вход (SSO) связан с двумя сценариями:
я) я вас очень хорошо знаю (участвуют две стороны)
ii) Эй, друг, познакомься с моим другом (участвуют три стороны)
Итак, для второго сценария необходим механизм перенаправления / пересылки, потому что обычно третьим лицом является только централизованная служба аутентификации / авторизации.
Теперь, с точки зрения реализации, SSO требует две области для оценки: -
a) как разные стороны / системы (внутренние или внешние по отношению к рассматриваемой организации) управляют учетными данными пользователей. Это называется управлением идентификацией.
б) как информация SSO должна передаваться между сторонами? Конечно, в большинстве сценариев.
Я думаю, что управление идентификацией является более важным, чем определение способа передачи информации на секретной основе, поскольку для последней части существует множество методов шифрования / дешифрования. Это управление неопределенностью, которое однозначно отличается в одном наборе систем с поддержкой единого входа.
Теперь управление идентификацией может быть реализовано с помощью простого идентификатора пользователя (если он доступен во всех участвующих системах), либо с помощью собственного содержимого XML, либо полезной нагрузки SAML, либо стороннего токена. Я думаю, что токен - это просто общий термин, относящийся к контейнеру, содержащему защищенные учетные данные пользователя, а также информацию о некоторых выполненных процедурах безопасности.
@ Оле, сказав все выше об основах единого входа (с моей точки зрения), я думаю, вам следует больше сконцентрироваться на том, как пользователи и их роли идентифицируются в нескольких системах, т.е. в вашем случае: - магазин ваших пользователей, открытый поставщик outh2 ; так что больше думайте об управлении идентификацией.
Одним из решений может быть (в зависимости от вашего бюджета и времени), что ваше предприятие может потратить усилия на создание собственного централизованного интерфейса аутентификации в форме стандартных технологий интеграции, например. веб-сервис и за этим API, вы можете иметь любую реализацию: ваш собственный провайдер или сторонний oAuth или оба из них. Вы можете реализовать уровень движка между вашим API и уровнем провайдера, который принимает решения. Например, Движок может иметь домен приложения и соответствующее отображение провайдера аутентификации.
Таким образом, вы получите единый интерфейс аутентификации для всех своих клиентов.
Клиент -> Внутренний централизованный API -> Engine -> Auth провайдера (ов)
позвольте мне привести пример:
i) вы можете получить доступ к веб-сервису, имя которого может быть singleSigonService. Полезная нагрузка XML может быть такой: -
<SingleSignOnReqType> <sourceID>XYZ</sourceID> <source-domain>my-java-app.com</source-domain> <user-credentials>...</<user-credentials>
<security-credentials>...</<security-credentials> </SingleSignOnReqType>
ii) Клиент веб-службы будет выполнять SSO-вызов на уровне централизованного движка (реализованный в любой технологии), который может выполнять валидацию и бухгалтерию и может основываться на исходном домене (например, my-java-app.com) во входящем XML делегировал бы запрос провайдеру Oauth2, такому как facebook-connect. Таким образом, ваш механизм, принимающий решения, будет управлять правилами аутентификации, как вы указали в своем требовании.
Таким образом, в основном все потребительские приложения будут иметь унифицированный интерфейс на основе веб-службы для вашего решения SSO. Это то, что я называю внутренним централизованным API.