Подтвердить что ты не робот

Единый вход в систему [SSO] в разных доменах с использованием Java

Мы реализуем Single Sign On [SSO] для нескольких приложений, которые размещаются на разных доменах и разных серверах.

enter image description here

Теперь, как показано на рисунке, мы представляем Authenticate Server, который фактически взаимодействует с LDAP и аутентифицирует пользователей. Приложения, которые будут использоваться/разговаривать с Authenticate Server, размещаются на разных серверах и доменах.

для SSO я не могу использовать переменные сеанса, так как существуют разные серверы и разные приложения, разные домены, переменная cookie/session уровня домена не помогает.

Я ищу лучшее решение, которое можно использовать для SSO через них. Любая продемонстрированная реализация существует? Если да, отправьте его или укажите мне в правильном направлении.

4b9b3361

ОТВЕТЫ

Ответ 1

Вы можете добиться этого, выполнив все ваши логины на сервере auth. Другие приложения могут связываться с сервером auth через обратный канал. Общий принцип таков:

  • Пользователь обращается к приложению 1.
  • Приложению 1 требуется, чтобы пользователь выполнил вход, поэтому он отправляет токен серверу auth через обратный канал. Приложение 1 затем перенаправляет пользователя на страницу входа на сервере auth с токеном в качестве параметра в запросе.
  • Пользователь регистрируется на сервере auth. Сервер Auth устанавливает cookie, помещает маркер как аутентифицированный и связывает с ним данные пользователя. Затем сервер Auth перенаправляет пользователя обратно в приложение 1.
  • Приложение 1 получает запрос от пользователя и вызывает сервер auth server over back, чтобы проверить, соответствует ли токен. Ответ сервера Auth с данными пользователя.
  • Приложение 1 теперь знает, что пользователь авторизован и имеет некоторые основные пользовательские данные.

Теперь это бит бит SSO:

  1. Пользователь обращается к приложению 2.
  2. Приложение 2 требует, чтобы пользователь выполнил вход, поэтому он отправляет токен серверу auth через обратный канал. Приложение 2 затем перенаправляет пользователя на страницу входа на сервере auth с токеном в качестве параметра в запросе.
  3. Сервер Auth видит, что существует допустимый файл cookie, поэтому он может сказать, что пользователь уже прошел аутентификацию и знает, кто он. Сервер Auth маркирует токен как аутентифицированный и связывает с ним данные пользователя. Затем сервер Auth перенаправляет пользователя обратно в приложение 2.
  4. Приложение 2 получает запрос от пользователя и вызывает сервер auth server over back, чтобы проверить, соответствует ли токен. Ответ сервера Auth с данными пользователя.
  5. Приложение 2 теперь знает, что пользователь авторизован и имеет некоторые основные пользовательские данные.

Существуют некоторые существующие реализации этого метода, например CAS (Служба централизованной аутентификации). Обратите внимание, что CAS поддерживается из Spring Безопасность. Я бы посоветовал вам взглянуть на использование существующей реализации, поскольку писать ваши собственные будет сложно. У меня есть упрощенные вещи в моем ответе, и есть много возможностей для внедрения дыр в безопасности, если вы новичок в этом.

Ответ 2

Я порекомендую вам проверить OAuth. Это хороший протокол аутентификации и авторизации, используемый несколькими крупными организациями, включая facebook, google, windows live и другие. Он может иметь начальную кривую обучения, но это решение производственного класса.

Он также имеет библиотеки для Java, Ruby, PHP и ряда других языков программирования.

Например, для Java доступны следующие реализации на стороне сервера.

  • Apache Amber (черновик 22)
  • Spring Безопасность для OAuth
  • Сервер авторизации Apis (v2-31)
  • Restlet Framework (проект 30)
  • Apache CXF

Доступны следующие библиотеки Java на стороне клиента:

  • Apache Amber (черновик 22)
  • Spring Социальные
  • Spring Безопасность для OAuth
  • Restlet Framework (проект 30)

Подробнее см. здесь:

Ответ 3

Больший вопрос заключается в том, как вы реализуете единый вход. Многие предложения с открытым исходным кодом и даже фирменные (IBM Tivoli), которые стоят на их солевом рынке, предлагают возможность междоменного единого входа. Это был бы самый простой и эффективный способ реализации перекрестного домена sso. Вы можете настроить сервер LDAP, который вы используете на выбранном сервере sso.

Взяв, например, open sso, вот статья для настройки единого знака перекрестного домена  http://docs.oracle.com/cd/E19681-01/820-5816/aeabl/index.html

Чтобы настроить LDAP в open sso,  http://docs.oracle.com/cd/E19316-01/820-3886/ghtmw/index.html

Ссылка на вопрос приведена на аккуратной диаграмме здесь  http://docs.oracle.com/cd/E19575-01/820-3746/gipjl/index.html

В зависимости от того, какое предложение вы используете, вы можете настроить однополярный одноранговый домен.

При этом ваша диаграмма будет выглядеть так: сервер auth будет вашей утилитой для взаимодействия с sso-сервером по вашему выбору.

Наличие сервера auth, который связывается с sso, является принципом звуковой архитектуры. Я бы предложил сделать вызовы для аутентификации как конечные точки REst, которые можно было бы вызвать через http из разных приложений.

Cross Domain single sign on

Ответ 4

Вы не можете использовать Rest Service.

Вы можете использовать то, что я называю аутентификацией Refferer Url Authentication Скажем, у вас есть приложение для проверки подлинности, запущенное на сайте www.AAAA.com В приложениях, где требуется аутентификация, you could have a filter which looks for a authenticated cookie in its domain else redirect to www.AAAA.com for authentication

В Successfull authentication вы можете pass the user profile information as encrypted GET / POST data back to the application