Всестороннее введение в SSO (Single Sign On)

Spring

Полное название SSO на английском языке — Single SignOn, то есть единый вход. SSO заключается в том, что в системах с несколькими приложениями пользователям необходимо войти в систему только один раз, чтобы получить доступ ко всем взаимно доверенным системам приложений. Он включает механизмы для сопоставления этого основного входа с входами того же пользователя в других приложениях. Это одно из самых популярных решений для корпоративной бизнес-интеграции.

1. Механизм реализации

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

Во-вторых, преимущества использования SSO

  • Дружественный интерфейс Когда пользователи используют систему приложений, они могут войти в систему один раз и использовать ее несколько раз. Пользователям больше не нужно каждый раз вводить имя пользователя и пароль пользователя, а также запоминать несколько наборов имен пользователей и паролей пользователей. Платформа единого входа может улучшить взаимодействие с пользователем при использовании системы приложений.
  • Удобно для администраторов Системному администратору нужно только поддерживать единый набор учетных записей пользователей, что удобно и просто. Напротив, системным администраторам ранее приходилось управлять множеством наборов учетных записей пользователей. Каждая прикладная система имеет набор учетных записей пользователей, что не только создает неудобства для управления, но и чревато лазейками в управлении.
  • Упрощение разработки приложений При разработке новой прикладной системы вы можете напрямую использовать службу аутентификации пользователей платформы единого входа, чтобы упростить процесс разработки. Платформа единого входа реализует единый вход, предоставляя унифицированную платформу аутентификации. Следовательно, прикладная система не нуждается в разработке программы аутентификации пользователя.

3. Схема реализации SSO

Распространенные проблемы с междоменным входом

1. Для проблемы со входом в тот же корневой домен

Если на нашем сайте имеется более одного бизнеса, они могут быть развернуты на разных компьютерах и часто требуют различать разные доменные имена. Но все предприятия зависят от набора систем учетных записей, поэтому нам нужно решить проблему входа на все сайты через один логин в это время, тогда мы можем использовать самый глупый метод на данный момент: то есть успешный логин, написать Cookie Перейдите в корневой домен, тогда все сайты смогут реализовать совместное использование файлов cookie в одном и том же корневом домене, что, естественно, реализует «единый вход».

2. При проблемах со входом в несколько корневых доменов

При наличии нескольких имен корневых доменов описанный выше механизм не может обеспечить «единую регистрацию» в этом случае. Потому что вышеперечисленное позволяет добиться эффекта «единого входа». Это из-за поддержки браузера и протокола Http. Но совместное использование файлов cookie между сайтами через корневые домены является более сложным.

  • Способ 1. После успешного входа в систему запишите файл cookie обратно на несколько доменных имен.

Этот метод может быть очень простым, вы можете написать его через back-end response, а можете использовать для написания front-end js, но вы должны писать один за другим для всех сайтов, которые требуют «единого входа». Ногами так думать тоже не получится, потому что нужно вести список сайтов, который сложно и больно добавлять. Уничтожение файлов cookie также очень сложно, поскольку файлы cookie под всеми доменными именами все равно необходимо удалить. То есть работа, которую необходимо выполнить, увеличивается в n раз. Такой подход желателен для небольших сайтов.

  • Способ 2: jsonp

Те, кто работал на фронтенде, могут знать, что jsonp можно использовать для междоменных запросов, а мы решаем проблему единого входа под несколькими доменами, что кажется очень логичным. Однако вход в систему осуществляется на стороне сервера, верно? Мы делаем междоменную обработку на стороне клиента, что не очень разумно. В то же время этот метод требует больших затрат на обслуживание, и каждый запрос должен идти к фиксированному домену, чтобы получить соответствующий файл cookie перед выполнением запроса. Думайте, что техническое обслуживание — это головная боль.

  • Способ 3. Внедрить промежуточный сервер

Этот способ можно рассматривать как упрощенную версию SSO, да и идея реализации тоже весьма «хитрая». Тем не менее, для небольших веб-сайтов очень полезно выполнять междоменный вход в систему. Конкретные идеи заключаются в следующем:

