Google sso что это
Добрый день! Уважаемые читатели и гости одного из посещаемых IT блогов Рунета Pyatilistnik.org. В прошлый раз мы с вами подробно разобрали реальные примеры использования утилиты Robocopy. Мне понравилось, что статья получила столько отзывов и комментариев. Сегодня я хочу вас научить производить настройку SSO в Google Chrome, чтобы пользователи не вводили свои учетные данные, а сразу попадали на корпоративные ресурсы, тем самым экономя свое время, мы поговорим про сквозную авторизацию.
Для чего нужна сквозная аутентификация в Google Chrome
Когда у вас в компании уже построена инфраструктура на базе домена Active Directory, то это подразумевает использование одной учетной записи на всех сервисах компании. Так как сейчас у сотрудника не обязательно есть только компьютер, у него может быть рабочий, планшет, телефон, ноутбук. Все эти устройства давно так же заводятся в домен и управляются централизовано. Когда вы включаете в компании политику стойкости пароля (PSO), то тем самым вы вынуждаете сотрудника делать его пароль очень сложным. Это за собой влечет сложность ввода учетных данных на мобильных устройствах, отнимая время вашего хелпдеска. Дабы всем упростить жизнь, есть такое понятие, как SSO (Single Sign On), если перевести на русский, это это единая точка входа.
Идея сквозной аутентификации очень проста, вы входите один раз под своей корпоративной учетной записью на устройство, а далее все сервисы компании на которых настроена SSO, для вас доступны без ввода логина и пароля. Согласитесь, что это очень удобно. Так мы например, недавно производили настройку SSO для ManageEngine ServiceDesk или для vCenter Server. Благодаря этому могу выделить плюсы:
Методы настройки SSO в Google Chrome
Я могу выделить вот такие методы сквозной аутентификации в данном браузере:
Параметры управления белым списком сайтов для SSO
В Google Chrome есть ряд настроек, которые отвечают за автоматический sso login.
Настройка встроенной аутентификацию Windows в Google Chrome локально
Данный метод позволит вам локально настроить ваш Google Chrome для входа на нужный ресурс с помощью встроенной аутентификацию Windows (сквозная авторизация). Открываем командную строку от имени администратора и вводим команду, в моем примере я буду настраивать вход без ввода учетных данных для ресурса https://pyatilistnik.org.
Пробуем теперь перезапустить ваш браузер и проверить автоматический вход на нужный вам сервис. Обратите внимание, что в итоге задали все те же две настройки auth-server-whitelist и auth-negotiate-delegate-whitelist.
Настройка сквозной авторизации через реестр
Выше мы выяснили, что у хрома есть два параметра auth-server-whitelist и auth-negotiate-delegate-whitelist. Оба параметра являются всего лишь ключами реестра Windows. Вот вам две ветки реестра, где вы найдете нужные ключи реестра.
Тут должны быть ключи с типом REG_SZ. Все записи начинаются со знака *.имя домена и перечисляются через запятую. После внесения или создания данных ключей, вам нужно перезапустить Google Chrome.
Настройка встроенной аутентификацию Windows в Google Chrome через GPO
Когда у вас большая компания и огромный штат сотрудников, вам для быстрого распространения настроек, подойдет использование объектов групповой политики. Для этого у вас должен быть создан центральный репозиторий политик и скопирован в него последний набор ADMX шаблонов для Google Chrome.
Как импортировать шаблон настроек Google Chrome в ваш репозиторий, я уже подробно рассказывал, смотрим по ссылке. Создаем новый объект GPO или используем уже существующий. Напоминаю, что все настройки вы можете применять, как к компьютерам, так и к пользователям. Я буду применять к сотрудникам, перейдите в раздел:
Вводим тут сервер через запятую.
Далее вы обновляете групповые политики у пользователя на рабочей станции и можете проверить сквозную аутентификацию. Так же в Google Chrome, в адресной строке введите адрес chrome://policy/. Тут вы можете увидеть прилетевшие политики. Так же есть кнопка обновления «Повторно загрузить политики».
Настройка SSO в Google Chrome для Azure
Если вы произвели интеграцию вашего Active Directory в облако Azure, то для работы Single Sign On есть расширение «Windows 10 Accounts«. Используйте это расширение для входа на поддерживаемые веб-сайты с учетными записями в Windows 10. Если у вас есть удостоверение, поддерживаемое Microsoft, в Windows 10, вам не потребуется вводить учетные данные для входа на поддерживаемые веб-сайты. Вам нужно будет использовать это расширение, если ваша организация внедрила политику условного доступа. В настоящее время это расширение поддерживает удостоверения Azure Active Directory.
Администрирование рабочего пространства
Узнайте, как управлять рабочим пространством Slack или организацией Enterprise Grid.
Единый вход с использованием Google Workspace
Примечание. Если возникли проблемы с настройкой единого входа на основе SAML, см. статью Устранение проблем с авторизацией на основе SAML.
Совет. Владельцы рабочего пространства и владельцы организаций могут обходить аутентификацию SSO. Для этого нужно перейти по ссылке в нижней части страницы входа в систему и ввести адрес электронной почты и пароль. Это гарантирует доступ к рабочему пространству или организации даже в случае проблем у IDP.
Аутентификация Google в сравнении с Google SAML
В таблице ниже показаны поддерживаемые настройки единого входа для каждого из вариантов.
| Аутентификация Google | Google SAML | |
| Синхронизация профиля* | ✓ | ✓ |
| Добавление пользователей при регистрации | ✓ | ✓ |
| Аутентификация с использованием нескольких доменов электронной почты** | ✓ | ✓ |
| Предварительное добавление пользователей | ✓ | |
| Собственные поля профиля SCIM | ✓ | |
| Автоматическое отключение пользователей | ✓ | |
| Основанный на правилах доступ в поставщике удостоверений | ✓ | |
| Поддержка Enterprise Grid | ✓ |
* Аутентификация Google синхронизирует только адреса электронной почты и отображаемые имена. Google SAML синхронизирует адреса электронной почты, отображаемые имена, имена и фамилии.
** При использовании аутентификации Google дополнительные домены нужно вводить вручную. В Google SAML это делается автоматически.
Настройка аутентификации Google
Планы Pro и Business+
План Enterprise Grid
Владельцы рабочего пространства могут получать доступ к параметрам единого входа с использованием аутентификации через Google Workspace и настраивать их. Вот как это делается.
Аутентификация с использованием Google Workspace недоступна с планом Enterprise Grid.
Совет. Чтобы утвердить дополнительные домены для создания аккаунтов участников, напишите нам. Мы поможем вам добавить новые домены или удалить имеющиеся.
Настройка Google SAML
План Enterprise Grid
Шаг 1. Настройка поставщика удостоверений
Шаг 2. Настройка единого входа для рабочего пространства
Шаг 1. Настройка поставщика удостоверений
Примечание. Когда вам будет предложено указать URL-адрес ACS, введите URL-адрес организации с планом Enterprise Grid (например, https://domain.enterprise.slack.com/sso/saml).
Шаг 2. Настройка единого входа для организации
После включения единого входа с использованием Google Workspace
После активации Google Workspace участники могут по-прежнему переходить по URL-адресу вашего рабочего пространства. Вот как это работает.
Управление единым входом с использованием Google Workspace
Переключение доменов Google Workspace
В случае изменения домена электронной почты или переключения с одного экземпляра Google Workspace на другой вы можете обновить свой домен Google Workspace, выполнив следующие действия.
Планы Pro и Business+
План Enterprise Grid
Владельцы и администраторы организации могут изменять свой домен Google Workspace с помощью поставщика удостоверений, используя аккаунт администратора Google.
Изменение адресов электронной почты
Владельцы рабочего пространства и организации могут изменять адреса электронной почты участников и управлять этими адресами. Но сначала это нужно разрешить в параметрах рабочего пространства.
Планы Pro и Business+
План Enterprise Grid
Теперь можно изменить адреса электронной почты на странице Участники.
Теперь можно изменить адреса электронной почты на странице Участники.
Совет. Чтобы выполнить массовое изменение адресов электронной почты, обратитесь к нам. Мы готовы помочь.
Добавление и удаление пользователей
При использовании единого входа на основе SAML администраторы Google Workspace могут управлять добавлением пользователей с помощью SAML-приложения Slack. Оно находится в разделе Приложения в консоли администратора Google.
Если вы хотите пообщаться со специалистом службы поддержки, напишите по адресу feedback@slack.com.
Если вы хотите пообщаться со специалистом службы поддержки, напишите по адресу feedback@slack.com.
Если вы хотите пообщаться со специалистом службы поддержки, напишите по адресу feedback@slack.com.
Ой! У нас сложности. Повторите попытку позже.
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.
