Кто использует протокол аутентификации SAML 2.0

    У себя в блоге мы часто затрагиваем вопросы защиты данных и авторизации. Например, мы рассказывали о новом стандарте для беспарольной авторизации WebAuthn и даже брали интервью у одного из его разработчиков. Также обсуждали технологию DANE для аутентификации доменных имен по DNS. Сегодня поговорим о протоколе SAML 2.0 и о тех, кто его использует.


    Фото — Marco Verch — CC BY — Фото изменено

    Что такое SAML


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

    С помощью протокола SAML друг с другом взаимодействуют поставщики учетных записей (IdP, или identity provider) и поставщики услуг (SP, или service provider) для безопасной передачи идентификационных данных пользователей приложений. Роль поставщика учетных записей может играть служба каталогов Active Directory и даже простая SQL база данных с логинами и паролями. Сервис провайдером может быть любое веб-приложение, в котором хочет авторизоваться пользователь (разумеется, поддерживающее SAML).

    В целом процесс аутентификации состоит из следующих шагов:

    1. Пользователь просит авторизовать его в приложении от SP.
    2. Поставщик услуг запрашивает подтверждение логина у IdP.
    3. Поставщик учетных записей посылает специальное SAML-сообщение, в котором говорит о корректности или некорректности идентификационных данных.
    4. Если данные верны, поставщик авторизует пользователя.


    Кто его внедряет


    Последнее крупное обновление для SAML — SAML 2.0 — было опубликовано в 2005 году. И с тех пор протокол получил довольно широкое распространение. Работу с ним поддерживают такие сервисы, как Salesforce, Slack и GitHub. Его использует даже информационная система ЕСИА для авторизации на Госуслугах.

    Казалось бы, за такой долгий срок протокол должен был стать чем-то обыденным, однако в последнее время он вновь вызывает повышенный интерес — по теме выходит большое количество статей (вот и вот), а в социальных сетях ведется активное обсуждение. Использовать SAML также начали IaaS-провайдеры.

    Например, месяц назад SAML внедрили в Azure Active Directory Proxy Service — инструмент для получения удаленного доступа к веб-приложениям. По мнению ряда экспертов, компания-разработчик сервиса решила использовать этот протокол, так как он обеспечивает более надежную защиту SSO-логинов для крупных компаний, чем альтернативы вроде OAuth.

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

    Внимание протоколу уделяют не только облачные провайдеры, но и некоммерческие организации. Пару недель назад в Public Safety Technology Alliance (PSTA), которая занимается продвижением технологий для обеспечения общественной безопасности, рекомендовали своим партнерам внедрить авторизацию на базе SAML 2.0 и OpenID. Среди причин были выделены: зрелость технологий, их распространенность и надежность.

    Мнения о протоколе


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


    Фото — Matthew Brodeur — Unsplash

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

    Хотя эксперты по ИБ считают протокол SAML довольно надежным, опасения вызывает наличие уязвимостей в отельных библиотеках для SSO-операций. В прошлом году инженеры из Duo Labs, занимающейся информационной безопасностью, нашли баг с обработкой XML-комментариев. Модифицировав поле username в SAML-сообщении, злоумышленник может выдать себя за другого пользователя. Впрочем, важным условием для осуществления атаки является наличие учетной записи в сети жертвы.

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

    О чем мы пишем в наших блогах и социальных сетях:

    Новые лицензии для открытого ПО, кто ими занимается
    В Open Invention Network больше трех тысяч лицензиатов — что это значит для открытого ПО

    Как защитить виртуальный сервер в интернете
    Как сэкономить с помощью API

    Дайджест: 5 книг и один курс по сетям
    Подборка книг для тех, кто уже занимается системным администрированием или планирует начать



    Мы в 1cloud.ru предлагаем услугу «Облачное объектное хранилище». Она позволяет хранить резервные копии и работать с архивными данными.


    1cloud.ru
    331,53
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Поделиться публикацией

    Комментарии 3

      0
      Концепция SSO довольно интересна. Было бы интересно почитать про сравнение SAML и какого-нибудь OAuth и других протоколов
        0
        Баг связан с конкретной реализацией.
        Просто не надо использовать сторонний код в коммерческих системах.
        Тем более, что реализация SAML занимает часа два.
          0
          Имею опыт реализации облачного Enterpise-сервиса с аутентификацией и авторизацией пользователей по SAML. Работало просто отлично, вплоть до самостоятельного подключения админами клиентов (всех дел — задать URI своего IdP и скопипастить его публичный ключ).
          У Microsoft есть бесплатный ADFS — имплементация IdP поверх AD c возможностью включения практически любых полей оттуда в SAML-assertion (включая группы — что очень удобно для авторизации) и кастомизации login flow/UI.
          Для нас же — сняло кучу головной боли по управлению аккаунтами и уровнями доступа. Это довольно давно было, с сегодняшними заморочками вроде GDPR пришлось бы год работы потратить на колхозинг чего-то своего.
          Единственный недостаток указан в статье — у MS/IBM/SAP были несколько разные XML-схемы, поэтому приходилось поддерживать их все. Ну и у некоторых тогдашних телефонов были глюки с HTTP-переадресацией. Сегодня уже вряд ли актуально…

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое