Функциональные возможности
Аутентификация
- Сценарии аутентификации и регистрации реализованы в виде настраиваемого графа переходов между страницами и формами. Безопасность сценариев и консистентность логики обеспечивает сервер аутентификации. Клиентские приложения получают возможность свободной реализации UX/UI шагов.
- Широкий выбор методов аутентификации. Продукт предоставляет более 30 различных методов аутентификации, которые можно использовать в сценариях. В том числе:
○ логин и пароль;
○ одноразовые пароли с использованием метки времени (TOTP);
○ аутентификация с помощью ЕСИА и ряда других внешних поставщиков identity;
○ сертификат квалифицированной электронной подписи (КЭП);
○ клиентский сертификат на устройстве доступа;
○ биометрия пользовательского устройства (WebAuthN);
○ разовая ссылка «magic link»;
○ долгоживущие токены.
Кроме методов аутентификации для клиентов в системе поддержан ряд классических методов аутентификации для администраторов и сотрудников с использованием учетных данных в каталоге Active Directory и автоматической доменной аутентификации по протоколу Kerberos.
- Поддержка аутентификации по стандартам OAuth2.0, OpenID Connect, SAML.
- API аутентификации для веб- и мобильных приложений.
- SSO и SLO.
Регистрация клиентов
- RooX UIDM позволяет создавать сценарии саморегистрации клиентов, совмещая методы аутентификации с онбордингом клиентов и их регистрации в системах компании.
- Регистрация пользователей с помощью УКЭП или учетной записи ЕСИА. Система позволяет настроить регистрацию пользователей с использованием информации из электронной подписи или учетной записи ЕСИА.
- Упрощенная регистрация. Возможность быстро регистрировать и аутентифицировать клиентов с использованием только номера телефона, без запроса других идентификаторов.
- Запуск произвольных проверок. Сценарии регистрации позволяют запустить произвольные процессы в смежных системах BPMS. Например, возможно инициировать произвольные проверки клиента во внешних системах перед регистрацией.
- Саморегистрация юридических лиц. Для клиентов-юрлиц предусмотрены различные сценарии регистрации официальных представителей (администратор) компаний и их сотрудников. Администратор клиента-юрлица может регистрировать сотрудников или отправлять им ссылки для саморегистрации.
Самообслуживание
- Смена и сброс пароля. Система предоставляет готовые пользовательские сценарии и API для самообслуживания пользователей.
- Пользовательские настройки аутентификации. Пользователь может управлять некоторыми особенностями сценариев аутентификации. В частности, активировать или отключать использование второго фактора аутентификации в зависимости от использованного первого фактора.
- Управление разрешенными устройствами. Пользователь может удалять устройства из списка «доверенных», предотвращая доступ с неизвестных или ненадежных устройств.
- Генерация API-токенов для предоставления доступа сторонним приложениям.
- Управление доступом сотрудников юрлица. Уполномоченные сотрудники клиента-юрлица могут управлять списком своих сотрудников и их полномочиями.
Защита веб-приложений
- Централизованная аутентификация веб-приложений согласно протоколам OAuth2.0, OpenID Connect, SAML;
- Централизованная авторизация действий пользователей;
- Обмен токенов согласно протоколу Token Exchange;
- Бесшовный переход между приложениями с использованием технологии Single Sign-On;
- Защита важных операций многофакторной аутентификацией;
- Набор библиотек разработчиков: Mobile SDK, Web SDK, Java SDK.
Администрирование пользователей
- Управление пользователями. Интерфейс администратора пользователей RooX UIDM поддерживает создание и редактирование учетных записей, блокировку, сброс пароля и другие необходимые операции.
- Управление приложениями.
- Управление политиками аутентификации и авторизации.
- Аудит действий пользователя.
- Имперсонация (вход авторизованным сотрудником в приложения от лица управляемой учетной записи).
Стандарты и и принципы
RooX UIDM создан в соответствии со следующими принципами:
- Фокус на российский рынок, локальная разработка и техническая поддержка;
- Поддержка микросервисной архитектуры;
- Полный охват функций API-методами для интеграции и кастомизации (API-first);
- Соответствие ГОСТ P 58833-2020 («Защита информации. Идентификация и аутентификация. Общие положения»), ГОСТ Р 70262.1-2022 («Защита информации. Идентификация и аутентификация. Уровни доверия идентификации»). Соответствует требованиям 683-П ЦБ для кредитных организаций;
- Поддержка российского стека технологий, совместимость с российскими ОС, Java, СУБД;
- Соответствие международным стандартам NIST, OWASP.
Система аутентификации со стороны клиента
В некоторых случаях сама аутентификация целиком проводится на стороне клиента, а серверу лишь посылается ее результат. Как подтип такой аутентификации может быть, что клиент переадресовывается на некоторый длинный URL в случае удачного прохождения аутентификации.
В любом случае независимо от реализации такую систему аутентификации нельзя назвать достаточно хорошей. Практически, она даже хуже системы с длинным URL.
Вот пример системы с аутентификацией пользователя методами JavaScript.
<html>
<title>аутентификация</title>
<head>
<script type="text/javascript">
function auth()
{
p = prompt('Введите пароль');
if(p == 'pdgf32f')
{
document.location.href='auth.html';
exit;
}
else alert('Пароль неверный');
}
</script>
</head>
<body>
<input type="button" value="Войти в систему" onclick="auth()">
</body>
</html>
Очевидно, что подобная система не представляет никакой преграды перед нападающим. Полный текст HTML–страницы доступен любому, даже неаутентифицированному пользователю, и любой пользователь, просматривая исходный код, сможет выявить всю информацию, необходимую для проведения аутентификации.
Кроме JavaScript на стороне клиента, аутентификация может выполняться в Java–аплетах, Active X–компонентах и другими способами, предполагающими выполнение некоторого кода, с помощью которого будет произведена аутентификация на стороне клиента.
Использование смарт-карт и USB-ключей
Несмотря на то, что криптография с открытым ключом согласно спецификации Х.509 может обеспечивать строгую аутентификацию пользователя, сам по себе незащищенный закрытый ключ подобен паспорту без фотографии. Закрытый ключ, хранящийся на жёстком диске компьютера владельца, уязвим по отношению к прямым и сетевым атакам. Достаточно подготовленный злоумышленник может похитить персональный ключ пользователя и с помощью этого ключа представляться этим пользователем. Защита ключа с помощью пароля помогает, но недостаточно эффективно -пароли уязвимы по отношению ко мно¬гим атакам. Несомненно, требуется более безопасное хранилище.
Смарт-карты
Смарт-карты — пластиковые карты стандартного размера банковской карты, имеющие встроенную микросхему. Они находят всё более широкое применение в различных областях, от систем накопительных скидок до кредитных и дебетовых карт, студенческих билетов и телефонов стандарта GSM.
Для использования смарт-карт в компьютерных системах необходимо устройство чтения смарт-карт. Несмотря на название — устройство чтения (или считыватель), — большинство подобных оконечных устройств, или устройств сопряжения (IFD), способны как считывать, так и записывать информацию, если позволяют возможности смарт-карты и права доступа. Устройства чтения смарт-карт могут подключаться к компьютеру посредством последовательного порта, слота PCMCIA или USB. Устройство чтения смарт-карт также может быть встроено в клавиатуру. Как правило, для доступа к защищенной информации, хранящейся в памяти смарт-карты, требуется пароль, называемый PIN-кодом.
USB-ключи
USB-ключи достаточно привлекательны, поскольку USB стал стандартным портом для подключения периферийных устройств и организации не нужно приобретать для пользователей какие бы то ни было считыватели.
Аутентификацию на основе смарт-карт и USB-ключей сложнее всего обойти, так как используется уникальный физический объект, которым должен обладать человек, чтобы войти в систему. В отличие от паролей, владелец быстро узнаёт о краже и может сразу принять необходимые меры для предотвращения её негативных последствий. Кроме того, реализуется двухфакторная аутентификация. Микропроцессорные смарт-карты и USB-ключи могут повысить надёжность служб PKI: смарт-карта может использоваться для безопасного хранения закрытых ключей пользователя, а также для безопасного выполнения криптографических преобразований. Безусловно, данные устройства аутентификации не обеспечивают абсолютную безопасность, но надёжность их защиты намного превосходит возможности обычного настольного компьютера.
Для хранения и использования закрытого ключа разработчики используют различные подходы. Наиболее простой из них — использование устройства аутентификации в качестве защищенного носителя аутентификационной информации: при необходимости карта экспортирует закрытый ключ, и криптографические операции осуществляются на рабочей станции. Этот подход является не самым совершенным с точки зрения безопасности, зато относительно легко реализуемым и предъявляющим невысокие требования к устройству аутентификации. Два других подхода более безопасны, поскольку предполагают выполнение устройством аутентификации криптографические операций. При первом пользователь генерирует ключи на рабочей станции и сохраняет их в памяти устройства. При втором пользователь генерирует ключи при помощи устройства. В обоих случаях, после того как закрытый ключ сохранён, его нельзя извлечь из устройства и получить любым другим способом.
Импортозамещение
Миграция
Для импортозамещения разработаны две концепции миграции на Roox UIDM:
- для решений сторонних вендоров, развернутых на собственной инфраструктуре;
- для перехода с облачных сервисов аутентификации и авторизации.
Совместимость с Linux
RooX UIDM совместима с российскими OC на базе Linux: Astra Linux и «Альт». RooX UIDM входит в реестр отечественного ПО (запись в реестре №10504 от 06.05.2021).
Лицензирование
Стоимость формируется в зависимости от количества пользователей или функциональных возможностей, оплата единовременная или по подписке.
Обеспечение поддержки
Поддержка осуществляется разработчиком, на русском языке, уровень L-3. Параметры устанавливаются индивидуально в зависимости от требований заказчика.
Резюме
Итак, задача решена?! Мы можем аутентифицировать пользователей и аутентифици-ровать устройства в момент их первой попытки получить доступ к каким-либо корпоративным ресурсам
И неважно, откуда такая попытка осуществлялась – изнутри сети или снаружи, по проводному соединению или беспроводному, с Windows или Mac, с устройства, за которым сидит пользователь, или нет
В идеале же необходимо использовать комбинацию «пользователь + устройство». Только в этом случае можно исключать такие ситуации, когда пользовательский пароль перехвачен, и кто-то пытается с чужого узла подключиться к корпоративным ресурсам. Протокол, который позволяет проводить аутентификацию устройств, называется 802.1x, а технология, с помощью которой можно оценивать соответствие целого узла требованиям политик безопасности, – Network Admission Control, или Network Access Control (NAC).
Мы можем гарантировать (при правильном использовании), что никто посторонний не подключится ни к нашей сети, ни к нашим серверам, ни к нашим приложениям, ни к нашим данным. Достаточно ли этого?
Можно ли объединить все вместе?
Можно ли попробовать устранить описанную проблему со сложностью администрирования процесса аутентификации, авторизации и контроля доступа на уровне внутренней сетевой инфраструктуры? Да, безусловно. Как для администрирования множества межсетевых экранов или систем предотвращения вторжения используется система централизованного управления, так и для управления настройками доступа сетевого оборудования используется аналогичная система.
В принципе многие системы сетевого управления могут решить задачу централизации администрирования настроек сети и управления списками контроля доступа, но… Обычно делается это в отвязке от самих пользователей и в отрыве от оценки состояния (статуса) самого узла. Иными словами, котлеты отдельно, а мухи отдельно. А есть ли решения, которые смогут объединить все эти задачи вместе? Можно ли интегрировать сервисы:
Многие системы сетевого управления могут решить задачу централизации администрирования настроек сети и управления списками контроля доступа, но… Обычно делается это в отвязке от самих пользователей и в отрыве от оценки состояния (статуса) самого узла. Иными словами, котлеты отдельно, а мухи отдельно. А есть ли решения, которые смогут объединить все эти задачи вместе?
- аутентификации;
- авторизации;
- управления жизненным циклом гостевого доступа;
- профилирования;
- оценки состояния узла?
Можно ли с помощью одного решения реализовать следующие политики:
- Мне нужно разрешать подключение к сети только определенных пользователей и устройств.
- Мне нужно, чтобы пользователь и устройства пользовались соответствующими сетевыми сервисами.
- Мне нужно разрешить гостям доступ в сеть и управлять их настройками.
- Мне нужно разрешать/блокировать использование iPad в моей сети (BYOD).
- Мне нужно, чтобы в моей сети были “чистые” (соответствующие политикам ИТ и ИБ) устройства.
- Мне необходим масштабируемый способ реализации политики доступа в сети.
Да, такие решения есть. Они не только проводят интегрированную аутентификацию устройств и пользователей. Они еще и упрощают управление сетью, т.к. не требуют наличия тысяч правил на каждом сетевом устройстве. Достаточно иметь одну ролевую политику, в которой правила описаны следующим образом:
- Финансовый контролер имеет доступ к финансовым серверам, принтеру, а к Интернету доступ в рабочее время запрещен.
- Сотрудник HR имеет доступ к HR-системе, порталу дистанционного обучения, принтеру и Интернету.
- Сотрудник отдела продаж имеет доступ к CRM-системе, принтеру, а к Интернету – только полчаса в день во время обеда.
- Принтер имеет доступ только к серверу обновления и сам не может инициировать никаких соединений.
Дальше система:
- сама, взяв данные из Active Directory, понимает, кто скрывается за ролью «финансовый контролер» или «сотрудник отдела продаж»;
- сама определяет путь прохождения запроса на доступ от компьютера сотрудника до запрошенного ресурса;
- сама динамически и в реальном времени прописывает соответствующие настройки доступа сетевого оборудования (понимая «язык» конкретной модели) на всем протяжении пути;
- сама контролирует, чтобы пользователь или устройство не смогли сделать «шаг влево или вправо»;
- сама по окончании доступа отменяет сделанные правила, тем самым реализуя принцип минимума привилегий на сетевом уровне;
- сама фиксирует все попытки доступа для последующего анализа или разбирательств.
Таких решений, цель которых – автоматизация контроля сетевого доступа, немного, но все-таки эта ниша постепенно заполняется продуктами, которые научили «дружить» традиционную информационную безопасность, следяющую за пользователями, и безопасность, следяющую за сетью. Обычно такие решения разрабатываются производителями сетевого оборудования, перед которыми и стоит задача эффективного управления всем тем многообразием настроек и функций, которые в их продукции есть, но которыми бывает неудобно пользоваться в крупных сетях.
Дело за малым – разрулить традиционный конфликт между айтишниками и безопасниками и понять, как они будут делить задачу управления безопасностью во внутренней сети. Ведь раньше безопасники этим не занимались, потому что у них не было правильного инструментария и их не пускали к сетевому оборудованию представители ИТ-подразделений. Последние же тоже не занимались безопасностью внутренней сети, считая это не своей работой. В итоге такого вакуума страдала компания – злоумышленники-то были рады такому конфликту и ничтоже сумняше-ся пользовались им.
⇡#Коммуникационное ПО
TrueConf (разработчик «Труконф»). Комплекс решений для видео-конференц-связи и удалённой работы, представляющий собой альтернативу Zoom, Cisco Webex, Microsoft Teams, Google Meet, Skype for Business и прочим зарубежным коммуникационным платформам. Отечественная система допускает подключение до 1000 абонентов к одной конференции с разрешением вплоть до 4К (UltraHD). В составе продукта представлены клиентские приложения для всех популярных операционных систем (Windows, Linux, macOS, Android, Android TV, iOS), мессенджер, инструменты для обмена файлами и различные медиасервисы. В дополнение к этому предусмотрены функции шифрования транслируемых по сети данных, средства интеграции с VoIP/ВКС-оборудованием и возможность проведения WebRTC-конференций.
Mailion (разработчик «Новые облачные технологии»). Почтовая система нового поколения, которая предназначена для работы на серверных мощностях крупного предприятия или холдинга более чем с 30 тыс. сотрудников. Утверждается, что решение способно поддерживать одновременную работу до миллиона активных пользователей. Mailion создана российскими специалистами с чистого листа и помимо обмена электронной корреспонденцией обеспечивает календарное планирование, работу с адресными книгами, а также интеллектуальный поиск информации в почте, календаре, контактах и справке. Для взаимодействия с почтовой системой предусмотрены настольные, веб- и мобильные клиентские приложения.
В основу продукта положена микросервисная архитектура с использованием принципов Cloud Native. Такой подход обеспечивает геораспределённую работу платформы, гарантирует высокую отказоустойчивость и позволяет использовать службы электронной почты в IT-средах любых масштабов. Решение совместимо с любыми внешними настольными клиентами и мобильными приложениями для работы с почтой, календарями и контактами по протоколам IMAP, CalDAV, CardDAV и LDAP. Поддерживаются популярные браузеры и операционные системы. Mailion использует принципы иммунного подхода, которые заложены в KasperskyOS, и совместима с ней в части мобильного клиента. Предусмотрены возможности для интеграции дополнительных модулей и компонентов с использованием разных языков программирования.
IVA AVES-S (разработчики: Научно-исследовательский институт «Масштаб» и группа компаний «ХайТэк»). Платформа для организации многоточечных защищённых видеоконференций с разрешением Full HD. Система позволяет в режиме реального времени обмениваться сообщениями, включая голосовые звонки, видео, слайды, презентации и документы. По функциональным возможностям продукт сравним со Skype for Business, но при этом предназначен для использования в органах государственной власти, силовых структурах, госкорпорациях и прочих организациях, предъявляющих высокие требования к безопасности пересылаемых по сети данных. В активе IVA AVES-S имеются сертификаты ФСТЭК и Минобороны России, допускающие использование продукта для работы с информацией с грифом до «совершенно секретно» включительно. Для открытого сегмента рынка предусмотрена версия IVA AVES без литеры «S».
Альтернативные решения для коммуникаций: VideoMost (разработчик Spirit), «Сибрус» («Киберника»), «Вега-Ирида» (концерн радиостроения «Вега»), eXpress («Анлимитед Продакшн»), «Видеоселектор» («Инкома»).
Биометрическая идентификация
Данная технология основана на применении статистического анализа биологических наблюдений и явлений. Биометрическая характеристика — это измеримая физиологическая или поведенческая черта человека.
Биометрические характеристики можно разделить на две группы:
- Физиологические биометрические характеристики (называемые физическими или статическими) — характеристики, основанные на данных, полученных путём измерения анатомических данных человека(отпечатки пальцев, форма лица, кисти, структура сетчатки глаза и др.).
- Поведенческие биометрические характеристики (также называемые динамическими биометрическими характеристиками) — биометрические характеристики, основанные на данных, полученных путём измерения действий человека. Характерной чертой для поведенческих характеристик является их протяжённость во времени (типичные примеры — голос, подпись).
Реализация session-based аутентификации в DRF
Несмотря на эти
недостатки, авторизация и аутентификация этим способом довольно распространена
и встроена в Django REST Framework. Реализуется
она очень просто. Достаточно в коллекции urlpatterns (в файле drfsite/urls.py) прописать
строчку:
urlpatterns =
...
path('api/v1/drf-auth/', include('rest_framework.urls'))
Все. Запускаем
тестовый веб-сервер, переходим по адресу:
http://127.0.0.1:8000/api/v1/drf-auth/
и нам здесь
отображаются поддерживаемые маршруты, в частности:
-
api/v1/drf-auth/login/ — для входа в
систему; -
api/v1/drf-auth/logout/ — для выхода
из системы.
Мало того, если
выполнить любой API-запрос для DRF, например:
http://127.0.0.1:8000/api/v1/women/
то вверху на
панели увидим ссылку для авторизации. Нажмем на нее, появится окно для ввода
логина и пароля:
Мы можем войти
здесь под администратором, так как DRF полностью интегрирован с
фреймворком Django и все
зарегистрированные на сайте пользователи автоматически могут использовать
систему авторизации и аутентификации DRF.
После входа
возвращаемся на прежнюю страницу и видим, что мы были успешно авторизованы и
идентифицированы системой, так как внизу списка появилась форма для добавления
новой записи. А мы помним, что на предыдущем занятии сделали так, чтобы эта
форма появлялась только для авторизованных пользователей.
Чтобы убедиться,
что аутентификация пользователя производится по session id, можно открыть
в браузере панель «Инспектор», перейти во вкладку «Network», обновить
страницу и здесь (в самом верху выбрать страницу) можно посмотреть на
содержимое переданного заголовка. В частности, мы видим следующую строчку для cookie:
csrftoken=CBwenFKcZc9uHFFqVDqWRyxJZYhUxBXinHFOUk4B2aOCC0I2HByf3KlUhy5WwTwv;
sessionid=oyg9fmyh6t8g3wsk73ut4ayiagzid2a1
Здесь,
во-первых, имеется csrftoken для защиты от взлома (подмены устройства, с
которого осуществляется вход) и, во-вторых, sessionid, по которому выполняется
аутентификация пользователя. То есть, при каждом запросе от клиента должна
поступать эта информация, чтобы сервер мог корректно идентифицировать
пользователя и разрешить ему вход в систему.
Я постарался
предельно просто и доступно изложить идею авторизации на основе сессий и cookies, а также
продемонстрировал, как можно подключить этот тип аутентификации пользователей в
Django REST Framework. На следующем
занятии мы продолжим эту тему и поговорим о более распространенном способе аутентификации
для API-запросов через
токены.
Видео по теме
#1. Django REST Framework — что это такое
#2. Установка Django Rest Framework
#3. Базовый класс APIView для представлений
#4. Введение в сериализацию. Класс Serializer
#5. Методы save(), create() и update() класса Serializer
#6. Класс ModelSerializer и представление ListCreateAPIView
#7. Представления UpdateAPIView и RetrieveUpdateDestroyAPIView
#8. Viewsets и ModelViewSet
#9. Роутеры: SimpleRouter и DefaultRouter
#10. Ограничения доступа (permissions)
#11. Авторизация и аутентификация. Session-based authentication
#12. Аутентификация по токенам. Пакет Djoser
#13. Идея авторизации по JWT-токенам
#14. Делаем авторизацию по JWT-токенам
#15. Добавляем пагинацию (pagination)
Сервер авторизации
Сервер авторизации — это набор конечных точек (методов API) для взаимодействия с пользователем и выдачи токенов. Как это работает?
Давайте вернемся к ситуации с HireMe123 и MyCalApp, только теперь у нас есть OAuth 2.0:
MyCalApp теперь имеет сервер авторизации. Предположим, что HireMe123 уже зарегистрирован как известный клиент в MyCalApp, что означает, что сервер авторизации MyCalApp распознает HireMe123 как объект, который может запрашивать доступ к своему API.
Предположим также, что вы уже вошли в систему с HireMe123 через любую аутентификацию, которую HireMe123 настроил для себя. HireMe123 теперь хочет создавать события от вашего имени.
HireMe123 отправляет запрос авторизации на сервер авторизации MyCalApp. В ответ сервер авторизации MyCalApp предлагает вам — пользователю — войти в систему с помощью MyCalApp (если вы еще не вошли в систему). Вы аутентифицируетесь с MyCalApp.
Затем сервер авторизации MyCalApp запросит у вас согласие разрешить HireMe123 получать доступ к API MyCalApp от вашего имени. В браузере откроется приглашение, в котором будет запрошено ваше согласие на добавление в календарь событий HireMe123 (но не более того).
Если вы скажете «да» и дадите свое согласие, то сервер авторизации MyCalApp отправит код авторизации в HireMe123. Это позволяет HireMe123 знать, что пользователь MyCalApp (вы) действительно согласился разрешить HireMe123 добавлять события с использованием пользовательского (вашего) MyCalApp.
MyCalApp затем выдаст токен доступа для HireMe123. HireMe123 может использовать этот токен доступа для вызова MyCalApp API в рамках разрешенных вами разрешений и создания событий для вас с помощью MyCalApp API.
Ничего плохо больше не происходит! Пароль пользователя знает только MyCalApp. HireMe123 не запрашивает учетные данные пользователя. Проблемы с совместным использованием учетных данных и слишком большим доступом больше не являются проблемой.
А как насчет аутентификации?
На данный момент, я надеюсь, стало ясно, что OAuth предназначен для делегированного доступа. Это не распространяется на аутентификацию. В любой момент, когда аутентификация включалась в процессы, которые мы рассмотрели выше, вход в систему осуществлялся любым процессом входа в систему, который HireMe123 или MyCalApp реализовали по своему усмотрению. OAuth 2.0 не прописывал, как это должно быть сделано: он только покрывал авторизацию доступа сторонних API.
Так почему же аутентификация и OAuth так часто упоминаются вместе друг с другом?
Генерация ключевой пары с помощью устройства
В этом случае закрытый ключ не появляется в открытом виде, и нет риска, что злоумышленник украдёт его резервную копию. Единственный способ использования закрытого ключа — это обладание устройством аутентификации. Являясь наиболее безопасным, это решение выдвигает высокие требования к возможностям самого устройства: оно должно обладать функциональностью генерации ключей и осуществления криптографических преобразований. Это решение также предполагает, что закрытый ключ не может быть восстановлен в случае выхода устройства из строя, и т. п. Об этом необходимо беспокоиться при использовании закрытого ключа для шифрования, но не там, где он используется для аутентификации или в других службах, использующих цифровые подписи.
Классификация методов идентификации и аутентификации с точки зрения применяемых технологий представлена на рис. 2.
Рис.2. Классификация технологий идентификации и аутентификации
Association
Once the STA is authenticated to the access point, the next step is to become Associated. The Association occurs after the Shared Key Authentication or Open System Authentication Algorithm. There cannot be a STA that is Associated but not Authenticated. If the STA fails Authentication, it does not move to Association.
After the the access point sends an Acknowledgement to the STA’s Authentication Response, the STA sends an Association Request.
The Association Request is Acknowledged by the access point which then sends an Association Response frame to the STA.
If the association is successful, the access point’s Association Response frame will contain a Status code: Successful.
После того, как STA аутентифицирован для точки доступа, следующим шагом будет связывание. Ассоциация происходит после аутентификации с общим ключом или алгоритмов аутентификации открытой системы. Не может быть связанного, но не аутентифицированного STA. Если STA не проходит аутентификацию, он не переходит к ассоциации. После того, как точка доступа отправляет подтверждение на ответ аутентификации STA, STA отправляет запрос ассоциации. Точка доступа подтверждает запрос ассоциации, а затем точка доступа отправляет кадр ответа ассоциации на STA. Если ассоциация прошла успешно, кадр ответа точки доступа будет содержать код состояния: успех.
The details within an Association Response include:
- Capabilities Information such as
- Supported Data Rates
- HT Capabilities
- HT Information such as the Primary Channel
- WMM information
- And more..
If the Status code is anything other than Successful, then the STA is deauthenticated.