Во-первых, у нас есть два доменных имени для единого входа, и нам нужен промежуточный сервер.

  1. У нас есть системное доменное имя xulingbo.net. Когда мы войдем в систему, посетите xulingbo.net/wp-login, чтобы войти. После успешного входа в систему файл cookie будет записан обратно на доменное имя xulingbo.

  2. У нас также есть системное доменное имя javaWeb.com. Когда мы заходим внутрь javaWeb, у нас нет файлов cookie, поэтому запрос переходит к промежуточному системному переходу. В это время вам нужно привести текущее доменное имя к параметру проверки перехода. Эта система прыжков находится в домене xulingbo: jump.xulingbo.net. В настоящее время вы можете получить файл cookie, записанный ранее в домене xulingbo.

  3. После того, как система переходов получает куки в домене xulingbo, она извлекает куки в домене xulingbo и перенаправляет запрос на jump.inside-javaWeb.net.Этот интерфейс также есть в системе переходов.После запроса система переходов записывает куки обратно в inside-javaWeb Под доменным именем это обеспечивает простой единый вход. Как показано ниже:

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

  • Метод 4: система SSO на основе CAS

Полное название CAS: Central Authentication Service, которая является хорошей платформой единого входа для веб-приложений, включая java, .net, PHP, Prel, Apache, uPortal, Ruby и т. д. . Механизм реализации не сложный, но идея очень умная. Единый вход также можно быстро реализовать с помощью CAS. Украденное изображение иллюстрирует процесс входа и проверки одного домена sso:

CAS в основном делится на клиент CAS и сервер CAS, где клиент в основном встроен в перехватчик или фильтр, который требует SSO для входа на сайт.

  1. Сначала браузер инициирует запрос к сайту 1.
  2. Сайт 1 обнаруживает, что текущий запрос не имеет легального файла cookie, а затем перенаправляет на сервер CAS, который является сервером единого входа.
  3. Сервер CAS отображает интерфейс входа в систему и требует от пользователя входа в систему.
  4. После того, как пользователь войдет в систему, файл cookie сервера CAS будет записан в браузер, одновременно с этим будет сгенерирован билет, а для перехода к CASClient будет использоваться код 302. Это гарантирует, что пользователь не знает об этом.
  5. Клиент CAS использует сгенерированный билет, чтобы отправить его на сервер CAS для проверки.После того, как проверка пройдена, сайт 1 создает свой собственный файл cookie и записывает его обратно в браузер пользователя, а затем выполняет успешный вход в систему.

Это гарантирует, что текущий браузер имеет файл cookie сайта 1 под доменным именем сайта 1, а текущий браузер также имеет файл cookie сервера CAS. Далее смотрим логин сайта 2:

Сайт 2 при входе в систему аналогичен начальному процессу входа на сайт 1, но при доступе к серверу CAS, поскольку текущий браузер уже имеет файл cookie сервера CAS, прямая проверка возвращает билет. Билет переходит к клиенту CAS через переход 302, и последующий процесс такой же, как и на сайте 1. Если в этот раз аутентификация не удалась, вам необходимо снова пройти процесс входа в систему.

Вопросы, на которые следует обратить внимание: 1. Проблема захвата куки сервера CAS Если куки сервера CAS перехвачены, это эквивалентно получению всего, поэтому для реализации этого процесса необходимо использовать HTTPS. 2. Использование билета, билет можно использовать только один раз, и он будет недействителен сразу после проверки. В то же время он должен быть чувствительным ко времени, обычно 5 минут. Наконец, правила генерации билетов должны быть случайными и не должны противоречить друг другу. 3. Для собственного сеанса каждой системы также может использоваться SSO, который может обеспечить согласованность всех правил сеанса и облегчить централизованный контроль.

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

  • Вызов службы Soa для входа и выхода Недостатки: вы должны реализовать это самостоятельно, чтобы определить, вошел ли пользователь в систему и истек ли срок сеанса; отсутствие контроля разрешений, вы должны реализовать это самостоятельно Преимущество: простота реализации
  • Самостоятельно реализовать функцию входа в систему в веб-сервисе низкий уровень безопасности
  • Используйте Spring Security + Oauth2 для реализации функции входа в систему Плюсы: корпоративный уровень, высокий уровень безопасности. Предоставляет различные методы проверки безопасности Может обрабатывать сложный контроль разрешений

​

4. Введение в Spring Security

  • Что такое Spring Security?

