Защо един 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, а регистърът може да използва токени с изрични обхвати. Запишете собственика, аудиторията, обхвата, срока и пътя за отмяна за всеки и подканите ще се появят там, където трябва, а не навсякъде наведнъж. Този запис е и отговорът, когато одитор попита кои системи все още се доверяват на парола.