Предварительное исследование языка разметки утверждений безопасности SAML2.0

Безопасность

Введение

Полное название SAML — Security Assertion Markup Language, представляющий собой набор открытых стандартов, основанных на формате XML, разработанном OASIS для обмена данными аутентификации и авторизации между поставщиками удостоверений (IdP) и поставщиками услуг (SP).

Очень важным применением SAML является система единого входа (SSO) через Интернет.

Далее давайте посмотрим, как работает SAML.

Состав SAML

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

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

Роль SP заключается в проверке информации об аутентификации пользователя и авторизации пользователя для доступа к указанной информации о ресурсе.

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

Зачем использовать SAML?

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

Во-вторых, это может повысить безопасность системы.При использовании SAML нам нужно только указать имя пользователя и пароль для IdP.

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

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

Далее давайте проанализируем, как работает SAML, с помощью блок-схемы SSO-аутентификации с SAML.

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

SP redirect request; IdP POST response

Пользовательский агент на приведенном выше рисунке — это веб-браузер Давайте посмотрим, как протокол SAML обрабатывает, когда пользователь хочет запросить ресурсы поставщика услуг.

  1. Пользователь запрашивает поставщика услуг через агента пользователя, например:
http://sp.flydean.com/myresource

SP выполнит соответствующую проверку безопасности ресурса и, если обнаружит, что контекст безопасности уже существует, пропустит шаги 2–7 и сразу перейдет к шагу 8.

  1. Если SP не найдет соответствующий допустимый контекст безопасности на первом этапе, он сгенерирует соответствующий запрос SAMLRequest и перенаправит пользовательский агент на IdP:
302 Redirect
Location: https://idp.flydean.com/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

RelayState — это информация о состоянии, поддерживаемая SP, которая в основном используется для предотвращения атак CSRF.

где этот SAMLRequest закодирован с помощью Base64samlp:AuthnRequest, ниже приведен пример samlp:AuthnRequest:

  <samlp:AuthnRequest
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="aaf23196-1773-2113-474a-fe114412ab72"
    Version="2.0"
    IssueInstant="2020-09-05T09:21:59Z"
    AssertionConsumerServiceIndex="0"
    AttributeConsumingServiceIndex="0">
    <saml:Issuer>https://sp.flydean.com/SAML2</saml:Issuer>
    <samlp:NameIDPolicy
      AllowCreate="true"
      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
  </samlp:AuthnRequest>

В целях безопасности SAMLRequest также можно подписать с помощью ключа подписи, предоставленного SP.

  1. Пользовательский агент отправит запрос на получение на сервер единого входа IdP:
GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1
Host: idp.flydean.com

После того, как IdP получит AuthnRequest, он выполнит проверку безопасности.Если это действительный AuthnRequest, отобразится интерфейс входа в систему.

  1. Пользователь может ввести имя пользователя и пароль для входа в систему. После успешного входа IdP вернет форму XHTML:
  <form method="post" action="https://sp.flydean.com/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLResponse" value="response" />
    <input type="hidden" name="RelayState" value="token" />
    ...
    <input type="submit" value="Submit" />
  </form>

Эта форма содержит информацию SAMLResponse, а SAMLResponse содержит информацию, относящуюся к пользователю.

Тот же SAMLResponse также закодирован с использованием Base64.samlp:Response.

<samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_2"
    InResponseTo="identifier_1"
    Version="2.0"
    IssueInstant="2020-09-05T09:22:05Z"
    Destination="https://sp.flydean.com/SAML2/SSO/POST">
    <saml:Issuer>https://idp.flydean.com/SAML2</saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_3"
      Version="2.0"
      IssueInstant="2020-09-05T09:22:05Z">
      <saml:Issuer>https://idp.flydean.com/SAML2</saml:Issuer>
      <!-- a POSTed assertion MUST be signed -->
      <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
      <saml:Subject>
        <saml:NameID
          Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
          3f7b3dcf-1674-4ecd-92c8-1544f346baf8
        </saml:NameID>
        <saml:SubjectConfirmation
          Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
          <saml:SubjectConfirmationData
            InResponseTo="identifier_1"
            Recipient="https://sp.flydean.com/SAML2/SSO/POST"
            NotOnOrAfter="2020-09-05T09:27:05Z"/>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions
        NotBefore="2020-09-05T09:17:05Z"
        NotOnOrAfter="2020-09-05T09:27:05Z">
        <saml:AudienceRestriction>
          <saml:Audience>https://sp.flydean.com/SAML2</saml:Audience>
        </saml:AudienceRestriction>
      </saml:Conditions>
      <saml:AuthnStatement
        AuthnInstant="2020-09-05T09:22:00Z"
        SessionIndex="identifier_3">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
         </saml:AuthnContextClassRef>
        </saml:AuthnContext>
      </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>

