Опыт реализации SSO в приложении Axon средствами SAML 2.0 / Habr

Перед экспертами Центра информационных технологий РТ была поставлена задача реализовать интеграцию веб-приложения Axon с SSO средствами протокола SAML 2.0. В качестве SSO выступает продукт Avanpost FAM, а в качестве конечного веб-приложения – Informatica Axon Data Governance. В статье описываем основные этапы настройки, рассказываем, что из себя представляет данный протокол, и как была решена задача.

Немного про SAML 2.0

SAML – это стандарт для обмена утверждениями о безопасности между веб-сервисами, основанный на языке xml. Версия 2.0 является последней версией протокола SAML и была выпущена в 2005 году.

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

Основные понятия в SAML 2.0

Поставщик SAML – это система, которая помогает пользователям получать доступ к необходимому сервису. SAML передает идентификационные данные между двумя сторонами: IdP и SP.

Поставщик идентификационных данных (IdP) выполняет аутентификацию и передает уровень идентификации и авторизации пользователя поставщику сервисов. IdP выполняет аутентификацию пользователя, а SP разрешает доступ на основе ответа, предоставленного IdP.

Поставщик услуг (SP) требует аутентификации у IdP для предоставления авторизации пользователю, и, поскольку обе системы используют один и тот же язык, пользователю требуется войти в систему только один раз.

Утверждение SAML (SAML Assertion) – это XML-документ, который IdP отправляет SP, документ содержит статус авторизации пользователя. Тремя разными типами утверждений SAML являются решения по аутентификации, атрибутам и авторизации.

Принцип работы SAML 2.0

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

Разработка базовой модели взаимодействия

Перед началом интеграции следует проработать основную модель взаимодействия между пользователем, IdP и SP.

В нашем проекте поставщиком идентификационных данных (IdP) является Аванпост FAM, а поставщиком услуг (SP) – веб-приложение бизнес-глоссарий компании Informatica.

Исходя из представленной модели, выделим следующие шаги взаимодействия:

Пользователь обращается к SP, и запрашивает у сервиса метод аутентификации.
SP формирует SAML-Request и перенаправляет пользователя на IdP.
Пользователь вводит данные аутентификации, после чего IdP отправляет SAML-Response на основе SAML-Assertion.
SP принимает ответ от IdP, и на основе его решает, авторизовать пользователя или нет.

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

Такими основными атрибутами в нашем случае будут являться:

firstName – имя;

lastName – фамилия;

email – эл. почта

Все эти атрибуты, а также X509 сертификаты поставщика услуг и поставщика идентификационных данных будут заранее сконфигурированы и переданы между системами в формате xml в момент обращения пользователя к IdP, для прохождения аутентификации.

Заполненные пользователем ключевые атрибуты от IdP передаются в подписанный SAML Assertion, затем данные содержащиеся внутри утверждения передаются в SP, который потом «маппит» их на те, которые у него есть в системе, тем самым предоставляя доступ.

Процесс интеграции

Настройка на стороне IdP

На основании документации по Avanpost FAM, для интеграции информационных систем по SAML, необходимо внутри ОС, где установлен дистрибутив продукта, установить средства проверки подписи XML и добавить в config.json самого IdP путь к шаблону для SAML-Response:

sudo {yum/apt/packman} install xmlsec1 xmlsec1-openssl –y

. . .

"saml_response": "public/templates/samlresponse.html",

. . .

Также необходимо создать соответствующее приложение, и прописать в него следующие параметры:

Для того, чтобы пользователь мог получить доступ к конечному веб-приложению, в Аванпост FAM необходимо создать и включить данного пользователя и созданное приложение в одну группу.

После создания приложения на вкладке Attributes необходимо задать атрибуты и соответствующие значения для них.

Настройка на стороне SP

На стороне поставщика услуг (SP) заходим под локальной учетной записью администратора. В настройках «SAML Configuration» необходимо сконфигурировать следующие параметры:

Далее необходимо применить данные настройки путем перезагрузки служб внутри самой ОС, на которой установлен дистрибутив данного продукта.

Разработчиками ПО уже предусмотрен определенный скрипт, для автоматизации процесса перезапуска, давайте запустим его:

sh /axon72/axonhome/third-party-app/scripts/paramsync

Проверка работоспособности

Теперь давайте проверим работоспособность нашей интеграции. Для наглядности будем использовать SAML-tracer (можно скачать как расширение в любом популярном браузере).

Зайдем на страницу поставщика услуг (SP) и нажмем Login

Нас перекинет на страницу поставщика идентификационных данных (IdP)

В SAML-tracer видим следующий запрос, отправленный SP в сторону IdP:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

                    ID="ONELOGIN_55b121e8c532e827ca79a70194c26b847a62e7cc"

                    Version="2.0"

                    IssueInstant="2023-05-11T15:29:49Z"

                    Destination="https://{Avanpost URL}/saml2"

                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                    AssertionConsumerServiceURL="https://{Axon URL:PORT}/saml/acs"

                    >

    <saml:Issuer>https://{Axon URL:PORT}/saml/metadata</saml:Issuer>

    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"

                        AllowCreate="true"

                        />

</samlp:AuthnRequest>

Из данного запроса можно понять, что SP отправил пользователя на IdP и передал ему формат атрибута, который тот должен будет отправить обратно с другими данными в SAML Assertion, после обмена конфигурациями.

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

SAML2.0 Response
Destination            https://{Axon URL:PORT} /saml/acs
ID           _cc73f00f-f6a2-4e40-8b40-f2c2ee72c006
Version   2.0
IssueInstant           2023-05-11T15:59:30Z
Issuer      https://{Avanpost URL}
SAML 2.0 Assertion
ID           ONELOGIN_55b121e8c532e827ca79a70194c26b847a62e7cc
Version   2.0Version   2.0
IssueInstant           2023-05-11T15:59:30Z
Subject   {usermail}@tatar.ru
SAML 2.0 AttributeStatement
email       {usermail}@tatar.ru
lastName {Фамилия}
firstName               {Имя}

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

В более подробной форме ответа можно также увидеть обмен сертификатами, статус аутентификации и метод самой аутентификации, который мы задали:

<samlsig:Signature Id="{ID}">
        <samlsig:SignedInfo>
            <samlsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <samlsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
            <samlsig:Reference URI="{URI}">
                <samlsig:Transforms>
                    <samlsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <samlsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                </samlsig:Transforms>
                <samlsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                <samlsig:DigestValue>{DigestValue}</samlsig:DigestValue>
            </samlsig:Reference>
        </samlsig:SignedInfo>
        <samlsig:SignatureValue>{SignatureValue}</samlsig:SignatureValue>
        <samlsig:KeyInfo>
            <samlsig:X509Data>
                <samlsig:X509Certificate>{IdP Certificate} 
</samlsig:X509Certificate>
            </samlsig:X509Data>
</samlsig:KeyInfo>
    </samlsig:Signature>
    <samlp:Status>
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
<saml:AuthnContext>           <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml:AuthnContext>

Что мы получили

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

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

Спасибо за внимание.