Чому один 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, а реєстр може використовувати токени з явними областями. Запишіть власника, аудиторію, область, строк і шлях відкликання для кожного, і запити опиняться там, де потрібно, а не всюди одразу. Цей запис — також відповідь, коли аудитор питає, які системи досі довіряють паролю.