Что такое saml 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 могла бы обеспечить сотрудникам компании более простой и удобный доступ к различным зонам этого здания – к кабинетам, конференц-залу, зоне отдыха, столовой и т.д. – с помощью всего одной карты доступа вместо того, чтобы иметь отдельные карты на каждую комнату.

Источник

SAML простыми словами

Что такое SAML?

SAML — сокращение от Security Assertion Markup Language (Язык разметки декларации безопасности). Его ключевая роль в обеспечении сетевой безопасности заключается в том, что он позволяет получить доступ в несколько приложений, используя один набор учетных данных для авторизации. Он работает посредством обмена аутентификационной информацией в определенном формате между участниками, в частности, между системой управления доступами и веб-приложением.

Как работает SAML

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

SAML появился в индустрии высоких технологий для упрощения процесса аутентификации, когда пользователям нужно было получить доступ к нескольким независимым веб-приложениям в разных доменах. До появления SAML, технология единого входа (SSO) была вполне достижима/выполнима, но базировалась на файлах cookies, которые были жизнеспособны только в пределах одного домена.

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

Преимущества SAML

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

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

Плюс ко всему, теперь, когда система управления доступами обеспечивает безопасную SAML аутентификацию, у компаний появляется возможность инвестировать появившееся время и ресурсы в разработку нескольких/новых уровней безопасности. Например, система управления доступами обеспечивает комплексную защиту личных данных, что включает в себя такие функции, как многофакторная аутентификация (MFA), которая защищает от наиболее распространенных атак на конфиденциальную информацию.

Процесс работы

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

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

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

Вернемся к нашему примеру с авиакомпанией. Перед посадкой на самолет сотрудники авиакомпании (поставщика услуг) снова проверяют удостоверение личности (SAML подтверждение). Сразу после успешной аутентификации, авиакомпания разрешает посадку на борт.

Что такое SAML SSO?

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

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

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

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

В чем разница между OAuth и SAML?

OAuth и SAML — это протоколы, используемые для предоставления доступа. Однако, радикальным отличием между ними является то, что SAML используется для аутентификации, а OAuth для авторизации.

Пример SAML

Процесс аутентификации SAML базируется на claims (данных пользователя). На первом этапе, когда пользователь пытается получить доступ к сайту, поставщик услуг запрашивает аутентификацию пользователя у системы управления доступами. Затем, поставщик услуг использует SAML подтверждение, выданное системой управления доступами, для предоставления доступа пользователю. Проиллюстрируем данный процесс на примере:

Обучающие ресурсы

OneLogin предлагает несколько наборов инструментов разработчика SAML, которые можно использовать для внедрения SSO в свои приложения через систему управления доступами, предоставляющую SAML-аутентификацию.

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

Пакет разработчика The OneLogin SAML Toolkit предоставляет различные онлайн инструменты на https://www.samltool.com. Например, можно установить самостоятельно сгенерированный самозаверенный сертификат X. 509, который вы сможете использовать в тестовой среде.

Кроме того, поскольку SAML использует алгоритм кодирования Base64, OneLogin предлагает онлайн-сервис по кодированию и декодированию XML в Base64 и наоборот. Пакет разработчика также предоставляет ресурсы по шифрованию узлов из XML, подписи AuthNRequests и проверки вашего XML в соответствии со схемой SAML XSD.

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

Источник