Статья адресована архитекторам и техническим руководителям, которые используют PingAM 7.5 и рассматривают переход на OpenAM — систему управления доступом с открытым исходным кодом, которую сообщество Open Identity Platform развивает под открытой лицензией CDDL.
Это не пошаговая инструкция, а обзор миграции на уровне архитектуры и планирования, который помогает оценить объём и состав работ.
В статье разберём следующие моменты:
Пошаговые руководства по отдельным частям миграции выйдут в следующих постах — их список в конце статьи.
Основные причины миграции редко бывают техническими:
Лицензирование. PingAM распространяется только по подписке: бесплатно его можно использовать лишь для разработки и тестирования, а для промышленной эксплуатации нужна платная лицензия. Руководство Ping по лицензированию считает самостоятельно развёртываемое ПО, включая PingAM, по числу хранимых объектов: учитывается каждый пользователь, устройство или другой объект в хранилище, даже если он давно неактивен. Поэтому объём лицензии растёт вместе с хранилищем, а не с реальной нагрузкой. Сильнее всего это бьёт по инсталляциям с большим числом редко используемых учётных записей — например, по государственным сервисам для граждан.
Обновление до PingAM 8 — тоже миграция. ForgeRock объявила цепочки и модули аутентификации устаревшими ещё в AM 7.0, а Ping удалил их в PingAM 8.0. Если ваши процессы аутентификации построены на цепочках, при обновлении до PingAM 8 их придётся перестроить в деревья, то есть спроектировать аутентификацию заново. В OpenAM те же цепочки переносятся механически — об этом ниже. Откладывать решение надолго не получится: по трекеру Ping обновления и стандартная поддержка PingAM 7.5 заканчиваются в апреле 2027 года.
Контроль над кодом. Бинарная поставка и договор поддержки закрывают большую часть потребностей. PingAM можно расширять собственными узлами, плагинами и скриптами, но изменять и декомпилировать сам продукт запрещает соглашение о подписке Ping. Если ошибка или ограничение находятся в ядре, остаётся ждать исправления от производителя. OpenAM выпускается под лицензией CDDL, код расположен на GitHub, так что его можно самостоятельно править и развивать совместно с сообществом, а при разработке собственных расширений — опираться на исходный код ядра.
Open Identity Platform OpenAM и PingAM выросли из одного продукта, ForgeRock OpenAM, и у них общая исходная кодовая база. Последний общий публичный исходный код под CDDL вышел в 2016 году; сообщество Open Identity Platform продолжило развитие и поддержку на GitHub, под той же лицензией. ForgeRock развивала свою ветку как ForgeRock AM; в 2023 году Thoma Bravo купила ForgeRock и объединила её с Ping Identity, а годом позже AM стал PingAM.
После разделения развитие продуктов пошло в разных направлениях. В PingAM добавлены деревья и узлы аутентификации. Разошёлся и инструментарий настройки: Amster и файловая конфигурация в PingAM, ssoadm и REST API в OpenAM. OpenAM остался на модулях и цепочках аутентификации и развивал их: в поставке тридцать два документированных типа модулей аутентификации. Сервисы федерации по протоколам OAuth 2.0, OpenID Connect, SAML 2.0 и движок политик авторизации в основе остались общими, но в PingAM к ним добавились расширения, которых в OpenAM нет, — например, CIBA, PAR, обмен токенов и транзакционная авторизация. Они собраны в отдельной строке таблицы ниже.
Скачать дистрибутивы и ознакомиться с документацией по самостоятельной сборке можно на странице OpenAM. Если AM не единственный продукт в вашей инфраструктуре, остальная часть экосистемы — OpenDJ, OpenIDM, OpenIG и OpenICF — сопоставлена с продуктами ForgeRock на отдельной странице сайта Open Identity Platform.
Прежде всего выясните, как у вас настроены процессы аутентификации. PingAM 7.5 поддерживает обе модели: модули, собранные в цепочки, и деревья, собранные из узлов.
Если вы всё ещё используете цепочки аутентификации, процесс переносится один в один. Модуль остаётся модулем, цепочка — цепочкой, управляющие флаги REQUIRED, REQUISITE, SUFFICIENT, OPTIONAL ведут себя идентично. Наборы модулей совпадают не полностью: сверьте каждый используемый тип модуля со справочником модулей OpenAM. Конфигурацию всё равно придётся переносить руками, но в этом случае вы только механически переносите настройки, а не проектируете процессы аутентификации заново.
Если вы используете деревья аутентификации, процессы придётся проектировать заново. Дерево — это граф: каждый узел завершается одним из нескольких исходов, и граф решает, что выполняется дальше. Цепочка — это список, который выполняется по порядку. Ветвление, которое дерево определяло своей структурой, должно переехать в другое место — в скриптовый модуль или в отдельные цепочки. Скрипты тоже не переносятся: скрипт узла работает с nodeState и задаёт именованный исход через переменную outcome или объект action, а скриптовый модуль OpenAM работает с authState и выставляет его в SUCCESS или FAILED.
В таблице ниже возможности PingAM разобраны по компонентам. Второй столбец говорит о том, есть ли в OpenAM аналог: ✅ — есть, ⛔️ — нет. Наличие аналога ещё не означает механического переноса — характер работ показывает столбец трудоёмкости. Он описывает относительный уровень трудозатрат: Низкая — механический перенос, Средняя — перенос плюс повторное согласование или тестирование, Высокая — проектирование и реализация заново.
| PingAM 7.5 | OpenAM | Как переносится | Трудоёмкость |
|---|---|---|---|
| Модули и цепочки аутентификации | ✅ документация | Создаются заново вручную. Модули, которые есть в обоих продуктах, управляющие флаги и порядок ведут себя так же. Наборы модулей совпадают не полностью — сверьте каждый тип со справочником. | Низкая |
| Деревья и узлы аутентификации | ⛔️ | Перестраиваются в цепочки. Ветвление уходит в скриптовый модуль или в отдельные цепочки, выбираемые по запросу. | Высокая |
| Собственные Java-узлы аутентификации | ⛔️ | Переписываются под SPI аутентификации OpenAM. | Высокая |
| Скрипты Scripted модуля аутентификации | ✅ документация | Привязки authState, sharedState, httpClient и idRepository те же, но скрипты придётся править и тестировать заново. Добавьте в белый список классов контекста AUTHENTICATION_SERVER_SIDE пакеты org.forgerock.http.protocol.* и org.forgerock.util.promise.*, иначе HTTP-вызовы через httpClient.send() не работают. OpenAM использует Groovy 2.4, так что синтаксис Groovy 3 придётся переписать, а привязок systemEnv и scriptName в OpenAM нет. |
Средняя |
| Скрипты узлов Scripted Decision | ⛔️ | Переписываются. Для nodeState и именованных исходов аналога нет. |
Высокая |
| Хранилище учётных записей (PingDS, AD, другой LDAP) | ✅ документация | Настройте репозиторий учётных записей OpenAM на хранилище, которое у вас уже работает. Для PingDS выберите тип OpenDJ — его же рекомендует документация PingAM 7.5. С типом Generic LDAPv3 OpenAM молча перестанет читать и записывать атрибуты, которых нет в его стандартном списке: счётчики блокировок, профили OATH и Push, постоянные NameID SAML. Для LDAPS в OpenAM по умолчанию выбран устаревший TLSv1 — поменяйте его на TLSv1.2. Переносить данные не нужно, но OpenAM будет писать в те же учётные записи: профили устройств двухфакторной аутентификации и, если включена блокировка, её атрибуты. Это важно для отката (см. «Устройства двухфакторной аутентификации»). | Низкая |
| Хранилище конфигурации | ✅ | Автоматизированного импорта нет. Хранилище создаёт установщик OpenAM — во встроенном или во внешнем OpenDJ. Его содержимое — реалмы, политики, клиенты — учтено в строках ниже. Отдельно настраиваются серверы и сайты, а для внешнего хранилища — ещё и репликация. | Низкая |
| Реалмы | ✅ документация | ssoadm create-realm, затем сервисы каждого реалма. |
Низкая |
| Политики и наборы политик | ✅ документация | Создаются заново. Модель та же — наборы политик, субъекты, условия, типы ресурсов. Условия Transaction в OpenAM нет (см. строку о расширениях ниже). | Средняя |
| Сервисы и клиенты OAuth 2.0 и OIDC | ✅ OAuth 2.0, OIDC | Регистрируются заново. Это относится к стандартным потокам — authorization code (в том числе с PKCE), implicit и гибридным потокам OpenID Connect, resource owner password, client credentials, refresh token, device flow, JWT bearer и SAML 2.0 bearer — и способам аутентификации клиентов client_secret_basic, client_secret_post и private_key_jwt. Скрипты проверки и вычисления scope переписываются в Java-плагин ScopeValidator. |
Средняя |
| Расширения OAuth 2.0, OIDC и политик | ⛔️ | В OpenAM нет CIBA, PAR, JAR и JARM, обмена токенов (RFC 8693), mTLS-аутентификации клиентов и привязанных к сертификату токенов (RFC 8705), OIDC Back-Channel Logout, Macaroons, удалённого сервиса согласия, условия Transaction в политиках и выдачи scope через движок политик. Приложения и политики, которые на них опираются, придётся перестраивать под поддерживаемые потоки и условия. Транзакционная авторизация в PingAM к тому же опирается на деревья. | Высокая |
| Сущности SAML 2.0 и круги доверия | ✅ документация | Метаданные импортируются заново, сопоставление атрибутов настраивается заново. Если entity ID, URL конечных точек или сертификаты подписи меняются, партнёрам понадобятся ваши новые метаданные. | Средняя |
| Веб-агенты и Java-агенты | ✅ документация | Агенты Ping с OpenAM не работают. Создайте профили агентов в OpenAM заново, а при переключении группы приложений замените агенты Ping на веб-агенты или Java EE-агенты OpenAM либо на OpenIG. | Средняя |
| Хранилища секретов | ⛔️ | Слоя хранилищ секретов в OpenAM нет — каждый идентификатор секрета разрешается в псевдоним в keystore. Ротации через сопоставления секретов, когда одному идентификатору соответствует несколько псевдонимов, тоже нет: ключ меняют заменой в keystore. Если возможно, импортируйте существующие пары ключей. | Средняя |
| Сессии в CTS | ✅ документация | Не переносятся. После миграции на OpenAM пользователи аутентифицируются заново. | Низкая |
| Собственные репозитории учётных записей и плагины | ✅ документация | Требуется адаптировать под API OpenAM и пересобрать: SPI те же, но имена пакетов и сигнатуры могли измениться. | Высокая |
| Страницы для конечных пользователей | ✅ документация | Требуется разработать интерфейс заново. | Средняя |
В пяти строках таблицы стоит ⛔️. Для деревьев, собственных узлов и скриптов узлов аналога в OpenAM нет, и их придётся проектировать и писать заново. Расширения OAuth 2.0, OIDC и политик без аналога потребуют доработки приложений, а ротацию через хранилища секретов заменит смена ключей в keystore. Но и там, где аналог есть, переносится не всё: действующие токены, зашифрованные значения и часть регистраций устройств двухфакторной аутентификации при переезде теряются, а ключи и адреса сохраняются, только если заранее так решить.
Действующие токены. Строка про CTS отмечена как низкая трудоёмкость, потому что перестраивать нечего: пользователи просто должны аутентифицироваться заново. Но в CTS лежат не только сессии. Там же лежат refresh-токены OAuth 2.0. После миграции все выданные refresh-токены перестанут работать. Для браузерного приложения это та же страница входа, которую и так вызвала бы потеря сессии. Мобильные приложения тоже попросят пользователей войти заново, хотя обычно refresh-токен избавляет от этого на недели и месяцы. Такая ситуация может вызвать нагрузку на поддержку, и команда, которая будет принимать обращения пользователей, должна узнать о ней заранее.
Зашифрованные значения. Обычный экспорт Amster вообще не содержит паролей. Зашифрованные пароли появляются, только если предварительно установить транспортный ключ, и расшифровываются они только обратно в AM. Так или иначе экспорт даёт список нужных вам секретов, а не сами секреты: пароли подключения к хранилищам данных, пароли агентов, секреты клиентов OAuth 2.0, учётные данные для почты. Каждый пароль или секрет придётся взять оттуда, откуда он изначально пришёл, либо сбросить, — а сброс секрета клиента означает, что нужно найти владельца этого клиента и согласовать с ним сброс.
Устройства двухфакторной аутентификации. PingAM хранит зарегистрированные устройства в профиле пользователя: OATH — в атрибуте oathDeviceProfiles, Push — в pushDeviceProfiles, WebAuthn — в webauthnDeviceProfiles. Модули Authenticator (OATH) и Authenticator (Push) в OpenAM по умолчанию читают те же атрибуты, так что OpenAM, подключённый к тому же хранилищу, эти устройства видит — если репозиторий учётных записей настроен с типом OpenDJ, а не Generic LDAPv3. Отдельный старый модуль OATH для этого не подходит: он берёт секрет из собственного атрибута, который по умолчанию не задан, и oathDeviceProfiles не читает. Но даже устройства OATH и Push переезжают не целиком. Коды восстановления PingAM хранит в виде одностороннего хеша (в документации Ping это называется one-way encryption), а OpenAM сравнивает введённый код с сохранённым напрямую, поэтому старые коды не подойдут и пользователям придётся выдать новые. Если в PingAM включено шифрование профилей устройств (по умолчанию оно выключено), в OpenAM нужно выбрать ту же схему шифрования и импортировать ту же пару ключей. Push-устройство вдобавок привязано к серверу: адрес, на который приложение отправляет подтверждения, оно получило из QR-кода при регистрации, а уведомления ему доставляет служба push-уведомлений, настроенная в PingAM. Если адрес изменится или OpenAM не сможет пользоваться той же службой, Push-устройства придётся регистрировать заново. Устройства WebAuthn придётся регистрировать заново в любом случае: OpenAM хранит их ключи в другом атрибуте и в своём формате. И предупредите поддержку: повторная регистрация устройств даст ещё одну волну обращений.
OpenAM не только читает профили OATH, но и пишет в них. При каждом входе через Authenticator (OATH) он обновляет в oathDeviceProfiles счётчик HOTP или время входа и дрейф часов TOTP, а при каждой записи — и при входе, и при регистрации — оставляет в атрибуте один профиль. Профиль Push при обычном входе не меняется: OpenAM перезаписывает его только при использовании кода восстановления. Набор полей профиля OATH, описанный в документации PingAM 7.5, совпадает с тем, что пишет OpenAM, но OpenAM разбирает профиль строго: если в реальном профиле окажется поле, которого он не знает, вход через Authenticator (OATH) для этого пользователя завершится ошибкой. Поэтому до параллельной эксплуатации выгрузите выборку реальных профилей вместе со значениями атрибута oath2faEnabled (о нём ниже) и проверьте на тестовой реплике обе стороны: устройство, зарегистрированное в PingAM, работает в OpenAM, а после входа через OpenAM — снова в PingAM.
До окончательного переключения регистрируйте устройства только в PingAM. Настройки OpenAM по умолчанию этому мешают: параметр Two Factor Authentication Mandatory (forgerockTwoFactorAuthMandatory) в сервисе Core Authentication выключен, и Authenticator (OATH) работает в необязательном режиме. В этом режиме модуль сначала проверяет атрибут oath2faEnabled и только потом — наличие устройства. Если атрибут пуст или равен 0, пользователь видит выбор «Register device» или «Skip this step», даже если устройство из PingAM у него есть. Пропуск записывает в учётную запись oath2faEnabled=1, и дальше OpenAM пускает этого пользователя без второго фактора. Регистрация заменяет профиль из PingAM новым, и прежнее устройство перестаёт работать. А пропуск шага на экране ввода кода сразу после регистрации удаляет профиль совсем.
Поэтому в реалмах, где второй фактор в PingAM обязателен, включите в OpenAM Two Factor Authentication Mandatory: тогда пользователь с устройством сразу попадает на ввод кода. Пользователю без устройства OpenAM и в этом режиме предложит регистрацию, а исключить его из цепочки нельзя: цепочку выбирают реалм или приложение, и все пользователи переключённой группы приложений проходят одну и ту же. Есть два выхода. Можно поставить перед Authenticator (OATH) скриптовый модуль с флагом REQUISITE, который отказывает во входе при пустом oathDeviceProfiles: такой пользователь сначала регистрирует устройство в PingAM. Или можно переключать группу только после того, как устройства в PingAM зарегистрировали все её пользователи с двухфакторной аутентификацией. В реалмах, где второй фактор необязателен, тот же выбор увидят пользователи, у которых устройство есть, а oath2faEnabled пуст или равен 0, — сколько их, покажет выборка.
Ключи и адреса. Два решения стоит принять до начала работ. Первое — можно ли выгрузить существующие пары ключей из keystore PingAM и импортировать их в OpenAM. Второе — оставить ли прежними entity ID SAML и URL конечных точек.
От entity ID зависят не только метаданные. Постоянные NameID SAML хранятся в записи пользователя вместе с entity ID провайдера идентификации и партнёра. OpenAM с прежним entity ID найдёт NameID, которые сохранил PingAM, и продолжит их выдавать, если репозиторий учётных записей настроен с типом OpenDJ. С новым entity ID он выпустит новые NameID, и партнёр, который связывает учётные записи по постоянному NameID, увидит незнакомых пользователей: в зависимости от настроек он заведёт им новые учётные записи или откажет во входе.
Прежние адреса — это прежние имя хоста, контекстный путь и имена реалмов: они входят и в URL конечных точек SAML, и в issuer OpenID Connect, а для SAML к ним добавляется metaAlias. OpenAM по умолчанию разворачивается под /openam, а у PingAM путь выбирают при установке: в документации Ping это тот же /openam, в ForgeOps — /am. Разверните WAR OpenAM под тем же путём, что у PingAM. Тогда issuer, discovery, JWKS и основные конечные точки OAuth 2.0 и OpenID Connect совпадут с PingAM 7.5. Исключение — адрес динамической регистрации клиентов: /register в PingAM и /connect/register в OpenAM. Переписывать путь на балансировщике ненадёжно: сервис Base URL Source, через который OpenAM подставляет внешний адрес, метаданные SAML не затрагивает, и в них остаётся собственный путь OpenAM.
Если сохранить ключи, идентификаторы и адреса, партнёрам и владельцам клиентов почти ничего не придётся менять, но переключать их придётся сменой DNS или правил балансировщика: всех сразу или по реалмам, если у каждого реалма своё DNS-имя либо балансировщик умеет различать запросы разных реалмов. Если реалмы различает балансировщик, проверьте, что его правила охватывают все адреса реалма, включая страницу входа, где реалм обычно передаётся параметром запроса, а не частью пути. Если же ключи, идентификаторы или адреса меняются, каждому партнёру понадобятся ваши новые метаданные, а каждому клиенту — новые конечные точки, зато переезжать они смогут по одному.
Базовая оценка берётся из двух предыдущих разделов: цепочки — это механический перенос, деревья — проектирование заново. Далее на оценку влияют следующие аспекты:
Реалмы. Большая часть переноса выполняется отдельно для каждого реалма. Keystore, хранилище конфигурации и CTS общие для сервера, а собственный Java-код компилируется один раз и затем подключается в каждом реалме; всё остальное вводится заново для каждого реалма. Стоит учесть, что настройка последующих реалмов будет заметно быстрее первого. Посчитайте, сколько у вас реалмов и сколько из них серьёзно отличаются друг от друга.
Собственный Java-код. Узлы аутентификации придётся переписать. Реализации репозиториев учётных записей, плагины постаутентификации и собственные условия политик требуется адаптировать и пересобрать: эти SPI тоже есть в OpenAM, но имена пакетов и сигнатуры могли измениться. В любом случае каждый такой компонент — это сборка, тестирование и ревью, и это единственная категория, где работа не ускоряется от повторения.
Policy-агенты. Считайте их по командам, которые владеют серверами, а не по числу агентов. Восемь агентов у одной команды — это одно согласование и один объём работ; восемь агентов у восьми команд — уже восемь согласований.
Партнёры по федерации. Значение имеет то, скольким партнёрам вообще придётся что-то делать. Это зависит не от размера вашей федерации, а от решений по ключам, секретам и конечным точкам, описанных в предыдущем разделе.
Добавьте перечисленные факторы к базовой оценке — и большинство инсталляций попадёт в одну из трёх категорий сложности. Как и в столбце трудоёмкости, речь о характере проекта, а не о числе недель.
Зелёная. Модули и цепочки, внешнее хранилище учётных записей на LDAP или Active Directory, стандартные OAuth 2.0 и SAML 2.0, нет пользовательских доработок. Владельцы клиентов забирают новые секреты, партнёры — новые метаданные, если вы меняете адреса или ключи. Заново проектировать ничего не приходится. Планируйте как обновление платформы: тестовый стенд, параллельная эксплуатация, окно переключения.
Жёлтая. В основном цепочки плюс деревья, которые проходят от начала до конца без ветвлений, или небольшое число собственных узлов. Дерево, которое нигде не ветвится, — это цепочка, узлы которой выписаны в ряд. Перенос механический, за исключением собственных узлов и узлов Scripted Decision: их замену нужно спроектировать, и начать проектирование стоит сразу, хотя сами реалмы переносятся уже после зелёных.
Красная. Ветвящиеся деревья, собственные узлы аутентификации с бизнес-логикой, узлы PingOne Protect внутри потоков или интеграция с PingIDM и/или PingGateway. Такие реалмы в любом случае придётся проектировать заново, а не переносить.
В одной инсталляции могут быть все три категории сложности. Разделите миграцию по реалмам: реалм, оставшийся на цепочках, можно мигрировать сразу, пока реалм с деревьями ещё в работе.
Составьте опись. Выполните в Amster export-config и сохраните результат. Импортировать его не нужно, но это самое полное машиночитаемое описание инсталляции, которое у вас будет, за вычетом секретов. Вторую часть описи придётся собрать вручную: какие команды владеют серверами с policy-агентами и какие агенты у каждой из них; кто у каждого партнёра по федерации может перезагрузить метаданные; кому разрешено менять секрет клиента; что реализовано в собственных jar-файлах, добавленных в WAR. Эти сведения тоже влияют на сроки.
Упорядочьте существующие реалмы. Отнесите каждый реалм к зелёной, жёлтой или красной категории, а потом начните с самого простого зелёного. Для него и настройте платформу: контейнер сервлетов или Docker-контейнер, подключение к репозиторию учётных записей, keystore, batch-файлы (о них — на этапе 4), конвейер развёртывания. Если делать это на реалме, в котором нет ничего необычного, возникающие проблемы оказываются проблемой платформы, а не ошибкой конфигурации. Каждый следующий реалм — это уже только перенос конфигурации. Реалмы, относящиеся к жёлтой и красной категориям, следует переносить в последнюю очередь, чтобы на них не влияли проблемы платформы. Проектирование для них при этом начинайте сразу, параллельно с переносом зелёных реалмов, чтобы к началу их переноса оно было готово.
Поднимите OpenAM рядом. На период тестирования миграции подключите OpenAM к тестовой реплике хранилища учётных записей. Затем обратите внимание на cookie сессии. Оба продукта поставляются с именем iPlanetDirectoryPro по умолчанию, и если две инсталляции окажутся в общем домене cookie, браузер будет отправлять одну и ту же cookie обеим: каждый сервер будет отклонять идентификатор сессии, который выдал не он, и перезаписывать его. Чтобы избежать конфликта, переименуйте cookie сессии в OpenAM.
Имя cookie задаётся свойством com.iplanet.am.cookie.name в настройках сервера по умолчанию. То же имя укажите в профилях агентов OpenAM, когда будете создавать их на этапе 4: у веб-агентов это свойство com.sun.identity.agents.config.cookie.name, у Java-агентов — com.iplanet.am.cookie.name. Поменяйте его и в собственных интеграциях с REST API: OpenAM ищет токен сессии в заголовке с тем же именем, что и cookie. По той же причине переименуйте amlbcookie — cookie, по которой балансировщик закрепляет пользователя за сервером. Оба продукта записывают в неё идентификатор сервера, так что балансировщик OpenAM, получив значение от PingAM, отправит пользователя не на тот сервер. Её имя задаётся свойством com.iplanet.am.lbcookie.name, и новое имя нужно прописать в правилах балансировщика.
Создайте конфигурацию заново. Сначала общие настройки для всех серверов — keystore, хранилище конфигурации, CTS, все собственные jar-файлы, которые поставляются в WAR, — затем реалм за реалмом. Записывайте перенос настроек как batch-файлы для команды ssoadm do-batch, начиная с первого реалма, даже если кажется быстрее прокликать консоль. Каждая строка такого файла — отдельная подкоманда ssoadm со своими параметрами, а учётные данные администратора один раз передаются самой do-batch в параметрах --adminid и --password-file. Так вы автоматизируете процесс настройки OpenAM, которым будете пользоваться не один раз: тестовые стенды, поднятие промышленной среды и т. д. Когда конфигурация реалма проверена на тестовой реплике, разверните её теми же batch-файлами в промышленной среде OpenAM, подключённой к промышленному хранилищу учётных записей — тому же, к которому подключён PingAM.
Эксплуатируйте обе системы параллельно. К этому моменту OpenAM подключён к промышленному хранилищу учётных записей, общему с PingAM, поэтому учётные записи существуют сразу на обеих платформах. Сессии — нет: браузер, вошедший в PingAM, для OpenAM анонимен, и наоборот. Поэтому параллельная эксплуатация работает на уровне приложений, и переезжает на самом деле группа приложений, которые ожидают друг от друга единого входа. Два приложения с общей сессией переезжают вместе — или ломаются оба. Состав таких групп нужно определить до первого переключения.
Переключайте по одной группе. Переключение — это перенаправление приложений, а не смена платформы: установить агент OpenAM, выдать клиенту OAuth 2.0 новые конечные точки, отправить партнёру по федерации новые метаданные. PingAM всё это время остаётся рабочим — именно это делает откат дешёвым: вы возвращаете приложение на систему, которая не останавливалась. Но дёшев только откат маршрутизации и конфигурации, а не данных: то, что OpenAM успел записать в общее хранилище, — профили устройств двухфакторной аутентификации, счётчики блокировок — после отката останется, поэтому совместимость профилей в обе стороны проверьте заранее (см. «Устройства двухфакторной аутентификации»). Первой возьмите группу с наименьшим числом пользователей и владельцем, который спокойно отнесётся к возможным сбоям, и отработайте процесс там, прежде чем трогать что-либо критичное. Так выглядит переключение, когда адреса меняются. Если вы сохранили прежние entity ID и URL, переезжает целый реалм или вся инсталляция сразу: приложения и партнёры переключаются сменой DNS или правил балансировщика, агенты Ping в том же окне заменяются агентами OpenAM, а откат — это обратная смена DNS или правил и возврат агентов Ping.
Выведите PingAM из эксплуатации. PingAM выключают, когда последняя группа переехала и проработала на OpenAM достаточно долго, чтобы откат ей уже не понадобился. Экспорт Amster и batch-файлы держите в системе контроля версий даже после того, как серверов не станет. Рано или поздно кто-нибудь спросит, почему атрибут был сопоставлен именно так, и к тому моменту экспорт будет единственным местом, где этот ответ ещё остался.
Секретов в репозитории при этом быть не должно. Если экспорт делался с транспортным ключом, в нём есть зашифрованные пароли — поля с суффиксом -encrypted, и расшифровать их сможет любой экземпляр AM с тем же ключом. Положите в репозиторий обычный экспорт, в котором вместо паролей стоит null. А если ключ sms.transport.key всё ещё лежит в keystore PingAM, удалите его: документация Ping требует делать это сразу после экспорта. Batch-файлы тоже проверьте: пароль хранилища данных или агента, переданный в параметре --attributevalues, записан в них открытым текстом. Вынесите такие значения в файлы для параметра --datafile и храните их отдельно, вместе с остальными секретами.
Коротко: для большей части того, что умеет PingAM 7.5, в OpenAM есть аналог, а исключения — деревья и узлы, часть расширений OAuth 2.0, OIDC и политик, хранилища секретов — перечислены в таблице. Готового инструмента для импорта конфигурации нет, а объём работ определяется тем, как построена аутентификация. Реалм на цепочках — это механический перенос. Реалм на ветвящихся деревьях — это редизайн процессов аутентификации, и в графике он должен стоять отдельной работой, а не задачей внутри миграции.
Документация OpenAM — справочник по второму столбцу таблицы сопоставления. Сначала прочитайте справочник модулей со своим списком модулей в руках, потому что сюрпризы находятся именно там.
По нескольким составным частям здесь уже есть разобранные примеры. Двухфакторная аутентификация с Google Authenticator и WebAuthn показывают, как цепочки собираются из модулей, а OAuth 2.0 и федерация разбирают клиентскую сторону.
Если вам нужно второе мнение о том, в какую категорию попадает ваша инсталляция, 3A Systems проведёт оценку миграции и может взять на себя её выполнение — см. Внедрение и доработка и Техническая поддержка. Помощь сообщества в GitHub Discussions остаётся бесплатной.
Запланированы три продолжения — пошаговые инструкции с конкретными командами, а не руководства по планированию:
Ссылки появятся здесь по мере публикации.
Напрямую — нет. PingAM 7.5 выгружает конфигурацию в JSON через Amster или файловую конфигурацию, а OpenAM настраивается через ssoadm, консоль и REST API. Поддерживаемого пути импорта между ними нет, поэтому конфигурация создаётся заново, а не копируется. Экспорт Amster всё равно стоит сделать. Это самое полное машиночитаемое описание того, что есть в вашей инсталляции, и мы используем его как опись на первом этапе.
Нет. В OpenAM аутентификация реализована как модули, объединяемые в цепочки, и в поставке более тридцати модулей аутентификации. PingAM 7.5 наряду с деревьями по-прежнему поддерживает модули и цепочки, поэтому если вы остались на цепочках, понятия сопоставляются один в один, хотя конфигурацию всё равно придётся создавать вручную, а не импортировать. Для потоков, построенных как деревья, среды выполнения в OpenAM нет, и их приходится перестраивать в цепочки: ветвление уходит в скриптовый модуль или в отдельные цепочки, а скрипты узлов переписываются.
Да. OpenAM подключается к существующему каталогу LDAP, к Active Directory или к PingDS (ранее ForgeRock DS) в качестве репозитория учётных записей, поэтому данные пользователей обычно остаются на месте. Если нужно уйти и с PingDS, данные пользователей переносятся в OpenDJ штатными экспортом и импортом LDIF. Что при этом переживёт перенос, зависит от четырёх вещей: от схемы хранения паролей, потому что при несовпадении пользователи не смогут выполнить bind; от схемы PingDS и служебных атрибутов; от конфиденциальных или зашифрованных атрибутов; и от топологии репликации, которая строится заново, а не мигрирует.
Это зависит прежде всего от того, как построена аутентификация. Инсталляции, оставшиеся на цепочках и модулях, с внешним хранилищем учётных записей и стандартными интеграциями OAuth 2.0 или SAML, — это в основном механическая работа. Инсталляциям, которые активно перешли на деревья или несут много собственных Java-узлов аутентификации, нужна перестройка аутентификации, и планировать их следует как проект, а не как обновление версии. Поверх этой базовой оценки на сроки влияет число реалмов, policy-агентов и партнёров по федерации.
Нет. Ни 3A Systems, ни Open Identity Platform не аффилированы с Ping Identity и не одобрены ею; Open Identity Platform — независимый проект сообщества. PingAM, PingDS, PingIDM, PingGateway и PingOne — товарные знаки Ping Identity, а ForgeRock — товарный знак ForgeRock, Inc.