Что такое sso аутентификация
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)
Технология единого входа (Single Sign-On, SSO) обеспечивает возможность использования одного идентификатора для доступа ко всем разрешенным ИТ-ресурсам и системам и позволяет решать задачи строгой и сквозной аутентификации пользователей.
SSO-решения централизованно хранят все пароли и автоматически обрабатывают запросы аутентификации по требованию ИТ-систем и/или веб-ресурсов, подставляя учетные данные пользователя (как правило, логин и пароль) и избавляя его таким образом от необходимости запоминать и вручную вводить эти данные.
Для того, чтобы осуществить вход в приложение, пользователю достаточно лишь предоставить данные для аутентификации, выполнив действия, соответствующие используемым способам аутентификации: получить одноразовый пароль, приложить палец к считывателю, подключить токен или смарт-карту и т.п. Учетные данные (логин и пароль) будут подставлены SSO-системой автоматически без участия пользователя.
Например, пройдя процедуру аутентификации в операционной системе, пользователь автоматически получает доступ к различным приложениям без необходимости многократного ввода данных своих учетных записей.
Таким образом, при использовании технологии Single Sign-On процедура аутентификации становится для пользователей значительно проще и удобнее. Исчезает не только необходимость запоминания множества логинов и паролей, но также необходимость их ручного ввода, что в свою очередь, существенно упрощает доступ к приложениям и снижает нагрузку на ИТ- и ИБ-службы, специалистам которых не нужно восстанавливать забытые пароли и доступ к ресурсам для заблокированных учетных записей.
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, про которую я не знаю.
Как работает single sign-on (технология единого входа)?
Что такое single sign-on?
Технология единого входа (Single sign-on SSO) — метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных.
Как работает SSO?
SSO базируется на настройке доверительных отношений между приложением, известным как провайдер услуг, и системой управления доступами, например, OneLogin. Такие доверительные отношения часто базируются на обмене сертификатом между системой управления доступами и провайдером услуг. Такой сертификат может использоваться, чтобы обозначить идентификационную информацию, которая отправляется от системы управления доступами провайдеру услуг, таким образом провайдер услуг будет знать, что информация поступает из надежного источника. В SSO идентификационные данные принимают форму токенов, содержащих идентификационные значения информации о пользователе такие, как email или имя пользователя.
Порядок авторизации обычно выглядит следующим образом:
Если пользователь попробует получить доступ к другому сайту, то понадобится настройка подобных доверительных отношений в соответствии с методом SSO. Порядок аутентификации в этом случае будет состоять также из вышеизложенных шагов.
Что такое токен в контексте SSO?
Токен — это набор информации или данных, который передается из одной системы в другую в процессе исполнения SSO. Данные могут быть просто email адресом и информацией о системе, отправившей токен. Токены должны обладать цифровой подписью для получателя, чтобы подтвердить, что он поступил из надежного источника. Сертификат для электронной подписи предоставляется во время первоначального этапа настройки.
Является ли технология SSO безопасной?
Ответом на этот вопрос будет «в зависимости от ситуации».
Есть несколько причин, по которым стоит внедрить SSO. Метод единого входа может упростить работу с логином и паролем, как для пользователя, так и для администратора. Пользователям больше не придется держать в голове все учетные данные, теперь можно просто запомнить один более сложный пароль. SSO позволяет пользователям намного быстрее получить доступ к приложениям.
SSO также сокращает количество времени, потраченного на восстановление пароля с помощью службы поддержки. Администраторы могут централизованно контролировать такие факторы, как сложность пароля и многофакторную аутентификацию (MFA). Администраторы также могут быстрее отозвать привилегии на вход в систему, если пользователь покинул организацию.
Однако, у SSO есть некоторые недостатки. Например, вероятно, вам захочется, чтобы определенные приложения оставались заблокированы/менее открыты к доступу. По этой причине важно выбрать то решение SSO, которое, к примеру, даст вам возможность запросить дополнительный фактор проверки аутентификации прежде, чем пользователь авторизуется или оградит пользователей от доступа к определенным приложениям пока не обеспечено безопасное соединение.
Как внедрить SSO?
Особенности внедрения SSO могут отличаться с учетом того, с каким именно решением SSO вы работаете. Но вне зависимости от способа, вам нужно точно знать какие цели вы преследуете. Убедитесь, что вы ответили на следующие вопросы:
Что отличает настоящую SSO от хранилища или менеджера паролей?
Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On — что означает “такой же/одинаковый вход”, а не “единый вход” (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.
С SSO, после того, как вы вошли в систему, вы можете получить доступ ко всем одобренным компанией сайтам и приложениям без необходимости авторизовываться снова. Это включает в себя как облачные, так и локально установленные приложения, часто доступные через сам сервис SSO (также известный, как сервис авторизации).
В чем разница между программным обеспечением единого входа и решением SSO?
Изучая доступные варианты единого входа, вы можете увидеть, что их иногда называют программным обеспечением единого входа, а не решением единого входа или провайдером единого входа. Часто разница состоит лишь в том, как позиционируют себя компании. Фрагмент программного обеспечения предполагает локальную установку. Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.
Бывают ли разные типы SSO?
Когда мы говорим о едином входе (SSO), используется множество терминов:
На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) — это характеристика/фича, доступная внутри архитектуры FIM.
OAuth 2.0 — это особая программная платформа, которая также может считаться частью архитектуры FIM. OAuth фокусируется на доверительных отношениях, предоставляя доменам идентификационную информацию пользователя.
OpenID Connect (OIDC) — это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.
Security Access Markup Language (SAML) — это открытый стандарт, который также разработан для обеспечения функциональности SSO.
Система Same Sign On, которую часто обозначают, как SSO, на самом деле, не похожа Single Sign-on, т.к не предполагает наличие доверительных отношений между сторонами, которые проходят аутентификацию. Она более привязана к идентификационным данным, которые дублируются и передаются в другие системы когда это необходимо. Это не так безопасно, как любое из решений единого входа.
Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Service Protocol (LDAP).
Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) — это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos. Таким образом, пользователи, относящиеся к ADDS могут аутентифицироваться с их устройств и получить доступ к другим системам, интегрированным с ADDS. Это и есть форма SSO.
Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.
Протокол LDAP (Lightweight Directory Service Protocol) — это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации. Но он часто применяется как часть процесса аутентификации и контроля доступа. Например, прежде, чем пользователь получит доступ к определенному ресурсу, LDAP сможет запросить информацию о пользователе и группах, в которых он состоит, чтобы удостовериться, что у пользователя есть доступ к данному ресурсу. LDAP платформа на подобие OpenLDAP обеспечивает аутентификацию с помощью аутентификационных протоколов (например, Simple Authentication и Security Layer SASL).
Как работает система единого входа как услуга?
SSO функционирует также, как и многие другие приложения, работающие через интернет. Подобные OneLogin платформы, функционирующие через облако, можно отнести к категории решений единого входа “Software as a Service” (SaaS).
Что такое App-to-App (приложение-приложение) SSO?
В заключение, возможно вы слышали о App-to-App SSO. Пока еще такой подход не является стандартным. Такое понятие больше используется SAPCloud для обозначения процесса передачи идентификационных данных пользователя из одного приложения в любое из других, состоящих в их экосистеме. В какой-то степени такой метод присущ OAuth 2.0, но хочется снова подчеркнуть, что это не стандартный протокол или метод. В настоящее время он является характерным только для SAPCloud.