Почему один OTP не покрывает Wi-Fi, VPN и реестр

Единый вход обещает одну личность и меньше запросов, но обещание ломается на третьем протоколе. Ловушка в том, чтобы предполагать, будто одна успешная аутентификация создаёт токен, который может предъявить любой другой протокол. Доступ к Wi-Fi, вход в VPN и реестр контейнеров проводят каждый свой обмен, с разными аудиториями и сроками жизни. Разделить учётную запись — решение каталога; разделить учётные данные — решение протокола, а протоколы редко соглашаются.

Три обмена, три владельца

Корпоративный Wi-Fi запускает метод EAP внутри 802.1X, обычно его завершает служба RADIUS со своим взглядом на пользователя или устройство. Шлюз VPN аутентифицируется через свой поддерживаемый поток и затем держит сеанс со своим таймером повторной аутентификации. Реестр отвечает на неаутентифицированный запрос вызовом, который называет службу токенов, аудиторию и область действия, и клиент обменивает свои учётные данные на короткоживущий токен.

Это не три представления одного сеанса. У каждого свой проверяющий, свой срок жизни и свой путь отзыва, поэтому смена пароля в каталоге может оставить один работающим, а другой сломанным. Относитесь к ним как к трём интеграциям, которые случайно делят каталог пользователей.

Что браузерный SSO переносит, а что нет

Сеанс браузера у поставщика идентичности действительно полезен: приложения, которые туда перенаправляют, наследуют вход, уже выполненный пользователем. Это работает потому, что такие приложения говорят на тех же протоколах перенаправления и токенов и принимают ту же аудиторию. У запрашивающей стороны, говорящей на EAP, нет перенаправления, за которым можно следовать, а клиент Docker, получающий вызов реестра, не запрашивает токен идентичности OIDC. Поставщик идентичности может ручаться только за протоколы, для которых он построен.

Сбой легко увидеть в журналах, когда знаешь, куда смотреть. Поставщик идентичности сообщает об успешном входе, тогда как связывание с Wi-Fi всё ещё не удаётся, или реестр возвращает 401 после обмена токена, которого браузер так и не увидел. Два успеха и один сбой — не противоречие; это три отдельных аутентификации.

Где сертификат заменяет повторяющийся код

Для управляемых устройств EAP на основе сертификатов убирает человеческий шаг, не убирая идентичность: устройство предъявляет сертификат, служба RADIUS сверяет его с издавшим органом, а отзыв происходит в этом органе, а не в общем секрете. Цена — работа по жизненному циклу, потому что сертификаты истекают и должны быть обновлены заранее.

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

docker login registry.example.com

Сравните стоимость обслуживания, а не число запросов

Общие учётные данные кажутся дешёвыми, потому что работа невидима, пока что-то не сломается. Вместо этого посчитайте, во что каждый вариант обходится за год: регистрация, продление, отзыв, радиус последствий утечки и число систем, которых касаются, когда кто-то уходит. Парк сертификатов стоит дороже в построении и дешевле в эксплуатации в масштабе; скопированный код ничего не стоит начать и всё — распутать.

Затем выбирайте по каждому участку, а не глобально. Wi-Fi может перейти на сертификаты, VPN может сохранить поддерживаемый SSO с MFA, а реестр может использовать токены с явными областями. Запишите владельца, аудиторию, область, срок и путь отзыва для каждого, и запросы окажутся там, где нужно, а не везде сразу. Эта запись — также ответ, когда аудитор спрашивает, какие системы всё ещё доверяют паролю.