App sso agent что это
Fortinet Single Sign-On. Описание технологии
Приветствуем! На протяжении всего времени нашей работы с решениями компании Fortinet, а в частности с межсетевым экраном нового поколения FortiGate, одним из самых интересующих вопросов является контроль и отслеживание трафика отдельных пользователей или групп пользователей. Сегодня мы хотим подробно рассказать о механизме прозрачной аутентификации пользователей на межсетевом экране FortiGate с помощью технологии Fortinet Single Sign-On. Данная статья будет посвящена именно теоретическому аспекту FSSO, поскольку в данном случае без теории тяжело разобраться, что происходит на практике.
FSSO для Windows AD использует коллектор агента. Агенты для контроллеров домена (DC агент) также могут использоваться, в зависимости от режима работы коллектор агента. Существует два основных режима работы: DC Agent Mode (режим, в котором используются DC агент) и Polling Mode (в этом режиме используются только коллектор агенты). Также на FortiGate может использоваться Polling режим, который не требует установки сторонних агентов на сервера. Однако, данный вариант подходит только для простых сетей с минимальным количеством пользователей.
Для начала рассмотрим режим DC Agent Mode. Данный режим является рекомендованным для FSSO. Для него требуется:
Схема работы FSSO в режиме DC Agent Mode представлена на рисунке ниже:
При аутентификации пользователя DC агент перехватывает запись о входе на контроллере домена.
Затем DC агент выполняет DNS запрос для определения IP адреса пользователя и передает полученную информацию на коллектор.. После того, как коллектор получает информацию, он снова выполняет DNS запрос для того, чтобы определить, был ли изменен IP адрес пользователя.
После этого, вся информация о пользователе передается на FortiGate.
После того, как коллектор передал всю информацию о пользователе, FortiGate знает этого пользователя, его IP адрес и группы, к которым он принадлежит. Когда пользователь пытается получить доступ к интересующим его сетевым ресурсам (в том числе и к Интернету), FortiGate сравнивает IP адрес источника с IP адресами, находящимися в списке активных FSSO пользователей. Поскольку пользователь уже авторизован в домене, и FortiGate содержит информацию о нем, пользователь не будет авторизовываться повторно. Вместо этого, доступ данного пользователя к интересующему ресурсу будет разрешен или запрещен в зависимости от политики безопасности, под которую попадает трафик данного пользователя.
NetAPI: Агент обращается к временным сессиям, созданным на контроллере домена в момент входа пользователей в домен, и вызывает функцию NetSessionEnum. Данный метод работает быстрее остальных, однако он может пропустить некоторые события входа при высокой нагрузке контроллера домена. Это связано с тем, что при высокой нагрузке сессии могут удаляться из оперативной памяти до того, как агент успеет к ним обратиться и передать информацию на FortiGate.
WMI: Агент с помощью Windows API получает системную информацию с контроллера домена. Контроллер домена по запросу возвращает все требуемые события входа пользователей в домен. Данный способ позволяет уменьшить нагрузку канала между коллектор агентом и контроллером домена.
Схема работы Collector Agent-Based Polling режима представлена на рисунке ниже:
Пользователь аутентифицируется в домене, предоставляя свои учетные данные на контроллер домена;
Коллектор агент периодически (раз в несколько секунд) опрашивает контроллер домена на предмет наличия событий входа пользователей в домен;
Коллектор агент посылает полученную информацию на FortiGate;
Поскольку пользователь уже авторизован в домене, и FortiGate содержит информацию о нем, пользователь не будет авторизовываться повторно. Вместо этого, доступ данного пользователя к интересующему ресурсу будет разрешен или запрещен в зависимости от политики безопасности, под которую попадает данный трафик.
Требуется больше системных ресурсов;
Схема работы данного режима представлена на рисунке ниже.
FortiGate опрашивает контроллер домена для получения событий входа пользователей в систему.
После аутентификации пользователя на контроллере домена, FortiGate получает это событие во время следующего опроса в совокупности со следующей информацией: имя пользователя, имя машины, IP адрес. Затем, он запрашивает группы пользователей, о которых получил информацию.
Когда пользователь пытается получить доступ к сетевому ресурсу, FortiGate уже имеет всю необходимую информацию о данном пользователе, и пользователю не нужно аутентифицировать повторно. Вместо этого, доступ данного пользователя к интересующему ресурсу будет разрешен или запрещен в зависимости от политики безопасности, под которую попадает трафик данного пользователя.
Подведем итоги, выделив основные отличия в режимах DC Agent Mode и Polling Mode:
FSSO в режиме DC Agent Mode сложнее в инсталяции. Он требует установки коллектор агента, а также DC агента на каждый контроллер домена, в котором мониторятся события входа в систему. Но в то же время этот режим является более масштабируемым, поскольку работа по захвату событий входа реализуется DC агентами, которые и передают данную информацию на коллектор агент.
Также, в режиме DC Agent Mode необходимые события собираются один раз и отправляются на привязанные коллектор агенты. Поэтому, события входа пользователей не упускаются. А в режиме Polling Mode, некоторые события входа могут быть пропущены, или при их передаче может возникнуть задержка.
Для удобства, основные отличия в режимах были сведены в таблицу:
Требуется ли DC агент
Высокий уровень масштабирования
Низкий уровень масштабирования
Уровень захвата событий
Захватываются все события
Некоторые события могут быть пропущены (NetAPI) или могут быть переданы с задержкой (WinSecLog)
На этом теоретическая часть, посвященная технологии FSSO, закончена. В следующий раз мы осветим именно практические аспекты данной технологии. Чтобы не пропустить новых материалов, следите за новостями на наших каналах:
Программа-агент Single Sign-on
Решение Zyxel SSO
Решение Zyxel SSO
Для внедрения в вашу сеть механизма аутентификации single sign-on на основе приставок безопасности Zyxel требуется SSO Agent и устройство Next-Gen USG либо межсетевой экран ZyWALL VPN.
Информация о Single Sign-On (SSO)
При аутентификации пользователя на компьютере, подключенном к сети, он должен ввести свое имя и пароль. Если аутентификация Active Directory используется на приставках безопасности Zyxel для блокировки исходящего сетевого трафика для всех пользователей за исключением для определенных пользователей или групп пользователей, то последние должны выполнить дополнительную процедуру для того, чтобы их исходящий трафик не блокировался: они должны вручную пройти аутентификацию на приставке безопасности Zyxel и только после этого смогут получить доступ к сетевым ресурсам или Интернету. Механизм Single Sign-On (SSO) упрощает процедуру аутентификации пользователей. При использовании SSO пользователи из достоверных (trusted) или дополнительных сетей только один раз предъявляют свои авторизационные данные (credentials) (которые они используют для доступа к своему компьютеру), после чего они автоматически аутентифицируются устройством USG.
Преимущества
Информация о SSO Agent
Для использования SSO необходимо установить SSO Agent на сервере, на котором работает контроллер домена Microsoft Active Directory. SSO Agent работает как учетная запись пользователя домена с привилегиями Domain Admin (администратора домена). Пользуясь этими привилегиями, SSO Agent при попытке пользователя пройти аутентификацию в домене сети считывает авторизационные данные пользователя с его компьютера и передает их приставке безопасности Zyxel. При инсталляции SSO Agent необходимо убедиться, что он будет работать как пользователь с привилегиями Domain Admin.
* License subscription fee and permits may vary by country.
Single Sign-On, или Танцы Шестерых
Материал прозаичен, но может оказаться кому-нибудь полезным, чему я буду очень рад. Ещё больше буду признателен конструктивным советам и отзывам.
Итак, наша тема – «Как реализовать Single Sign-On для веб-приложения в условиях разношёрстности и нормальной лохматости системного зоопарка».
Single Sign-On. Вводная
Доверился кому, так доверяй во всём.
© Цецилий Стаций
Для тех, кто не в курсе (хотя они вряд ли станут читать этот материал), скажу, что Single Sign-On (в дальнейшем повествовании – «SSO») в общепринятом представлении не является ни технологией, ни тем более неким магическим протоколом. SSO – это подход, метод, позволяющий реализовать связность AAA (Authentication & Authorization & Accounting) между разнородными системами и приложениями без дополнительных телодвижений со стороны конечного пользователя.
Типичными примерами SSO являются, например, решения, построенные целиком на продуктах Microsoft; в этом случае сервер(ы) Active Directory обеспечивают не только хранение каталога, но и управляют поведением подключенных к домену рабочих станций, установленным на них софтом и всем прочим, вплоть до железа (мы же все умеем запрещать политиками тот же USB). Сквозная парадигма AAA в такой ситуации обеспечивается почти автоматически при использовании продуктов Microsoft, то есть в гомогенной среде.
В качестве примеров:
Аксиома
Задача
Сразу оговорюсь, что есть и более простые пути решения этой задачки, помимо описанного ниже, но мы же их не ищем. Ну и требования Заказчика были не самые однозначные.
Танцуем с Пингвинами. Linux
Домен: Эукариоты, Царство: Животные, Подцарство: Эуметазои, Тип: Хордовые, Подтип: Позвоночные, Инфратип: Челюстноротые, Надкласс: Четвероногие, Класс: Птицы, Подкласс: Новонёбные, Отряд: Пингвинообразные, Семейство: Пингвиновые, Вид: Oracle Linux Server release 7.2
Установка
Нам достался вполне оперившийся потомок/клон RHEL под именем Oracle Linux Server release 7.2.
Настройка
Как всегда, Линукс в его серверном виде прост, беззаботен и безотказен, но нам важно убедиться, что он правильно сконфигурирован, особенно в части сетевых настроек.
Тестирование
Сначала смотрим на настройки DNS, т.к. это критично для работоспособности всего решения:
На этом этапе необходимо проверить доступность серверов DNS (которые, в нашем случае, являются и домен-контроллерами). Сделать это можно по-разному, просто используйте свои любимые утилиты и методы проверки (host, dig, telnet, ping, …). Важно, чтобы нужные нам порты были доступны и работоспособны, а в случае DNS это в первую очередь TCP/53. И не забываем про кощунство и жадность сетевых администраторов и безопасников (я сам такой), которые могут закрыть вам всё, включая ICMP, и оставить только парочку затребованных и согласованных портов. Что есть правильно.
Собачий вальс. Kerberos
Це́рбер, также Ке́рбер (от др.-греч. Κέρβερος, лат. Cerberus) — в греческой мифологии порождение Тифона и Ехидны (Тартара и Геи), трёхголовый пёс, у которого из пастей течёт ядовитая смесь. Цербер охранял выход из царства мёртвых Аида, не позволяя умершим возвращаться в мир живых. Однако это удивительное по силе существо было побеждено Гераклом в одном из его подвигов.
Уверен, что не нужно напоминать про необходимость правильной настройки Kerberos для «плодотворного сотрудничества» с MSAD.
Разумеется, для установки и конфигурирования вам необходимы root’овые права на сервере. Или sudo. Или «Звоните Солу».
Установка
Установка и настройка необходимых пакетов производится довольно просто, если «злые сетевые админы» дали вашему серверу выход в Интернет.
К сожалению, Интернет с доступом к репозиториям нужен на этапе установки, если добрые админы не установили всё нужное заблаговременно.
И всё печально, если нет ни доступа, ни установленных пакетов.
Однако будем оптимистами и, считая, что админы хотя бы на часик открыли канал, выполняем установку:
Само собой, как используемый менеджер пакетов, так и их версии у вас могут быть другими, но сути дела это не меняет.
И Да, обещаю, что более таких наиполнейших листингов тривиальной установки в статье не появится.
Настройка
Вполне работающий файл конфигурации Kerberos изначально будет выглядеть примерно так:
Тестирование
На следующем шаге у нас, как правило, всё происходит очень просто.
Просто убеждаемся, что всё плохо:
Зовём специалистов по трёхголовым собачкам (AKA сисадмина, знающего сверхсекретный доменный админский логин/пароль), и просим его ввести его примерно вот так:
После этого klist должен вернуть уже что-то осмысленное.
Засим нашу собачку считаем готовой, хотя…
Общеизвестно, что Ниссан – это невыгулянный Пассат.
Танец Великих Равнин. Apache
Апачи – собирательное название для нескольких культурно родственных племён североамериканских индейцев, говорящих на апачских языках атабаскской ветви семьи на-дене.
Апачи создали свой собственный захватывающий танец в масках по названию гахан, которым они празднуют достижение совершеннолетия девочками. Также у апачей и поныне есть танцевальные обряды для видений и предсказаний.
Начинаем охотиться вместе с индейцами племён Апачи.
Установка
Как и прежде, пакеты – это наше всё (за исключением всемогущих шаманов-Админов, разумеется):
Настройка
Этого, конечно, недостаточно, потому что свежеустановленный индеец не знает нашего языка. Сконфигурируем его примерно так:
И дадим “пиночек под задочек”:
Убедимся, что он научился разговаривать по-нашенски, зайдя в System Management Portal.
Апачи некогда были гордым и независимым народом, у них это в крови, поэтому со всем уважением и вежливостью попросим Apache браться за работу вместе с нашим Пингвином-Прорицателем:
Прослушавши “Пионерскую Зорьку”, сделав водные процедуры, выгулявши трёхглавую собачку и причесав индейца, переходим к “Производственной Гимнастике”, которая сегодня будет танцевальной (и даже с бубнами).
Танцуем Самбу!
Са́мба (порт. samba) — бразильский танец, символ национальной идентичности бразильцев. Танец обрёл мировую известность благодаря бразильским карнавалам. Одна из разновидностей самбы вошла в обязательную пятёрку латиноамериканской программы бальных танцев. Исполняется в темпе 50-52 удара в минуту, в размере 2/4 или 4/4.
Как всем нам прекрасно известно, наша любимая Samba в серверном варианте совершенно логично разделена на три основных исполняемых модуля: (smb|nmb|winbind)d.
Теоретически нам нужен только работоспособный winbindd. Да, это всего лишь один из демонов Самбы. Но он, установленный отдельно от всего пакета, почему-то на имеющейся платформе работать не захотел, а разбираться в причинах его недовольства не захотелось уже мне.
Поэтому устанавливаемся по полной.
Установка
Процедура очень проста, особенно, если ваш(а) Админ(ша) танцует вместе с вами.
Костюмчик готов, затягиваем галстук:
Настройка
Мало прийти на карнавал, нужно ещё и немного потанцевать (уже с бубнами):
Репетируем первые шаги (разумеется, ошибаемся на первых порах):
Зовём на помощь учителей танца, и («Как много нам открытий чудных. ») это оказываются те же самые кинологи, помогавшие нам в приручении нашего трёхглавого щеночка!
И надеемся на чудо… Всё зависит от рук и от места, откуда они растут…
«Разлук так много на земле.
И разных судеб,
Надежду дарит на заре.
Паромщик людям”
© Prodigy & Rammstein, 2048
Если затем видим примерно вот такое:
то Счастье уже почти Есть!
Тестирование
Проверяем его (Счастья) наличие:
Медляк. mod_auth_ntlm_winbind
Прежде чем танцевать медленный танец, придется кого-то на него пригласить, ведь в одиночку под него двигаться не считается приемлемым. Улучите момент и подойдите к приглянувшейся девушке. Собравшись танцевать медленный танец, объявите о своем намерении потенциальной партнерше прямо, без ненужного многословия. Не будьте излишне развязны и напористы, оставьте за ней решение, согласиться или нет. В последнем случае она откажется, но поблагодарит вас.
Установка
Найдите в Сети живой репозиторий с mod_auth_ntlm_winbind.
Да, их мало живых (я забрал с какого-то svn).
Да, версии совсем не новые.
Да, вам нужно будет их собрать «вручную».
Да, не все соберутся.
Да, даже после патчей и правок вручную.
Да, для сборки понадобится полностью настроенное окружение (gcc + glib + apxs + headers + *-dev + …).
И ДА, это – единственный известный мне вариант, который работает стабильно.
Настройка
С настройкой всё более-менее элементарно, добавьте в ваш конфиг-файл Apache (в основной, либо в conf.d/xyz.conf, по желанию):
Разумеется, пути должны быть указаны правильно для вашей инсталляции, как и все прочие параметры.
Для первоначальной отладки советую раскомментировать строчку LogLevel, тогда в файлы протоколов Apache будут записываться дополнительные и иногда очень полезные сообщения.
Белый танец. Кто кого.
Leicht versprochen, leicht gebrochen.
На очень закономерный и весьма своевременный (к концу статьи-то!) вопрос «А нафига мы всё это делали?» отвечу, что всё это всего-то ради одной строчки в серверном ответе HTTP.
Бочка мёда
Нам нужен верный автоматически передаваемый веб-сервером REMOTE_USER (или HTTP_REMOTE_USER – не суть важно), чтобы:
После этого мы запросто сможем с серверной стороны используя, например, LDAP-доступ к AD, запросить иные реквизиты этого пользователя (членство в группах, и т.п.).
Про эту механику планируется отдельная статья, там есть свои тонкости.
Парочка ложек дёгтя
Single Sign-On. Выводная
Я буду весьма признателен, если подскажете в комментариях более удачную конфигурацию; допускаю даже, что появилась новая механика взаимодействия AAA для связки Linux + Apache + MSAD, про которую я не знаю.
App sso agent что это
Обзор: Средства защиты информации и бизнеса 2014
Мобильные технологии в корпоративном сегменте активно развиваются уже достаточно давно, хотя пока не получили массового распространения, но преимущества использования мобильных устройств для решения бизнес-задач ни у кого не вызывают сомнений. За исключением, наверное, специалистов по информационной безопасности, которые традиционно скептически относятся к безопасности всех ИТ-новинок.
Тема безопасности мобильных технологий далеко не нова. Много копий сломано вокруг концепции BYOD (bring your own device) и контроля мобильных устройств, популярна тема шифрования данных и удаленного управления, а также безопасного доступа к информационным ресурсам компании. Доступ должен быть обеспечен для любой платформы, используемой как на рабочей станции пользователя, так и на мобильном телефоне или планшете. Усиленная аутентификация, в том числе с использованием дополнительных факторов, должна происходить на компьютере и мобильном устройстве, иначе мобильность будет слабым звеном в контуре безопасности организации. При этом меры обеспечения ИБ не должны создавать неудобства для пользователей. В противном случае новые технологии не найдут у них поддержки, и организация не достигнет запланированных показателей повышения эффективности работы за счет их использования.
На сегодняшний день одной из современных тенденций в области аутентификации является использование SSO. Это удачный компромисс между безопасностью доступа к приложениям и удобством работы пользователя. Идея этой технологии заключается в обеспечении единой аутентификации для всех информационных систем организации, которые с точки зрения доступа являются разнородными и никак не интегрированы между собой или с общей службой каталогов, например, Microsoft Active Directory. Т.е. вместо ввода логина и пароля для каждого приложения достаточно один раз пройти аутентификацию, например, при входе в домен. Это очень удобно для пользователя, которому не надо запоминать много разных и сложных паролей, а затем менять их хотя бы раз в полгода. Кроме того, подобное решение повышает уровень информационной безопасности в части парольной политики, так как пароли к приложениям могут быть более длинными и сложными и чаще меняться, что снижает риск брутфорсинга.
Аутентификация – одна для всех
Несмотря на общую идею SSO-технологии, существует несколько подходов в ее реализации. Первый из них заключается в организации общего сервиса аутентификации для всех приложений, который интегрируется с ними и обеспечивает единую и однократную аутентификацию. Ключевой момент такого подхода – это интеграция с приложениями на основе стандартных протоколов, например, Kerberos, SAML, OpenID, OAuth и т.п. Конечно, у каждого из этих протоколов есть своя специфика, но в целом они решают общую задачу – использование однократной аутентификации (SSO) для доступа во все приложения.
Наиболее распространенным вариантом такого подхода в ИТ-инфраструктурах, построенных на базовых продуктах Microsoft, является интеграция приложений со службой каталогов Microsoft Active Directory и использование стандартного протокола аутентификации Kerberos. Этот подход внедрения SSO c использованием стандартных протоколов аутентификации для интеграции приложений является, безусловно, более системным, но далеко не всегда реализуемым, так как процесс интеграции зачастую подразумевает доработки непосредственно в информационных системах. Поэтому, как правило, такой подход применим в развитых ИТ-инфраструктурах, где любое приложение изначально поддерживает внешнюю аутентификацию с использованием промышленных стандартов. К сожалению, в России это скорее исключение, чем правило, поэтому применимость этого подхода весьма ограничена.
Что касается мобильных платформ, то чаще всего такой подход применяется для web-приложений, где механизм аутентификации не зависит от устройства, с которого пользователь получает доступ. Т.е. SSO-аутентификация, организованная для web-приложений, будет работать на любом из этих устройств, и с точки зрения мобильных платформ специфика минимальна. В случае с нативными приложениями все не так однозначно, и организация SSO-аутентификации может потребовать их доработок. Хотя использование стандартных протоколов и отсутствие необходимости установки дополнительного ПО как на рабочую станцию, так и на мобильное устройство – несомненный плюс.
Автоматическая подстановка
Второй подход не требует значительных интеграционных работ и не подменяет внутренние механизмы аутентификации самих приложений. Основная суть данного подхода заключается в перехвате окна аутентификации приложения по его идентификатору и подстановке пары логин/пароль, соответствующих данному приложению, из защищенного профиля пользователя. Т.е. при аутентификации осуществляется автоматический ввод идентификационных данных пользователя вместо ручного ввода, сам механизм аутентификации остается прежним.
В целом с точки зрения пользователя процесс выглядит следующим образом. Пользователь при входе на компьютер осуществляет logon в операционной системе. Если рассматривать вариант инфраструктуры Microsoft, то он вводит доменный логин или пароль. Как правило, SSO-решения позволяют использовать различные факторы аутентификации, в том числе токен, смарт-карта, биометрия, одноразовые пароли и т.д., но для начала можно рассмотреть самый примитивный вариант – пару логин/пароль. После входа на компьютер пользователь запускает бизнес-приложение. Появляется окно аутентификации приложения, которое автоматически перехватывается специализированным программным SSO-агентом. SSO-агент подставляет в окно аутентификации из защищенного профиля пользователя его логин и пароль для данного приложения. Приложение осуществляет аутентификацию согласно своим стандартным протоколам.
Основная сложность такого подхода – автоматизация смены паролей и записи их в профиль пользователя. Необходимость самостоятельной смены паролей пользователями для каждого приложения и записи их в свой профиль снижает эффективность данной технологии, хотя такие реализации тоже встречаются.
Промышленным вариантом такого подхода является интеграция SSO-сервиса с приложениями, где он, используя стандартную функциональность приложений по управлению паролями, меняет их по заданному графику и с необходимым уровнем сложности и записывает новые пароли в профиль пользователя. Профиль пользователя при следующей аутентификации синхронизируется с хранилищем на рабочей станции или токене пользователя.
Особенности SSO для мобильных устройств
В части применения данного подхода на мобильных устройствах есть свои плюсы и минусы. Сама схема такой SSO-реализации на мобильной платформе не сильно отличается от полноценных рабочих станций. Для ее работы нужен нативный SSO-агент, который обеспечит подстановку пары логин/пароль в окна аутентификации мобильных приложений. С точки зрения интеграции дополнительное появление мобильных приложений в готовой SSO-инфраструктуре для рабочих станций не обременит заказчика серьезными трудозатратами. Но далеко не всегда производители SSO-решений готовы предоставить полный набор готовых полнофункциональных SSO-агентов для всех популярных мобильных операционных систем, и здесь ограничения являются зачастую организационными.
Классическим примером этого является операционная система iOS компании Apple. Чтобы разработать приложение и легитимно устанавливать его на устройствах Apple, необходимую пройти соответствующую процедуру регистрации производителя и сертификации разрабатываемого программного обеспечения. Данная процедура далеко не однозначна, требует значительного времени и трудозатрат. В противном случае остается только один путь – это jailbreak, что не подходит большинству пользователей iPhone и iPad, для которых корректность работы устройства и поддержка его производителем превыше преимуществ корпоративной SSO.
В случае с Android и Windows все намного проще, и функциональность SSO ограничивается только фантазией, потребностями заказчиков и компетентностью разработчика. С учетом сопоставимой с iOS популярности этих платформ, это уже неплохой результат. По статистике топ-менеджмент предпочитает устройства Apple, и, стремясь достичь удобства использования личных гаджетов для корпоративных целей, можно столкнуться с описанными ранее трудностями.
Еще одна особенность, связанная с SSO на мобильных устройствах, касается факторов аутентификации. В случае с рабочими станциями основными из них являются аппаратные USB-токены и смарт-карты, которые используют стандартные порты и протоколы. Для мобильных устройств такие факторы малоприменимы, и дело здесь не только в специфике аппаратного и программного подключения (хотя реализации подключения токенов через адаптер уже встречаются), но и в громоздкости конечной конструкции, что противоречит самой идеологии компактности и удобства мобильного устройства.
Выходом из сложившейся ситуации во многом является использование «программных» факторов аутентификации, таких как одноразовый пароль и его последующие концепты. Справедливости ради стоит отметить, что для аутентификации стали применяться и беспроводные технологии, например, использование bluetooth-токенов c возможностью подключения и по USB. Т.е. комбинированный вариант, который можно использовать и для рабочих станций, и для мобильных телефонов и планшетов. Некоторые производители мобильных устройств уже встраивают в них биометрические сканеры, поэтому использование этого функционала для SSO-аутентификации в мобильных приложениях также не за горами.
В заключение хочется отметить, что на текущее время рынок информационной безопасности не может похвастаться сформированным сегментом мобильной SSO-аутентификации. Это связано не только с организационными и технологическими ограничениями, но, по большей части, – с недостаточным пока спросом российских корпоративных пользователей. Ведь сейчас далеко не каждая организация использует SSO-технологии даже в классической офисной ИТ-инфраструктуре. Но с ростом числа корпоративных мобильных приложений неминуемо встанет проблема комплексной аутентификации с обеспечением необходимого уровня безопасности и удобства для пользователя.