SAML протокол, используемый в подключении ключевой клавиш в Wildfly

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

Введение

Мы знаем, что два наиболее часто используемых протокола для SSO — это SAML и OpenID Connect. Мы уже говорили о том, как использовать OpenID Connect для подключения keycloak в wildfly в предыдущей статье. Сегодня мы продолжим объяснять, как использовать протокол SAML для подключения keycloak. .

OpenID Connect и SAML

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

OpenID Connect включает в себя как аутентификацию, так и авторизацию, а также использует Json Web Token (JWT) для доставки сообщений.

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

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

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

SAML 2.0 — это протокол аутентификации на основе XML, который был создан до OIDC, поэтому он будет более зрелым, чем OIDC, но и более сложным, чем OIDC.

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

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

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

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

Saml Workflow

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

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

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

Обычно существует три способа использования SAML для аутентификации SSO, в зависимости от различных методов запроса: запрос перенаправления SP, ответ IdP POST:

Агент пользователя в вышеупомянутом рисунке является веб-браузером. Давайте посмотрим, как протокол 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: ответ содержит SAML: Информация о утверждении.

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

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

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

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

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

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

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

Использование SAML с keycloak

Далее посмотрим, как настроить использование протокола SAML в keycloak.

Мы запускаем сервер keycloak с ./standalone.sh -Djboss.socket.binding.port-offset=100. доступhttp://localhost:8180/auth/adminВы можете войти в интерфейс консоли администратора.

Обратите внимание, что для того, чтобы отличаться от порта по умолчанию 8080 локального приложения, мы добавили параметр -Djboss.socket.binding.port-offset=100, чтобы изменить порт keycloak с 8080 на 8180.

Введите имя пользователя и пароль администратора, которые мы создали для входа в интерфейс администратора keycloak.

Здесь вам нужно создать новый клиент для приложения SAML.

Щелкните client-> create input ID клиента и Client Protocol: saml, нажмите save, чтобы создать нового клиента.

После успешного создания клиента, предполагая, что приложение, которое мы хотим развернуть, называется app-profile-saml, нам нужно добавить следующую информацию:

Valid Redirect URIs: http://localhost:8080/app-profile-saml/*

Base URL: http://localhost:8080/app-profile-saml/

Master SAML Processing URL: http://localhost:8080/app-profile-saml/saml

Force Name ID Format: ON

Нажмите, чтобы сохранить.

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

Для простоты мы выбираем средство сопоставления протоколов по умолчанию:

В качестве последнего шага нам нужно настроить адаптер.

Нажмите Установка, выберите KeyCloak Saml Adapter keycloak-saml.xml и нажмите Загрузить.

Измените загруженный файл keycloak-saml.xml:

Измените logoutPage="УКАЖИТЕ СТРАНИЦУ ВЫХОДА!" на /index.jsp

Измените entityID в entityID="saml-test" на установленный нами entityID

Скопируйте keycloak-saml.xml в каталог config/ нашего приложения. Здесь мы используем официальное приложение, его можно найти по адресуGitHub.com/key cloak/can…Скачать.

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

Подготовка и применение wildfy

После загрузки приложения wildfly с официального сайта wildfly нам также необходимо загрузить клиентские адаптеры wildfly с keycloak.

Здесь, поскольку мы используем SAML, нам нужно скачать keycloak-saml-wildfly-adapter-dist-11.0.2.zip.

После завершения загрузки скопируйте его в корневой каталог wildfly и разархивируйте.

Разархивируйте адаптер.После распаковки войдите в каталог wildfly/bin и запустите:

./jboss-cli.sh --file=adapter-elytron-install-offline.cli

Установка завершена.

После завершения установки не забудьте запустить приложения wildfly.

Теперь мы можем компилировать наше приложение:

cd app-profile-saml-jee-jsp 
mvn clean wildfly:deploy

Мы можем развернуть наше приложение на wildfly.

Сначала посмотрите на работу приложения, посетитеhttp://localhost:8080/app-profile-saml/

Нажмите на вход, вы увидите, что вы перешли на страницу входа в keycloak:

После ввода имени пользователя и пароля он перейдет на страницу profile.jsp, чтобы отобразить информацию о профиле пользователя.

Кратко объясните рабочий процесс приложения.

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

После ввода пользовательского имени и проверки пароля, keycloak A Samlresponse вернется к приложению, приложение по службе потребителей утверждений будет обработать запрос, создать соответствующий контекст безопасности, и пользовательский агент перенаправляется на страницу, которую вы хотите получить доступ к ресурсу Отказ

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

Ссылка на эту статью:Woohoo. Флойд press.com/key cloak-splash…

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

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

Категории