Альтернативы OpenSSO/OpenAM

Внимание! Я здесь немного рыбалка, и я даже не уверен, что вопросы, которые я задаю, имеют смысл. Пожалуйста, будьте любезны с вашими ответами!:)

Недавно я взял на себя проект, который в настоящее время основан на Java + Linux + Tomcat + MySQL. В настоящее время система - это всего лишь веб-сайт с несколькими рабочими местами cron на заднем плане, чтобы перемещать некоторые данные и т.д. При работе с менеджером продукта для разработки приоритетного отставания его четкое из того, что он хочет сделать, что я необходимо начать разработку сервис-ориентированной архитектуры (SOA < - buzz word warning!), и я получаю сочетание веб-серверов и серверов приложений. Примечание: Im решительно рассматривает возможность перехода на Glassfish v3.

В настоящее время аутентификация и авторизация обрабатываются в Java-коде с информацией о пользователе, хранящейся в базе данных MySQL. Как минимум, мне кажется, что мне нужно разделить это на отдельную службу аутентификации (в противном случае в результате будет дублироваться дублированный код для обработки аутентификации и авторизации пользователей).

Я изучал решения типа единого входа (SSO) и делал некоторые исследования. Из того, что я могу собрать, OpenSSO официально был отброшен Oracle, но подхватил ForgeRock и теперь называется OpenAM. Это кажется очень близким к тому, что я хочу, но поскольку у меня уже есть система на основе MySQL, я бы предпочел иметь что-то, что ее поддерживает (или какой-то другой вид РСУБД). Я нашел это в Qaru и, похоже, указывает, что его в основном LDAP или ничего.

Есть ли способ открыть OpenSSO/OpenAM для базы данных для его аутентификации и авторизации?

Мои вопросы:

Какие еще варианты доступны для OpenSSO/OpenAM? Является ли LDAP способом? Примечание: поиск "OpenAM vs" google не дает многого. Люди склонны просто "сворачивать"?

Любые мысли/предложения/ссылки по этой теме, которые помогут воспитывать меня, будут очень признательны. Заранее благодарю за ваше терпение и помощь.

ОТВЕТЫ

Ответ 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), но эти люди знают, что делают, поэтому стоит посмотреть.

Ответ 2

Обратите внимание, что "Есть ли способ сделать OpenSSO/OpenAM для работы с базой данных для его аутентификации и авторизации?" неправильно сформулирован. Вопросы и ответы на вопрос касаются только аспекта авторизации. OpenAM отлично работает с базой данных MySQL для пользователей и паролей (аутентификация) и может использовать скрытый/встроенный LDAP-сервер для хранения политик и других параметров.

Похоже, вам по-прежнему нужно создать свою модель безопасности, но вы, скорее всего, найдете, что вам совсем не нужно что-то вроде OpenAM, и можете просто использовать безопасность контейнеров/фреймов.

Ответ 4

OpenAM имеет два отдельных магазина: хранилище пользователей, где хранятся пользователи и все сопутствующие свойства, и хранилище конфигурации, в котором содержится конфигурация. Существует хранилище пользователей базы данных, которое доступно в OpenAM, но я никогда не пробовал. Вопрос SO, на который вы указывали, ссылался в первую очередь на хранилище конфигураций, которое при использовании только LDAP встроено в OpenAM (поэтому не требует прямого управления).

Лично я являюсь поклонником Tomcat над Glassfish, так как это быстрый и легкий контейнер Servlet, без всякого связанного раздувания, которое идет с полным контейнером J2EE.

Ответ 5

Вы можете использовать OpenAm с RDBM. Я использую хранилище пользователей на основе JBDC в OpenAm

Ответ 7

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

  • Ваша основная точка входа должна расширять com.sun.identity.idm.IdRepo.
  • Вам необходимо зарегистрировать свой собственный репозиторий, используя ssoadm.jsp? cmd = add-sub-schema.

С этого момента ваш тип репозитория будет указан среди других типов при создании хранилища данных для области.

Удачи!