Spring security — это мощная и настраиваемая среда аутентификации и контроля доступа, которая предоставляет комплексные службы безопасности для предприятий на основе JavaEE. Это стандарт де-факто для защиты приложений на основе Spring. Основная роль — «аутентификация» и «авторизация» (или контроль доступа). На уровне аутентификации Spring Security поддерживает несколько режимов аутентификации.

  • основная функция 1. Аутентификация (кто вы) 2. Авторизация (что можно сделать) 3. Защита от атак (предотвращение подделки личных данных)
  • Что такое Spring Security Authentication?
  1. Пользователю предлагается ввести имя пользователя и пароль для входа в систему.
  2. Система (успешно) проверяет правильность пароля для имени пользователя.
  3. Получить контекстную информацию для этого пользователя (список его ролей и т. д.).
  4. Создайте безопасную среду для пользователей.
  5. Пользователь может выполнять некоторые операции, потенциально защищенные механизмом управления доступом, проверять необходимые разрешения и работать с текущей информацией о среде безопасности.

Введение в процесс проверки

  1. Имя пользователя и пароль объединяются в экземпляр UsernamePasswordAuthenticationToken (экземпляр интерфейса Authentication, который мы видели ранее).
  2. Маркер передается экземпляру AuthenticationManager для проверки.
  3. AuthenticationManager полностью заполняет экземпляр Authentication, чтобы вернуть успешную аутентификацию.
  4. Контекст безопасности устанавливается путем вызова SecurityContextHolder.getContext().setAuthentication(…​) с передачей возвращенного объекта проверки подлинности.

5. ОАВТ2

  • определение существительного
  1. Стороннее приложение: стороннее приложение, также известное в этой статье как «клиент».
  2. Служба HTTP: поставщик службы HTTP, именуемый в этой статье «поставщик службы».
  3. Владелец ресурса: владелец ресурса, также известный как «пользователь» в этой статье.
  4. Пользовательский агент: Пользовательский агент, обычно относится к браузеру.
  5. Сервер авторизации: Сервер аутентификации, то есть сервер, специально используемый поставщиком услуг для обработки аутентификации.
  6. Сервер ресурсов: Сервер ресурсов, то есть сервер, на котором поставщик услуг хранит ресурсы, созданные пользователем. Он и сервер аутентификации могут быть одним сервером или другим сервером.
  • Идея OAuth

OAuth устанавливает уровень авторизации между «клиентом» и «поставщиком услуг». «Клиент» не может напрямую войти в «поставщика услуг», только уровень авторизации, который отличает пользователя от клиента. Токен, используемый «клиентом» для входа на уровень авторизации, отличается от пароля пользователя. Пользователь может указать область разрешений и срок действия токена уровня авторизации при входе в систему. После того, как «клиент» входит в систему на уровне авторизации, «поставщик услуг» открывает данные, сохраненные пользователем, «клиенту» в соответствии с областью разрешений и сроком действия токена.

  • запустить процесс

(A) После того, как пользователь открывает клиент, клиент запрашивает у пользователя авторизацию. (B) Пользователь соглашается предоставить Клиенту авторизацию. (C) Клиент использует авторизацию, полученную на предыдущем шаге, для запроса маркера с сервера аутентификации. (D) После того, как сервер аутентификации аутентифицирует клиента, он подтверждает правильность и соглашается выдать токен. (E) Клиент использует токен для обращения к серверу ресурсов для получения ресурса. (F) Сервер ресурсов подтверждает правильность токена и соглашается открыть ресурс клиенту. Нетрудно заметить, что среди шести вышеперечисленных шагов B является ключом, то есть как пользователь может авторизовать клиента. С этой авторизацией клиент может получить токен, а затем использовать токен для получения ресурсов.

В сочетании с приведенным выше рисунком использование oauth2 для защиты вашего приложения можно разделить на три простых шага.

  1. Настройте службу авторизации сервера ресурсов.
  2. Настройте службу ресурсов сервера аутентификации.
  3. настроить весеннюю безопасность