Мы видим, что samlp:Response содержит информацию saml:Assertion.

  1. После того, как пользовательский агент получит форму XHTML, он отправит форму SP.

  2. Служба потребителя утверждений в SP обработает запрос, создаст соответствующий контекст безопасности и перенаправит пользовательский агент на страницу ресурса, к которой необходимо получить доступ.

  3. Пользовательский агент снова запрашивает ресурс SP.

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

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

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

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

SP POST Request; IdP POST Response

Я только что говорил о запросе перенаправления SP, здесь мы рассмотрим, как выполняется запрос SP POST:

Отличие от первого метода заключается во втором и третьем шагах.

Шаг 2: SP больше не перенаправляет, а возвращает агенту пользователя форму XHTML:

  <form method="post" action="https://idp.flydean.com/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLRequest" value="request" />
    <input type="hidden" name="RelayState" value="token" />
    ...
    <input type="submit" value="Submit" />
  </form>

Шаг 3. После получения формы XHTML на втором этапе агент пользователя отправляет форму на сервер единого входа IdP.

Начиная с четвертого шага, это то же самое, что и первый метод.

SP redirect artifact; IdP redirect artifact

В-третьих, и SP, и IdP используют перенаправление, но содержание перенаправления является артефактом.

Ранее мы говорили, что сообщения SAML можно передавать по значению или по ссылке.

И этот метод передачи по ссылке является артефактом.

Получатель, получивший артефакт, отправитsamlp:ArtifactResolveДайте его эмитенту, чтобы получить настоящее сообщение.

Вот пример запроса сообщения от IdP:

  <samlp:ArtifactResolve
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_cce4ee769ed970b501d680f697989d14"
    Version="2.0"
    IssueInstant="2020-09-05T09:21:58Z">
    <saml:Issuer>https://idp.flydean.com/SAML2</saml:Issuer>
    <!-- an ArtifactResolve message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Artifact>AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=</samlp:Artifact>
  </samlp:ArtifactResolve>

Соответствующий сервер вернетsamlp:AuthnRequestизsamlp:ArtifactResponse:

<samlp:ArtifactResponse
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="_d84a49e5958803dedcff4c984c2b0d95"
    InResponseTo="_cce4ee769ed970b501d680f697989d14"
    Version="2.0"
    IssueInstant="2020-09-05T09:21:59Z">
    <!-- an ArtifactResponse message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <samlp:AuthnRequest
      xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="_306f8ec5b618f361c70b6ffb1480eade"
      Version="2.0"
      IssueInstant="2020-09-05T09:21:59Z"
      Destination="https://idp.flydean.com/SAML2/SSO/Artifact"
      ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
      AssertionConsumerServiceURL="https://sp.flydean.com/SAML2/SSO/Artifact">
      <saml:Issuer>https://sp.flydean.com/SAML2</saml:Issuer>
      <samlp:NameIDPolicy
        AllowCreate="false"
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
    </samlp:AuthnRequest>
  </samlp:ArtifactResponse>

Взгляните на блок-схему третьего метода:

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

Возьмем в качестве примера третий, четвертый и пятый шаги:

Пользовательский агент третьего шага запрашивает SSO-сервер IdP:

 https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact_1&RelayState=token

Обратите внимание, что параметры запроса здесь становятся SAMLart.

На четвертом этапе IdP должен отправитьsamlp:ArtifactResolveк SP, чтобы запросить настоящий samlp:AuthnRequest.

На пятом шаге SP возвращаетsamlp:ArtifactResponseСодержит samlp:AuthnRequest.

Суммировать

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

Автор статьи: о программе flydean

Ссылка на эту статью:woohoo.floydpress.com/zamora-start и…

Источник этой статьи: блог flydean

Добро пожаловать на мой официальный аккаунт: самая популярная интерпретация, самая глубокая галантерея, самые краткие уроки и множество трюков, о которых вы не знаете, ждут вас!

Категории