Ответ 1
Вы интегрируете существующие приложения или хотите просто поддержать свои собственные приложения?
Вы ищете фактическое SSO или просто общие учетные данные? SSO регистрируется в одном приложении и передает этот учет в другое приложение (например, вход в Gmail и автоматическое вхождение в Blogger). Общие учетные данные: вы можете использовать одно и то же имя входа и пароль для всех приложений, но сами учетные данные не распространяются автоматически.
LDAP - это общая система, используемая для управления общими учетными данными. Многие системы позволяют указать свой магазин аутентификации на существующий сервер LDAP.
Например, если у вас было несколько приложений, развернутых в контейнере Java EE, а также, скажем, почтовый сервер и веб-клиент электронной почты, все эти разнообразные приложения можно было указывать на один и тот же сервер LDAP, и ваши пользователи имели бы единый логин и пароль для всех разных систем, все написанные на разных языках, все они развернуты на разных машинах. Это случай использования LDAP с хлебом и маслом, и почти каждая система может справиться с этим из коробки. Glassfish и Tomcat могут с готовностью проверять сервер LDAP. Таким образом, Apache (веб-сервер), Postgres (база данных), Postfix (электронная почта) и т.д. И т.д.
Итак, если вы хотите просто использовать общие учетные данные, вы получаете это "бесплатно" прямо сейчас, установив сервер LDAP. LDAP - это немного другое зверь, чем нечто вроде СУБД, но как только вы немного изучите его и "получите", это действительно очень приятно. OpenLDAP - популярный сервер LDAP, но я неполный к ApacheDS.
Способ установки в контейнере Java EE заключается в настройке "Realm". GF и Tomcat оба имеют диапазоны LDAP из коробки, я думаю, что все остальное. Но орех там, что вам нужно использовать безопасность Java EE для использования Realm.
Смотрите, детали с областью Java EE - это то, что он является контентом, а не приложением. Точно так же, как пул соединений - это ресурс контейнера, который использует ваше приложение. Большинство людей хотят, чтобы безопасность была частью их приложения, где они чувствуют, что у них больше контроля над ним.
Это все хорошо и хорошо, пока вы не начнете получать кучу разных приложений, и все настроены по-разному и имеют отдельные списки пользователей, политики паролей и т.д. и т.д.
LDAP может многое исправить, так как вы все настроите их на использование одного и того же хранилища учетных данных.
Царство заполняет эту потребность на сервере Java EE. Ваше приложение настроено на использование Realm, предоставляемого контейнером. Если у вас есть несколько приложений и одно Realm, то все они получают доступ к учетным данным в пределах этого Realm (независимо от типа Realm).
Области могут быть любыми: файловыми, db-based, LDAP и т.д. Realms также кластер, если кластеры контейнера (что может быть удобно).
Темная сторона безопасности Java EE, и почему большинство приложений избегают этого, поскольку, опять же, Realm является частью контейнера, а не приложением, его можно немного неудобно использовать и, возможно, не предлагать функции, которые вам нравятся с точки зрения управления пользователями, политики паролей и т.д.
Но яркая сторона безопасности Java EE заключается в том, что, когда вы находитесь под ее зонтиком, вы можете легко использовать учетные данные в своем коде. Человек регистрируется на веб-сайте и этот учет может использоваться там в веб-приложении или автоматически распространяется обратно на уровень EJB (когда-либо удаленный EJB-уровень), и информация всегда удобна.
Вы можете указать свои веб-приложения в сфере, EJB, ваших веб-сервисах. Все они используют одни и те же фрагменты.
Чтобы получить лучшее из обоих миров, нужно использовать механизмы, специфичные для контейнеров, для доступа к безопасности контейнеров. Это другая темная сторона безопасности Java EE.
Такие вещи, как Realms и прямой доступ к безопасности контейнера, не переносятся в контейнерах. GF отличается от Tomcat, чем отличается от WebLogic. Все это действительно близко, но отличается деталями, поэтому ваш код не будет загружаться плавно.
Яркая сторона для домашних приложений, большинство людей просто используют контейнер, который у них есть, размещают разумную абстракцию вокруг кода, зависящего от контейнера, и называют его днем, отмечая, что да, им придется переносить это, если и когда они перемещаются в другой контейнер. Но на практике. как база данных, как только платформа контейнера выбрана, люди склонны прижиматься к ней и придерживаться ее.
Наконец, Servlet 3.0 (в GF3 и Tomcat 7) стандартизирует больше проблем входа в систему, чтобы сделать их более переносимыми по контейнерам, но базовые понятия одинаковы.
Теперь, SSO.
SSO - это другой зверь. Но, вне ворот, GF и Tomcat поддерживают SSO для веб-приложений. Это позволяет вам войти в одно веб-приложение и иметь возможность легко обращаться к другим пользователям без необходимости их входа в систему. Но SSO немного ограничено, поскольку он в большей степени зависит от безопасности контейнера и его жизненного цикла, а не от более гибкого управления под управлением приложения. Разум, а не только на Realms (это заданный), а на фактический вход в систему на основе FORM, а не на пользовательский программный логин. FORM логин не впечатляющий, но он функциональный и работает. Внесите Realm, разверните ваши приложения в один экземпляр Tomcat или GF (или кластер в GF 3.1), и вы получите SSO бесплатно, поэтому, если это важно, это действительно приятно. Это удобство использования отлично подходит для приложений для бэк-офиса, но не для общедоступного Интернета.
Если вам требуется более сложное решение SSO, вам нужно посмотреть пользовательские реализации. OpenSSO является одним из них, и он использует веб-профиль SAML и SAML. Однако есть и другие. Там CAS, Atlassian Cloud, Kerberos и OAuth. Все они используют разные протоколы, чем SAML. Если вы хотите придерживаться SAML, вы также можете посмотреть на Shibboleth или даже SimpleSAML (SimpleSAML - это сервер PHP, который, помимо прочего, действует как поставщик SAML Identity, но вам все равно нужен поставщик услуг в ваших приложениях).
Какой бы протокол вы ни выбрали, процесс в основном тот же (подробнее здесь - Вход в кросс-домен - как автоматически войти в систему при переносе из одного домена в другой).
Но дьявол в деталях. И, мальчик, есть ли дьяволы.
Все эти системы сложны. SSO сложнее. Например, теперь, когда у вас есть Single Sign On, как насчет Single Sign Out? Как насчет Единого таймаута? Как насчет учетных данных во время входа в систему? Как насчет STS (Secure Token Service) для ваших веб-сервисов? (STS предлагает аналогичный делегированный механизм аутентификации для веб-сервисов.)
SAML представляет вам много нового словаря и множество настроек. Это нелегко понять, поскольку документация не является звездной и много опирается на документы стандартов, которые говорят на более высоком уровне общих вещей, а не на вас и ваше приложение.
Если вам не нужен действительно SSO, тогда вы, вероятно, будете довольны чем-то вроде центрального хранилища LDAP и продолжаете оттуда.
Все, что говорилось, в качестве примера, наши приложения поддерживают как БД, так и LDAP. Они используют Glassfish и безопасность Java EE. Мы полностью контролируем работу пользователя. Мы также поддерживаем SSO через SAML (мы написали собственные Identity и Service Providers), и у нас есть общие учетные данные через LDAP и SSO через Java и другие приложения, используя наш код и сторонний код. Яркая сторона - это все стандарты. Темная сторона заключается в том, что стандарты передаются на английском языке, а английский язык подлежит интерпретации.
Я говорю это просто, чтобы сказать, что это можно сделать. Я также написал ad hoc, обратно из реализаций SSO салфеток, как одного домена, так и перекрестного домена (тот же самый домен с общим файлом cookie), используя простые фильтры сервлетов. Политики паролей, восстановление пароля, сохранение таймеров, кратковременное переключение окон и управление сеансом (это крик), роли, привилегии и т.д. И т.д. Был там, сделал это.
Кроме того, я бы отказался не упоминать Spring и Spring Security, которая предлагает все это поверх Spring. Я не использовал его (я не человек Spring), но эти люди знают, что делают, поэтому стоит посмотреть.