Все запросы на получение токенов будут обрабатываться в конечных точках контроллера Spring MVC, а доступ защищен. Поток обработки службы ресурсов будет помещен в стандартные фильтры запросов Spring Security (фильтры). Ниже перечислены конечные точки, которые необходимо реализовать для настройки службы авторизации. -AuthorizationEndpoint: служба, используемая для авторизации в качестве отправителя запроса, URL-адрес по умолчанию — /oauth/authorize. -TokenEndpoint: служба, используемая для получения токена (токена) в качестве запрашивающей стороны, URL-адрес по умолчанию — /oauth/token.

  • Режим авторизации клиента

Клиент должен быть авторизован пользователем (предоставление авторизации), чтобы получить токен (токен доступа). OAuth 2.0 определяет четыре метода авторизации.

  1. Код авторизации
  2. Упрощенный режим (неявный)
  3. Режим пароля (учетные данные пароля владельца ресурса)
  4. Режим клиента (учетные данные клиента)

Пояснение к режиму авторизации

  • Режим кода авторизации

Режим кода авторизации (код авторизации) — это режим авторизации с наиболее полными функциями и самым строгим процессом. Его характеристикой является взаимодействие с сервером аутентификации «поставщика услуг» через фоновый сервер клиента.

Его шаги следующие:
(A) Пользователь обращается к клиенту, который направляет его на сервер аутентификации.
(B) Пользователь выбирает, авторизовать ли клиента.
(C) Предполагая, что пользователь предоставляет авторизацию, сервер аутентификации направляет пользователя на «URI перенаправления» (URI перенаправления), заранее указанный клиентом, вместе с кодом авторизации.
(D) Клиент получает код авторизации, прикрепляет более ранний «URI перенаправления» и запрашивает токен с сервера аутентификации. Этот шаг выполняется на сервере в фоновом режиме клиента, невидимом для пользователя.
(E) Сервер аутентификации проверяет код авторизации и URI перенаправления и после подтверждения их правильности отправляет токен доступа и токен обновления клиенту.

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

  • --response_type: указывает тип авторизации, требуется, значение здесь фиксируется как «код»
  • --client_id: указывает идентификатор клиента, обязательный
  • --redirect_uri: указывает URI перенаправления, необязательно
  • --scope: указывает область применения разрешений, необязательно
  • --state: Указывает текущее состояние клиента, вы можете указать любое значение, и сервер аутентификации вернет это значение без изменений.
demo:
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

На шаге C сервер отвечает на URI клиента со следующими параметрами: --code: указывает требуемый код авторизации. Срок действия кода должен быть очень коротким, обычно устанавливается на 10 минут, и клиент может использовать код только один раз, иначе он будет отклонен сервером авторизации. Существует однозначное соответствие между этим кодом и идентификатором клиента и URI перенаправления. --state: если запрос клиента содержит этот параметр, ответ сервера аутентификации также должен точно содержать этот параметр.

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz

На шаге D клиент делает HTTP-запрос токена с сервера аутентификации, включая следующие параметры:

  • --grant_type: Указывает используемый режим авторизации, обязательная опция, значение здесь фиксировано как «authorization_code».
  • --code: указывает код авторизации, полученный на предыдущем шаге, является обязательным.
  • --redirect_uri: указывает URI перенаправления, который требуется и должен совпадать со значением параметра на шаге A.
  • --client_id: указывает требуемый идентификатор клиента.

На шаге E ответ HTTP, отправленный сервером аутентификации, содержит следующие параметры:

  • --access_token: указывает требуемый токен доступа.
  • --token_type: указывает тип токена. Значение не чувствительно к регистру. Обязательно. Это может быть тип носителя или тип mac.
  • --expires_in: указывает время истечения срока действия в секундах. Если этот параметр опущен, время истечения необходимо задать другими способами.
  • --refresh_token: указывает токен обновления, который используется для получения следующего токена доступа, необязательно.
  • --scope: Указывает объем полномочий.Если он соответствует объему, применяемому клиентом, этот пункт можно опустить.

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

  • упрощенный режим Упрощенный режим (тип неявного гранта) не проходит через сервер стороннего приложения, а напрямую запрашивает токен с сервера аутентификации в браузере, пропуская шаг «код авторизации», отсюда и название. Все шаги выполняются в браузере, токен виден посетителю, а клиент не требует аутентификации.

