saml sso что это

Протокол единого входа SAML

В этой статье рассматриваются запросы и ответы аутентификации SAML 2.0, которые поддерживаются Azure Active Directory (Azure AD) для единого входа.

На схеме протокола ниже описана последовательность единого входа. Облачная служба (поставщик услуг) использует привязку перенаправления HTTP для передачи AuthnRequest (запроса проверки подлинности) в Azure AD (поставщику удостоверений). Затем Azure AD использует привязку HTTP POST, чтобы опубликовать элемент Response в облачной службе.

В этой статье рассматривается использование SAML для единого входа. Дополнительные сведения о других способах управления единым входом (например, с помощью OpenID Connect или Встроенной проверки подлинности Windows) см. в статье Единый вход в приложения в Azure Active Directory.

AuthnRequest

Чтобы запросить проверку подлинности пользователя, облачные службы отправляют элемент AuthnRequest в Azure AD. Пример SAML 2.0 AuthnRequest должен выглядеть примерно так:

Издатель

NameIDPolicy

Элемент NameIdPolicy выглядит так:

RequestAuthnContext

Scoping

Сигнатура

Элемент Signature в элементах AuthnRequest не является обязательным. Azure Active Directory не проверяет подписанные запросы проверки подлинности при наличии подписи. Проверка запрашивающей стороны предоставляется только в ответах для зарегистрированных URL-адресов службы обработчика утверждений.

Ответ

После успешного выполнения запрошенного входа Azure AD отправляет ответ в облачную службу. Ответ на успешную попытку входа может выглядеть следующим образом:

Ответ

Издатель

Например, ответ с элементом Issuer может выглядеть следующим образом:

Состояние

Ниже приведен пример ответа SAML на неудачную попытку входа.

Assertion

Издатель

Сигнатура

Azure AD подписывает утверждение в ответ на успешный вход. В элементе Signature содержится цифровая подпись, которую может использовать облачная служба для проверки подлинности источника, чтобы проверять целостность утверждения.

Чтобы создать цифровую подпись, Azure AD использует ключ подписывания в элементе IDPSSODescriptor документа метаданных.

Условия

Этот элемент указывает условия, определяющие приемлемое использование утверждений SAML.

Атрибуты NotBefore и NotOnOrAfter указывают интервал, в течение которого утверждение допустимо.

Аудитория

AttributeStatement

AuthnStatement

Этот элемент служит утверждением того, что проверка подлинности субъекта утверждения выполнена определенным средством в определенное время.

Источник

Делимся опытом по интеграции SSO средствами SAML 2.0

1. Предыстория

Не смотря на то, что функция централизованного входа (Single Sign On, SSO) существует, обсуждается и применяется уже давно, на практике ее внедрение зачастую сопровождается преодолением самых различных проблем. Целью данной статьи будет показать, как реализовать простейший собственный Service Provider 1 (SP) для SAML 2.0 identity provider (idP) и с его помощью осуществить интеграции SSO в Java Web приложение.

Одним из наших последних проектов была подготовка и кластеризация портального решения для крупного университета. В рамках проекта мы столкнулись с задачей реализации (а также кластеризации) функции единой аутентификации для следующих систем:

Сложные моменты, с которыми мы столкнулись при решении данной задачи:

2. Для кого предназначена статья?

3. Основные компоненты работы SSO

На схеме ниже изображена общая схема функционирования нашего централизованного входа.

4. Настраиваем окружение для Shibboleth idP

Установка и конфигурация shibboleth idP:

Замечание: в этом же файле можно настроить получение атрибутов из различных источников данных как например LDAP или DBMS через JDBC. Подробнее тут https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAddAttribute.

4. Для того чтобы idP отдавал этот атрибут SAML SP фильтру описываем его в файле $shHome/conf/attribute-filter.xml.

Замечание: Здесь можно задать более сложное и корректное правило. Например, можно указать, чтобы данный атрибут передавался только определенному SAML SP.

5. Наш Shibboleth idP должен знать о тех узлах, с которыми он может взаимодействовать – так называемые relying party (https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnderstandingRP). Эта информация хранится в файле $shHome/conf/relying-party.xml.
Открываем файл и добавляем в него следующий элемент:

Добавьте SP в список алиасов для локалхоста в файле /etc/hosts:
127.0.0.1 localhost sp.local.ru

Также даем указание shibboleth idP не подписывать SAML 2.0 ответы и набор assertions (утверждений). До текущего времени наш shibboleth idP не имел понятия, что из себя представляет компонент с Время исправить этот момент. Идем на следующий шаг.

