Разница между двумя протоколами SSO, SAML и OAuth2

Java

Введение

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

SAML

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

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

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

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

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

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

Пользовательский агент на приведенном выше рисунке — это веб-браузер Давайте посмотрим, как протокол 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 в фоновом режиме, тем самым повысив безопасность.

Недостатки SAML

Протокол SAML был сформулирован в 2005 году. Когда протокол был сформулирован, он был в основном нацелен на веб-приложения, но веб-приложения в то время были относительно простыми, не говоря уже о поддержке приложений.

SAML должен передавать информацию о пользователе через протоколы HTTP Redect и HTTP POST и обычно отправляет данные в формате HTML FORM. Если приложение не является веб-приложением, например мобильным приложением.

Ссылка для запуска этого мобильного приложения — my-photos://authenticate , но мобильное приложение может не получить основной контент Http POST. Они могут передавать параметры только через URL.

Это означает, что SAML нельзя использовать в мобильных приложениях.

Конечно, при желании он будет работать, но потребует некоторой доработки. Например, сообщение POST анализируется сторонним приложением, а затем проанализированный запрос SAMLRequest передается в приложение в виде параметров URL.

Другой способ — использовать OAuth2.

OAuth2

Потому что Oauth2 был выпущен только в 2012 году. Так что ограничений по использованию не так много. Мы можем использовать OAuth2 в разных ситуациях.

Давайте сначала посмотрим на блок-схему авторизации в OAuth2:

Вообще говоря, в OAuth2 есть 4 роли.

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

сервер ресурсов: представляет сервер, которому в конечном итоге требуется доступ к ресурсу. Например, информация о пользователе, полученная после авторизации на github.

клиент: клиент, используемый для взаимодействия вместо владельца ресурса.

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

Весь процесс выглядит так:

Клиент инициирует запрос авторизации владельцу ресурса, владелец ресурса вводит соответствующую информацию аутентификации и возвращает разрешение на авторизацию клиенту.

Затем клиент запрашивает у сервера авторизации полученное разрешение на авторизацию и возвращает токен доступа.

Затем клиент может использовать этот токен доступа, чтобы запросить сервер ресурсов и, наконец, получить ограниченный ресурс.

Недостатки OAuth2

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

OAuth2 по умолчанию работает в среде HTTPS, поэтому нет единого мнения о способе шифрования информации. Нам нужно сделать это самим.

Наконец, OAuth2 — это протокол авторизации, а не протокол аутентификации. Для решения этой проблемы мы можем рассмотреть возможность использования протокола OpenID Connect. Потому что OpenID Connect основан на OAuth2 и добавляет протокол аутентификации.

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

OAuth2 на самом деле выполняет только авторизацию, а OpenID Connect добавляет аутентификацию к авторизации.

Преимущества OIDC: простой токен идентификации (JWT) на основе JSON и полная совместимость с протоколом OAuth2.

сравнение двух

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

Но, с другой стороны, OAuth2 может сделать токен недействительным на стороне сервера авторизации, потому что его нужно снова аутентифицировать.

Введение в CAS

Любой, кто делал SSO, должен был слышать о CAS. Полное название CAS — Central Authentication Service, которая представляет собой платформу аутентификации SSO с открытым исходным кодом на уровне предприятия.

CAS объединяет протоколы CAS1, 2, 3, SAML1, 2, OAuth2, OpenID и OpenID Connect, что очень эффективно. Мы представим использование CAS в следующей статье.

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

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

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

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

Категории