В одной из наших команд мы быстро и индивидуально разрабатывали или развертывали большое количество специализированных веб-сервисов. Некоторые из них мы создаем (используя Django, Flask, Node и т. Д.), Другие - это проекты с открытым исходным кодом, которые мы только что запускаем (например, Wekan, Nifi и т. Д.). Мы поддерживаем единый вход для централизации учетных данных и разрешений для пользователей, разработчиков и администраторов, а также запускаем комбинацию KeyCloak (который предоставляет как OIDC, так и SAML) для управления пользователями приложений и Dex для управления учетными данными Kubernetes (все службы развертываются в рамках этого кластер).
Однако мы очень быстро сталкиваемся с трудностями, заставляющими SSO работать. Каждое приложение и веб-фреймворк имеют свой способ интеграции SSO, если он вообще его поддерживает. Нам пришлось отказаться от некоторых возможностей, потому что они не всегда работали с нашей инфраструктурой единого входа. Мы все более нерешительно относимся к развертыванию новых типов услуг, поскольку временные затраты на интеграцию единого входа каждый раз значительны. В долгосрочной перспективе это, вероятно, меньше усилий, чем сохранение отдельных учетных данных для каждой отдельной службы, но не намного, по крайней мере, в краткосрочной перспективе.
Мой вопрос заключается в следующем: поскольку мы контролируем нашу сеть и кластер, существует ли хороший или общий способ создания единого веб-портала, который интегрируется с SSO, а затем встраивает или передает через прокси отдельные службы, которые затем могут быть либо незащищенными (но доступными только для них). с этого прокси-сервера с поддержкой единого входа) или идентификация пользователя каким-то образом передается? Это обычное дело для четко определенных протоколов или общих решений с открытым исходным кодом? Или есть причина, по которой я не могу найти способ сделать это? Кажется, что должна быть какая-то аутентификация / идентификация, эквивалентная завершению SSL.
Вы можете использовать, например, обратный прокси-сервер в качестве точки входа с централизованной аутентификацией / авторизацией.
Но это только обеспечивает способ регулирования / контроля доступа и не предоставляет информацию о пользователях / группах / разрешениях в доступной службе.
Многие службы также обеспечивают интеграцию LDAP, который является одним из наиболее поддерживаемых / распространенных стандартов для данных каталога. LDAP также может использоваться как бэкэнд для KeyCloak.
Во многих случаях подключение LDAP для служб довольно быстро настраивается, в некоторых приложениях мелкозернистый доступ поддерживается только в коммерческих версиях.
Часто LDAP предоставляется через инфраструктуру Active Directory, которая используется для входа в систему DNS и Windows.