6. Добавляем описание нашего SAML 2.0 SP фильтра. Для этого в файле $shHome/conf/relying-party.xml определяем метаинформацию для нашего SP, рядом с элементом

Мы дали указанию shibboleth idP искать определение SP в файле /opt/shib/metadata/saml-sp-metadata.xml. Создаем этот файл со следующим содержимым:

Здесь нужно понимать следующее:

Настройка Shibboleth завершена, поздравляем 🙂

Установка и конфигурация Tomcat для shibboleth idP:

5. Реализация SP Filter для протокола SAML 2.0

С технической точки зрения фильтр будет представлять собой реализацию стандартного интерфейса javax.filter.Filter. Область действия фильтра будет задаваться в конкретном web-приложении.

2. Файл сборки pom.xml:

3. Сердцем нашего фильтра будет класс SAMLSPFilter:

В класс FilterConfig определим основные переменные фильтра (область действия фильтра, название idP, путь до метадаты idP, название SP и т.д.). Значения этих параметров будут задаваться в конфигурационном файле web.xml Java Web-приложения. Объекты checkSAMLResponse и samlRequestSender нужны для проверки валидности SAML 2.0 сообщений и отправки запроса аутентификации. К ним вернемся чуть позже.

Набор XML файлов содержит инструкции, как разбирать элементы SAML 2.0 сообщений и содержится в библиотеке opensaml-*.jar, которая подключится при сборке проекта через maven.

ШАГ 1: Игнорируем запросы, не предназначенные для фильтра
Параметр excludedUrlPattern, который заключает в себе регулярное выражение. Если запрашиваемый ресурс попадает в шаблон excludedUrlPattern, то фильтр не обрабатывает его:

Шаг 2: Если пришел ответ от Shibboleth idP, обрабатываем его
Ищем в реквесте параметр “SAMLResponse” и если он найден, значит, мы получили ответ от shibboleth idP на запрос аутентификации. Приступаем к обработке SAML 2.0 сообщения.

Для этого декодируем SAML сообщение в методе SAMLUtils.decodeSamlMessage(..), проверяем выполнимость SAML утверждений — checkSAMLResponse.verify(..). Если все проверки выполнены, то создаем внутреннюю SAML сессию SAMLSessionManager.getInstance().createSAMLSession(..) и редиректим пользователя на первоначально запрашиваемый ресурс response.sendRedirect(..).

В классе SAMLUtils будем размещать полезные промежуточные методы при работе с SAML 2.0 сообщениями. Одним из таких методов будет метод decodeSamlMessage, который декодирует полученные через HTTPS SAML 2.0 сообщения.

В этот же класс поместим вспомогательный метод для преобразования SAML объектов в String. Это будет полезно при логировании SAML сообщений.

Создадим класс SAMLResponseVerifier, в который поместим функциональность для проверки SAML 2.0 сообщений, полученных от shibboleth idP. В главном методе verify(..) реализуем следующие проверки:

Для создании локальной сессии будем использовать свой класс SAMLSessionManager. Его задачей будет создавать/уничтожать локальные сессии, которая представляет из себя объект следующего класса SAMLSessionInfo.

Собственно сам класс SAMLSessionManager, который создает и уничтожает локальные SAML сессии в Session контексте cервлета, используя SAMLContext.

Шаг 3: Если получен запрос на logout, удаляем локальную сессию

Замечание: стоит отметить, что сессия остается активной на shibboleth idP и при следующем запросе на аутентификацию shibboleth idP просто вернет нам активную сессию. Реализация же глобального logout требует дополнительных настроек и до версии 2.4.0 не поддерживалась shibboleth idP. Подробнее можно почитать тут https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues

Шаг 4: Если пользователь уже аутентифицирован, даем доступ к ресурсу

Если пользователь имеет активную SAML сессию в нашем фильтре, то даем пользователю данный ресурс.

Шаг 5: Создаем SAML запрос на аутентификацию и отправляем пользователя к
Shibboleth idP

Класс SAMLRequestSender создает, кодирует и отправляет запросы в виде SAML 2.0-сообщений.

SAML 2.0-сообщение с инструкцией по аутентификации пользователя создается в методе buildRequest и представляет из себя XML объект:

