Аутентификация

Многие из нас участвовали в конференциях и семинарах. Регистрируясь на конференции, я подхожу к специальному столику, где получаю бэдж со своей фамилией и логотипом конференции. Хорошая практика – посещать мероприятия конференции, прикрепив бэдж на лацкан пиджака или повесив на груди. Тогда другие участники смогут идентифицировать меня, полагаясь на проверку, проведенную при регистрации.

К счастью, эта проверка обычно является очень мягкой. Участник просто сообщает свое имя, а регистратор, представляющий оргкомитет, проверяет наличие имени в списках. Проверку можно усилить (к всеобщему неудовольствию участников), если проверять их первичные (паспорт) или вторичные (командировочное предписание) удостоверения. Можно пойти по-другому пути: при предварительной регистрации на сайте конференции согласовывать с участниками секретные коды (пароли) и проверять их знание непосредственно у столика.

После регистрации я могу пройти к другому столику. Здесь после проверки бэджа мне выпишут билеты на объекты или мероприятия конференции. Билеты могут быть именными (в них вписано мое имя) или на предъявителя. Перед выпуском билета меня снова могут попросить сообщить предварительно согласованный код.

Примером билета на предъявителя является ключ от гостиничного номера, в котором я буду проживать. Этот ключ интересен тем, что открывает доступ к моим ресурсам – вещам, размещенным в номере. Если я забыл в номере флешку со слайдами доклада и не могу отлучиться в гостиницу, то я передам ключ своему коллеге и попрошу его съездить за флешкой. Коллега распоряжается моими ресурсами с моего ведома. Кроме этого, ключ дублируется гостиничными службами, которые убирают мой номер, т.е. также управляют моими ресурсами.

Описанная игровая ситуация имеют вполне отчетливые аналоги в современных информационных системах. Аутентификация – проверка подлинности пользователей – является одним из ключевых элементов этих систем. Аутентификацию проводит специальный сервер идентификации (СИ) – цифровой "столик регистрации". Аутентифицируясь перед СИ, я, образно говоря, создаю своего виртуального представителя (агента) в цифровом мире. Агентом является клиентская программа (КП), выступающая от моего имени. Как правило, это браузер. Я сообщаю КП свое имя, передаю токены аутентификации (ТА). Используя токены, КП доказывает СИ мою подлинность.

Простейший токен – это статический (долговременный) пароль. Токены посложнее – карты кодов, программы, которые генерируют одноразовые пароли, устройства, которые вырабатывают электронные подписи или реализуют криптографические протоколы. Токен обязательно содержит секрет аутентификации.В процессе аутентификации по этому секрету формируется аутентификатор, который и предъявляется СИ. Умение сформировать корректный аутентификатор доказывает мою подлинность.При предварительной регистрации СИ создает и сохраняет аттестат, связанный с токеном. Аттестат позволяет СИ проверять мои аутентификаторы. Примером аттестата является сертификат открытого ключа. Я вырабатываю подпись на своем личном ключе с помощью криптографического токена. СИ проверяет мою подпись на сертификате-аттестате.

КП не нужно прямо доказывать мою подлинность третьей стороне – прикладной системе (ПС). Достаточно получить у СИ билет аутентификации (БА, цифровой бэдж) и предъявлять его в сеансах с ПС. В БА указывается мое имя, имя СИ, время выпуска, срок действия. БА подписывается СИ. Проверяя подпись, ПС убеждается в подлинности билета. Но этого мало. Билет нужно связать с предъявителем. Поэтому ПС требует сопровождать БА заранее согласованным билетом сеанса (БС). Предварительно согласованный код из нашей игровой ситуации являются примером такого билета.

Вместе с БА сервер идентификации может выпускать другие билеты, например, билет доступа (БД). Этот билет открывает доступ ПС к моим ресурсам – это ключ от моего номера. Естественно, что права доступа согласовываются со мной.

По соображениям безопасности БД является краткосрочным. Чтобы не проводить повторную аутентификацию всякий раз по истечении срока действия БД, СИ выпускает долговременный билет обновления (БО). Предъявляя БО, ПС получает новый БД.

Мы кратко пересказали общую концепцию аутентификации. Концепция может быть реализована разными способами. В современном Интернет наибольшее распространение получили реализации в рамках инфраструктур OAuth 2.0 / Open ID Connect 1.0. Одна из таких реализаций в ближайшее время будет развернута в банковской сфере нашей страны.