LDAP довольно хорош. Он позволяет вам настроить кучу веб-сервисов, которые используют общую базу данных пользователей (или, скорее, каталог), так что вы можете установить WordPress, NextCloud, MediaWiki и т. Д., Все из которых позволяют вам входить в систему с одним и тем же пользователем. учетные данные после регистрации учетной записи на любом из них. Самостоятельно ничего программировать не нужно; все это программное обеспечение либо поддерживает LDAP «из коробки», либо имеет хорошо поддерживаемые плагины, чтобы предложить его.
Есть только одна проблема: LDAP не может помочь разным веб-службам обмениваться сеансами входа в систему (cookie-файлами), поэтому, когда вы входите в одну службу, вы не входите автоматически в другие. Вы должны войти в каждую службу с одним и тем же именем пользователя и паролем.
Итак, мой вопрос: существует ли такая широко распространенная технология, как LDAP (с точки зрения поддержки всеми видами программного обеспечения), которая решает проблему совместного использования сеансов пользователей? Что-то, что, скажем, поддерживается хотя бы WordPress, NextCloud и MediaWiki?
Это традиционное пространство для систем «управления веб-доступом» (WAM), таких как Siteminder, Oracle Access Manager, PingAccess и т. Д. Они обеспечивают «единый вход» (SSO) для различных приложений, предоставляя этим приложениям идентификационные данные с помощью заголовков и т.п. .
В последние годы веб-администраторы начали использовать подписанные и зашифрованные веб-токены JSON (JWT) в общих доменах (например, *.contoso.com) через файлы cookie. JWT может быть автономным, его можно проверить с помощью подписи, и он безопасен благодаря шифрованию. Его можно комбинировать с механизмами токенов обновления OIDC, OAuth для обеспечения постоянного доступа к приложению (на основе какого-либо бизнес-правила) и т. Д.
Все упомянутые вами приложения имеют механизмы, которые могут использовать OIDC, JWT, SAML и т. Д. В конечном счете, никто не сможет вручить вам «серебряную пулю», которая волшебным образом покроет все, что есть снаружи - вы найдете вещи, которые просто не были предназначены для такого рода аутентификации. Однако обычно это устаревшее программное обеспечение, которое последний раз обновлялось 12 лет назад, EOL - 8 лет назад, и никто не позаботился о его обновлении. Или хотел за это заплатить.
Лучшая стратегия - выяснить все, что нужно для SSO. Затем посмотрите на варианты SSO для этих вещей. Я бы начал с OIDC в качестве основного, а затем с заголовков в качестве дополнительного (вы можете использовать что-то вроде mod_auth_openidc для Apache, чтобы отправлять заголовки из OIDC id_token в приложение, которое может использовать заголовки для OIDC). Это должно дать вам 90 +% пути.