Параметр AssertionConsumerServiceURL задает URL, по которому shibboleth idP будет возвращать ответ, а параметр ProtocolBinding указывает каким образом возвращать ответ нашему фильтру (POST метод протокола HTTP)
Параметр ID определяет идентификатор сообщения, который мы сохраняем при отправке сообщения
String key = SAMLRequestStore.getInstance().storeRequest();
и проверяем при разборе сообщения в методе verifyInResponseTo класса SAMLResponseVerifier.

Элемент saml2p:Issuer определяет имя нашего SP. Используя значение saml2p:Issuer shibboleth idP определяет от какого SP прислан запрос на аутентификацию, и как его нужно обрабатывать (через метадату SP).

В ответ на приведенное выше SAML 2.0 сообщение мы получим ответ от idP в виде SAML 2.0 сообщения в XML формате:

Сообщение будет обработано в уже реализованном методе SAMLResponseVerifier.verify(..)
Вот собственно и все, наш фильтр реализован!
Структура нашего проекта выглядит так:

Собираем реализованный фильтр в jar библиотеку в локальный репозиторий.
Для этого выполняем команду в директории с pom.xml: mvn clean install

6. Создаем Java Web приложение с поддержкой SSO

Создаем Java Web приложение

Для наглядного примера мы создадим простое Java Web-приложение с приватными и публичными ресурсами. Доступ до приватных ресурсов требует аутентификацию пользователя через веб-приложение Shibboleth idP. Одним из приватных ресурсов сделаем страницу, которая выводит информацию по текущему пользователю системы.
Структура нашего приложения выглядит следующим образом:

В web.xml файле определяем параметры нашего фильтра и область его действия. Сделаем ресурсы в формате «.jpg» открытыми через параметр excludedUrlPattern.

Страничка представляет собой просто вывод id и атрибутов аутентифицированного пользователя.

Собираем приложение командой: mvn clean package.

Проверяем работу Java Web-приложения

Интеграция с Google Apps.

