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