Его шаги следующие: (A) Клиент направляет пользователя на сервер аутентификации.
(B) Пользователь решает, авторизовать ли клиента.
(C) Предполагая, что пользователь предоставляет авторизацию, сервер аутентификации направляет пользователя на «URI перенаправления», указанный клиентом, и включает токен доступа в хэш-часть URI.
(D) Браузер делает запрос к серверу ресурсов, который не включает хеш-значение, полученное на предыдущем шаге.
(E) Сервер ресурсов возвращает веб-страницу, содержащую код для получения токена в хеш-значении.
(F) Браузер выполняет сценарий, полученный на предыдущем шаге, для извлечения токена.
(G) Браузер отправляет токен клиенту.

Ниже приведены параметры, необходимые для вышеуказанных шагов.
На шаге A HTTP-запрос, отправленный клиентом, содержит следующие параметры:

  • -response_type: Указывает тип авторизации.Значение здесь фиксировано на «токен», что является обязательным.
  • -client_id: Указывает идентификатор клиента, который требуется.
  • -redirect_uri: указывает URI перенаправления, необязательно.
  • -scope: указывает область разрешений, необязательно.
  • -state: Указывает текущее состояние клиента, вы можете указать любое значение, и сервер аутентификации вернет это значение без изменений.

Ниже приведен пример:

   GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

На шаге C сервер аутентификации отвечает на URI клиента со следующими параметрами:

  • -access_token: указывает требуемый токен доступа.
  • -token_type: указывает тип токена Значение нечувствительно к регистру и является обязательным.
  • -expires_in: указывает время истечения срока действия в секундах. Если этот параметр опущен, время истечения необходимо задать другими способами.
  • -scope: Указывает объем полномочий.Если он соответствует объему, применяемому клиентом, этот элемент можно опустить.
  • -state: если запрос клиента содержит этот параметр, ответ сервера аутентификации также должен точно содержать этот параметр.

Ниже приведен пример:

HTTP/1.1 302 Found
     Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
               &state=xyz&token_type=example&expires_in=3600
  • режим пароля

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

Его шаги следующие:
(A) Пользователь предоставляет клиенту имя пользователя и пароль.
(B) Клиент отправляет имя пользователя и пароль на сервер аутентификации и запрашивает токен у последнего.
(C) После того, как сервер аутентификации подтвердит правильность, он предоставляет токен доступа клиенту.

На шаге B HTTP-запрос, отправленный клиентом, содержит следующие параметры:
-grant_type: Указывает тип авторизации.Значение здесь фиксировано на «пароль», что является обязательным.
-username: Указывает обязательное имя пользователя.
-password: указывает пароль пользователя, обязательный.
-scope: указывает область разрешений, необязательно.

Ниже приведен пример:

   POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=password&username=johndoe&password=A3ddj3w

На шаге C сервер аутентификации отправляет токен доступа клиенту, пример ниже.

HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

Информацию о других сертификатах см. по следующему справочному адресу.

  • клиентский режим Режим клиента (предоставление учетных данных клиента) означает, что клиент аутентифицируется у «поставщика услуг» от своего имени, а не от имени пользователя. Строго говоря, клиентский режим не является частью проблемы, которую призван решить фреймворк OAuth. В этом режиме пользователь регистрируется напрямую у клиента, а клиент запрашивает у «поставщика услуг» предоставление услуг от своего имени, по сути проблемы с авторизацией не возникает.

Его шаги следующие:
(A) Клиент аутентифицируется на сервере аутентификации и запрашивает токен доступа.
(B) После того, как сервер аутентификации подтвердит правильность, он предоставляет токен доступа клиенту.

На шаге A HTTP-запрос, отправленный клиентом, содержит следующие параметры:
-granttype: указывает тип гранта, значение здесь фиксировано как «clientcredentials», обязательный параметр.
-scope: указывает область разрешений, необязательно.

POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=client_credentials

Сервер аутентификации должен каким-то образом проверить личность клиента. На шаге B сервер аутентификации отправляет токен доступа клиенту, пример ниже.

HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "example_parameter":"example_value"
     }

Прикреплен проект spring-security+oauth2, который я написал сам, который можно использовать для справки.Во всяком случае, мой собственный проект использует это.GitHub.com/подключиться в зоне/…
Другой метод единого входа:Единый вход Keycloak

обо мне

Продолжайте выводить оригинальные статьи, этоЛю Жунцзе1-я оригинальная статья

Категории