А теперь время проверить, что у нас действительно работает SSO.
Для этого будем использовать приложение из облачных служб Google Apps (http://www.google.com/enterprise/apps/business/).

Вообще логи в shibboleth idP достаточно простые и в то же время информативные. Рекомендуем потратить немного времени, чтобы разобраться в них.
Далее открываем наше приложение по урлу sp.local.ru:8443/sso/pages/private/page.jsp
и смотрим в логах, что shibboleth idP находит имеющуюся сессию для пользователя idpuser.

Ну вот и все. Наша простейшая система SSO функционирует. Надеемся, что вы нашли что-то полезное для себя.

Источник

Реализация SSO через SAML с примером

Доброго времени суток, дорогой читатель. Я уже давно хотел написать статью на хабре и вот наконец-то этот момент настал. Из последних тем, которыми я занимался и о которых мне есть что рассказать — это была реализация SSO для сервиса realtimeboard.com — замечательный продукт для совместной работы удаленной команды в одном месте, который хочется постоянно развивать и совершенствовать. Хочу здесь сразу уточнить, что в принципе SSO через Facebook и Google уже было в сервисе до моего прихода. Моей же задачей было реализовать его через протокол SAML.

SSO (Single Sign-On), — технология единого входа пользователей, благодаря которой владея одной лишь учетной записью пользователь может посещать множество различных сервисов.

SAML — это популярный XML-протокол для реализации SSO. Как правило большие организации (enterprise) используют именно его, как проверенный и надежный вариант.

В нашем сервисе появление этой фичи как раз и было обусловлено частыми запросами enterprise заказчиков на его реализацию. Такого рода заказчики централизованно ведут актуальную базу пользователей, вводят свои политики безопасности и т.п. Соответственно и доступ к контенту в сервисе становится более безопасным и контролируемым, чего в конце концов они и хотят.

На момент написания статьи, последняя версия стандарта — SAML 2.0. Базируется стандарт на XML, а значит и все требования стандартов w3c к XML так же применимы и к нему, не забывайте про это. Так, например в момент реализации, я словил одну ошибку. В момент создания AuthnRequest я генерировал уникальный строковый идентификатор для атрибута ID, так вот по требованиям он не должен начинаться с цифры, а у меня периодически так было.

В аутентификации через SAML SSO участвует три стороны:

Сама схема взаимодействия представлена на рисунке ниже

Из нее получается два основных кейса взаимодействия, причем один содержит в себе другой.

Вариант 1. Пользователь обращается к сервису. Сервис формирует сообщение AuthnRequest, кладет в параметр SAMLRequest и делает редирект через браузер к провайдеру на Login URL, где происходит аутентификация, затем провайдер формирует сообщение Response, кладет его в параметр SamlResponse и редиректит обратно в сервис на ACS URL.

Вариант 2. Пользователь уже аутентифицирован и находится в личном кабинете провайдера, откуда он может перейти в сервис, кликая по его ярлыку. В данной ситуации провайдер сразу формирует сообщение Response, кладет его в параметр SamlResponse и направляет в сервис на ACS URL.

ACS URL (Assertion Consumer Service URL) — урл на стороне нашего приложения, который принимает запросы с параметром SamlResponse, обрабатывает его (выдергивает сообщение Response, проверяет подпись по сертификату, различные правила) и если все хорошо, то создает рабочую сессию пользователя в приложении.

IdP Login URL — урл на стороне провайдера, который принимает запросы с параметром SAMLRequest и так же выполняет должную валидацию этого параметра, и если все хорошо, то отправляет на форму аутентификации.

В качестве IdP провайдeра может выступать один из онлайн-сервисов, таких как OneLogin, LastPass, Okta и другие. Также можно развернуть свой IdP с помощью Shibboleth или поднять AD.

Все параметры для этого взаимодействия должны настраиваться и храниться на обеих сторонах (IdP, SP), то есть должны быть выстроены доверительные отношения.

SP должен хранить у себя сертификат, который выдаст IdP, а также Saml Login URL, на который будет отправлять SAMLRequest.

IdP обязательно должен хранить у себя для размещаемого приложения ACS URL.

… должен сформировать сертификат, выбрать алгоритм шифрования, предоставить Saml Login URL для сервиса.

… должен настроить (если необходимо) атрибуты пользователя или еще какие-то кастомные поля для конкретного сервиса. Сервис с провайдером должны также договориться о формате Subject NameID. Это по сути идентификатор пользователя, информация о котором будет передана в сообщениях. В нашем случае это email.

Помимо ручной настройки, SP и IdP должны уметь генерировать файл метаданных, содержащий все необходимые параметры для “коллеги”, чтобы тот мог и загрузить и выставить настройки сам. У нас такой задачи не было.

В дополнение еще скажу, что помимо SSO, провайдеры опционально предоставляют еще и услугу SLO (Single Logout) — механизм, который предполагает выход сразу из всех сервисов одновременно. Возможны также две точки входа:

Для этого надо поддержать на стороне сервиса обработку запросов SP SLO URL и отправку запросов к IdP SLO URL. Такой задачи у меня также не было.

И так, задача поставлена, с теорией ознакомился, пора и делать начать. Первым делом ознакомился со списком имеющихся библиотек. Backend нашего сервиса написан на Java, искал библиотеки именно для него. Наиболее полный список продуктов, связанных с SAML можно увидеть тут. Выбрал для себя наиболее очевидные решения: Okta SAML Toolkit for Java, SpringSecurity SAML, OIOSAML 2.0 Toolkit, lastpass/saml-sdk-java, OneLogin 2.0, OneLogin 1.1.2, OpenSAML 2.0. Далее нужно было определить критерии, по которым будет выбрано то или иное решение. Так была составлена следующая таблица.

Если честно, исходный код предложенных решений просто ужаснул — известные провайдеры решили написать свои высокоуровневые прикладные библиотеки (получилось не очень), большая часть (слава богу) решений была основана на низкоуровневой библиотеке работы с SAML OpenSaml 2.0. Учитывая, что все эти библиотеки так или иначе пришлось бы править затачивая под потребности нашей логики и встраивать в наш основной код со всеми юнит-тестами было решено также использовать уже имеющийся базис в виде OpenSaml 2.0 и на нем писать нашу высокоуровневую логику. Возможно, если бы у нас был Spring, я бы стал использовать SpringSecurity SAML, но его у нас нет.

Вообще, все свои мысли и варианты решения я изложил в нашем же сервисе для дальнейшего обсуждения командой, скрин можно глянуть ниже или перейти на “живую” доску, участие в наполнении которой принимал не только я.

Итого, решение выбрано, поведение определено.

В качестве IdP для тестирования я выбрал, как можно увидеть по скринам выше, OneLogin. Он предоставляет бесплатный девeлоперский аккаунт, с ним проще всего было настроить тестовое приложение, а также он содержит набор утилит для работы с SAML, которые смогут облегчить Вам работу. Если не надо никакого полноценного конфигурируемого IdP, то можно использовать простую эту утилиту или ее аналог от Okta. Ими я тоже пользовался.

Сначала я написал свое тестовое локальное приложение чтобы обкатать в принципе эту технологию, его исходники я Вам и продемонстрирую. Затем уже перенес это решение на промышленную кодобазу. Логика приложения простая и применимая для любого сервиса. Приложение предлагает пользователю ввести email, если для этого домена не настроено SSO SAML, то приложение просит ввести внутренний пароль юзера (в примере ругается, что юзер не может SSO). Если же настроено, то смотрим на какой IdP настроен данный домен, формируем сообщение и перенаправляем запрос туда. После успешной аутентификации получаем сформированное сообщение на наш ACS URL от IdP, из сообщения берем email, берем сертификат для данного домена и проводим валидацию сообщения. В случае успешной проверки берем атрибуты из сообщения FirstName, LastName. Если пользователь уже существует меняем ему значения этих атрибутов в нашем сервисе. Если пользователя еще нет, то создаем его.

Это так называемый Just-in-Time Provisioning. Эта самая простая реализация провижининга (синхронизация) пользователей, которую можно сделать. Минусом такой синхронизации можно назвать отсрочку выполнения до следующего входа пользователя. Плюс невозможность удаления пользователя на стороне сервиса при удалении юзера из IdP. Чтобы полноценно запустить провижининг в сервисе необходимо реализовать стандарт SCIM, но этого я еще не делал — возможно это будет следующая история.

Источник

Что такое SAML аутентификация и кому она нужна?

Управление доступом пользователей к облачным ресурсам представляет собой одну из основных проблем для безопасного использования облачных приложений в корпоративном окружении. С распространением многочисленных сервисных концепций SaaS, PaaS и IaaS управление политиками доступа, в том числе организация строгой аутентификации для каждого приложения создает определенную нагрузку на ИТ-подразделения предприятий. Пользователям приходится держать в памяти многочисленные логины и пароли, что неизбежно приводит к утере паролей, снижению продуктивности и раздражает пользователей. До 20% всех обращений в службу поддержки связано с восстановлением утраченных или забытых паролей.

Более того, ИТ-подразделения зачастую не владеют информацией о том, с какими именно приложениями работают конкретные пользователи, и как часто осуществляется доступ к этим приложениям, что фактически приводит к формированию теневых ИТ и снижает эффективность управления ресурсами. С точки зрения контроля доступа возникает также следующий вопрос: каким образом вы можете гарантировать, что в случае ухода сотрудника из компании он перестанет пользоваться корпоративными приложениями? Наконец, даже несмотря на наличие возможности обезопасить доступ к облачным ресурсам средствами многофакторной аутентификации, ИТ-подразделения зачастую не располагают информацией, кто из сотрудников все же позаботился об использовании такой аутентификации. В результате повышается вероятность компрометации данных, угроза фишинга, перебора паролей, взлома облачных баз данных и прочих угроз.

В отсутствие централизованных инструментов управления доступом использование облачных приложений в корпоративном окружении часто не предусматривает механизмов эффективного масштабирования, что приводит к появлению брешей безопасности, увеличению административной нагрузки, раздражению пользователей и снижению эффективности работы организации.

Управление доступом к облачным ресурсам: удостоверения в роли нового периметра безопасности

Аутентификация с использованием SAML

Язык разметки SAML (Security Assertion Markup Language) представляет собой открытый стандарт на основе XML, который предназначен для обмена данными аутентификации и авторизации между сторонами процесса. Ставший стандартом с 2002 года, SAML является разработкой Технического комитета по сервисами безопасности (Security Services Technical Committee), который работает при организации OASIS, занимающейся продвижением стандартов для работы со структурированной информацией. С помощью протокола SAML пользователи могут получать доступ ко множеству своих облачных приложений, указывая всего один логин и пароль. Такой подход получил название «федерации удостоверений», поскольку вместо запоминания целого множества логинов и паролей к каждому приложению, пользователю необходимо помнить лишь одну такую пару. При федерации удостоверений единая система, поддерживающая протокол SAML и получившая название доверенного поставщика удостоверений (Identity Provider, IdP), проводит аутентификацию пользователей, при этом облачные приложения «перекидывают» процесс аутентификации на эту IdP систему всякий раз при попытке пользователя получить к ним доступ.

Федерация удостоверений на базе протокола SAML

Федерация удостоверений и система единого входа позволяет избавиться от множества сложностей и проблем, связанных с необходимостью раздельного управления логинами и паролями для доступа к многочисленным веб-приложениям, не важно, реализованы ли они внутри организации, или являются внешними. Федерация стала возможной благодаря применению стандартов, и протокол SAML выступает в роли краеугольного камня в архитектуре и является основным стандартом для федерации удостоверений. Кроме того, широкое распространение этого протокола и рост его популярности также стали важными преимуществами SAML.

Поскольку в основе стандарта лежит язык разметки XML, SAML отличается исключительной гибкостью. Одного внедрения SAML достаточно, чтобы поддерживать подключение сервиса единого входа (single sign-on, SSO) для множества различных партнеров по федерации. Эта совместимость обеспечивает SAML определенные преимущества над другими, закрытыми механизмами единого входа, в частности, SAML позволяет организациям не ограничивать себя решениями какого-либо отдельного поставщика, дает возможность переходить с одной платформы SAML аутентификации на другую.

Чтобы продемонстрировать гибкость и совместимость SAML, в рамках инициативы Kantara была реализована программа тестирования на взаимосовместимость, когда поставщики SAML решений подтверждали возможность взаимодействия своих стандартных коробочных решений с проектами SAML других поставщиков. На сегодняшний день в списке Kantara Trust Registry представлено более 80 сертифицированных решений от многочисленных поставщиков и организаций со всего мира.

Каким образом устроена SAML аутентификация?

Аутентификация средствами SAML предусматривает возможность обмена данными учетных записей между доверенным поставщиком удостоверений (IdP) и облачными или веб-приложениями. Модель SAML аутентификации включает в себя поставщика удостоверений, который выдает ‘SAML подтверждения’ (SAML assertions) – в роли такого поставщика может выступать, например, SafeNet Authentication Service – и поставщика услуг, который принимает эти подтверждения, например, Google Apps, Office 365 или любое другое облачное приложение, поддерживающее SAML. Подтверждения SAML обычно подписываются с помощью подписи PKI, которая служит доказательством того, что подтверждение является подлинным.

Сервис аутентификации, выступающий в качестве поставщика удостоверений, получает пользовательские учетные данные и возвращает ответ тому облачному приложению, к которому осуществляется доступ. Этот ответ получил название SAML подтверждения. В зависимости от содержимого SAML подтверждения облачное приложение либо принимает, либо отказывает пользователю в доступе. Если SAML подтверждение содержит положительный ответ, то пользователь входит в систему.

Ключевым аспектом в реализации федерации удостоверений средствами SAML является привязка (mapping) пользователей к поставщику удостоверений (IdP) и поставщикам услуг, чтобы при обращении пользователя к сервисам вроде Office 365, эти сервисы понимали, на какого поставщика удостоверений им нужно перенаправить пользователя, чтобы он мог пройти процедуру строгой аутентификации.

Федерация удостоверений для централизованного управления доступом пользователей

SAML позволяет распространить сферу применения имеющихся корпоративных учетных записей пользователей и на облачные приложения. Благодаря федеративной системе проверки подлинности удостоверений пользователи могут полностью обойтись без запоминания многочисленных логинов и паролей. Они смогут получать доступ ко всем своим облачным приложениям, используя одну и ту же корпоративную учетную запись, то есть ту же самую учетную запись, указывая которую они каждое утро входят в сеть.

С точки зрения пользователей федеративная система проверки удостоверений на базе SAML работает максимально органично и незаметно. В SAML используются cookie-файлы, благодаря чему после входа в Office 365 пользователю не требуется проходить повторную аутентификацию при входе в другие облачные приложения в новых вкладках браузера, например в Dropbox, WordPress, Salesforce и т.д.

Преимущества федерации удостоверений на базе протокола SAML

Помимо того, что SAML аутентификация помогает избавить пользователей от необходимости запоминания множества логинов и паролей, эта технология позволяет ИТ-администраторам управлять лишь одной парой учетных данных на пользователя для всех приложений. Поэтому при увольнении сотрудника из организации, ИТ-подразделению достаточно аннулировать лишь одну пару логина и пароля. При этом учетную запись можно аннулировать без необходимости входа в каждое отдельное облачное приложение. Автоматизированные скрипты позволяют минимизировать административную нагрузку на ИТ-подразделения за счет синхронизации с системами хранения учетных записей пользователей, такими как MS SQL или Active Directory.

Если представить ИТ-инфраструктуру в виде офисного здания, то федеративная система проверки подлинности удостоверений с помощью SAML могла бы обеспечить сотрудникам компании более простой и удобный доступ к различным зонам этого здания – к кабинетам, конференц-залу, зоне отдыха, столовой и т.д. – с помощью всего одной карты доступа вместо того, чтобы иметь отдельные карты на каждую комнату.

Источник