Авторы: Ирина Блажина и Николай Зайцев · HighLoad Channel

В X5 Tech несколько продуктов использовали собственные системы аутентификации. Пользователям приходилось заново входить в разные сервисы и получать дополнительные SMS, а команды независимо поддерживали код, связанный с безопасностью. Единый SSO должен был решить обе проблемы.

Основой системы стал Keycloak. Его возможностей хватало для обработки входов, но при росте аудитории команда столкнулась с другим ограничением: время запуска зависело от количества сохранённых сессий. Так задача масштабирования SSO превратилась в разбор кэшей, rolling updates, PostgreSQL и устройства самого Keycloak.

Кому смотреть: командам, которые внедряют централизованную аутентификацию, расширяют Keycloak собственными providers или готовят SSO к большой аудитории.

Из этого можно взять в работу: проверять identity-сервис не только под потоком входов, но и при полном перезапуске кластера с реальным объёмом пользовательских сессий.

Автор: Eugene Suleimanov · Proselyte

Почти двухчасовой курс от автора Eugene Suleimanov показывает Keycloak не как «готовую страницу входа», а как отдельную платформу, которой приложение передаёт значительную часть работы с аутентификацией и авторизацией.

Полностью пересказать такой материал в одном дайджесте невозможно. Автор последовательно проходит от realm, clients, scopes и roles до OAuth 2.0, OpenID Connect, SAML, федерации пользователей и межсервисного доступа. Затем собирает практическую систему с двумя приложениями, PostgreSQL и Keycloak, подключает внешние Identity Providers и защищает вызовы между сервисами.

Главная мысль курса — у приложения не одна граница входа. Пользователь может приходить напрямую или через GitHub, учётная запись может храниться в LDAP, а один сервис должен обращаться к другому без участия человека. Keycloak даёт общую точку, где эти сценарии можно описывать и контролировать.

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

Из этого можно взять в работу: перечислить все способы, которыми люди и сервисы получают доступ к системе, и проверить, не реализует ли каждый компонент собственную несовместимую схему аутентификации.

Автор: Listen IT · YouTube · статья Nixys

При входе через SAML приложение не получает пароль пользователя. Вместо него оно получает XML-документ, в котором Identity Provider утверждает, что пользователь прошёл аутентификацию. Теперь безопасность зависит от того, насколько строго приложение проверяет это утверждение.

Ролик Listen IT объясняет основные роли SAML. Service Provider представляет приложение, Identity Provider проверяет пользователя, а браузер переносит SAML-запросы и ответы между ними. Благодаря установленному доверию один вход у IdP может открыть доступ к нескольким независимым приложениям.

Это хорошее введение в SAML SSO, но реальный протокол сложнее показанной схемы. Недостаточно найти в ответе имя пользователя: Service Provider должен проверить цифровую подпись, отправителя, получателя, срок действия и другие ограничения assertion.

Кому смотреть: разработчикам, которым предстоит впервые подключать корпоративный SAML-вход и нужно понять роли IdP, SP и браузера.

Из этого можно взять в работу: перед интеграцией перечислить все проверки SAML response, которые выполняет выбранная библиотека, и убедиться, что они не отключены ради успешного первого входа.

Автор: Listen IT · YouTube · статья Nixys

Single Sign-On часто объясняют как «один пароль для всех приложений». Но главное изменение происходит не в пароле: приложения перестают самостоятельно проверять учётные данные и начинают доверять результату аутентификации в другой системе.

Ролик Listen IT показывает базовый сценарий SSO. Пользователь открывает приложение, перенаправляется к Identity Provider, проходит аутентификацию и возвращается с подтверждением личности. После этого другие приложения, включённые в ту же систему доверия, могут не запрашивать пароль повторно.

SSO при этом не является отдельным протоколом. Это желаемое поведение системы, которое можно реализовать через SAML или OpenID Connect. LDAP, Active Directory Domain Services и Active Directory Federation Services тоже появляются рядом с SSO, но решают задачи другого уровня: хранят пользователей, предоставляют доступ к каталогу или организуют федерацию.

Кому смотреть: разработчикам и системным аналитикам, которым нужно составить начальную карту технологий корпоративного входа.

Из этого можно взять в работу: для каждого приложения записать, кто именно проверяет пользователя и на основании какого сообщения приложение ему доверяет.

Автор: Алексей Смирнов · Podlodka Podcast #448

Уводим «Хвост инженера» в сторону безопасности. Этот выпуск Podlodka — о том, как уязвимости приходят в проект через обычные зависимости и наши привычки.

Алексей Смирнов основал CodeScoring — платформу для анализа open source зависимостей. Разбирает то, что обычно выпадает из разговоров о безопасном коде: угрозы, которые приходят не из вашего репозитория.

Уязвимость может прийти из библиотеки, которую вы не трогали три года, из инструмента сборки, из GitHub Actions. Ответственность разработчика распространяется на весь граф зависимостей — не только на то, что вышло из-под его рук.

Кому смотреть: тем, кто подключает зависимости не задумываясь и считает, что безопасность — это про свой код, а не чужой.

Из этого можно взять в работу: посмотри, что происходит с зависимостями, когда меняется мейнтейнер. XZ Utils показал, что именно здесь и нужно смотреть в первую очередь.