Открыть список
Как стать автором
Обновить
27,64
Рейтинг
Parimatch Tech
Parimatch Tech. Developing. Exciting.

Research the OpenSource: Ory/Hydra

Блог компании Parimatch TechИнформационная безопасностьПрограммированиеIT-стандартыРаспределённые системы

Меня зовут Богдан Хрисанфов и я работаю Lead System Analyst в Parimatch Tech. В этой статье постарался разобраться, что такое Hydra, и как она может помочь с множественными партнерскими интеграциями или предоставлением доступов к своему внешнему логину другим сервисам, аналогично логину в Google или Facebook.

Intro

Hydra — это облачная реализация Oauth2 с открытым исходным кодом (open-source).

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

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

Если хотите освежить в памяти Oauth2 или глубже понять его поток кода — переходите по ссылке на статью с погружением в тему.

Хороший пример работы Oauth2 — диаграмма последовательности UML:

Hydra упакована в docker и развернута в контейнере кластеров. Но в нашей серии «Использование исходного кода» мы сосредоточены на чтении исходного кода, чтобы изучить дизайн и реализацию программного обеспечения. Таким образом, если отложить стратегию развертывания, Hydra — это двоичный файл, написанный на Golang, который можно вызывать из командной строки.

Основные команды:

hydra clients | keys | serve| token.

Есть несколько других команд помощника, таких как:

hydra migrate sql, hydra token client, hydra token flush | revoke и hydra version.

Ниже рассмотрим команду hydra migrate sql, так как остальные не имеют особого значения для серии «Использования исходного кода».

Input

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

К счастью, здесь пригодится Cobra — библиотека для построения командной строки на основе Golang. Вы можете построить иерархию команд, прикрепив к родительской команде структуру, содержащую новую команду, описание и соответствующий обработчик. Обычно вы начинаете с корневой команды и создаете подкоманды для определенных функций, например, начиная с корня hydra, затем hydra clients, а затем hydra clients create.

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

  • постоянные флаги применяются к команде и всем ее подкомандам

  • локальные флаги применяются только к самой команде

Говоря о флагах, при написании серьезного программного обеспечения, такого как Identityserver, невозможно избежать конфигурирования. Конфигурация существует во многих различных форматах: файлы JSON, файлы YAML, переменные среды, удаленные серверы, вводы командной строки и так далее. Без подходящего инструмента каждая программа будет изобретать велосипед, чтобы понять различные форматы.

Чтобы понять различные форматы использую такие библиотеки как Viper. Он обеспечивает уровень абстракции над сложной группой возможных форматов конфигурации. Все, что нужно, это установить тип конфигурации (например, YAML), затем указать Viper на вход (например, файл) и указать ему прочитать конфигурацию. После этого все манипуляции с конфигурацией в коде так же просты, как получение и установка значений в структуре карты. При использовании Viper простая прямая конфигурация может быть слишком шаблонной для вызывающих абонентов. Флаги добавляются с течением времени, и они могут перекрывать друг друга или устаревать. Эта сложность не нужна для основной бизнес-логики.

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

Database Setup

База данных Hydra должна хранить пользовательскую информацию и технические параметры JWK (JSON Web Key), Oauth2 flow и т.д. Очень важно правильно настроить таблицы базы данных для правильной работы программного обеспечения.

Hydra предоставляет hydra migrate sql-команду для подготовки нужного набора таблиц базы данных за один раз. При вызове команды Hydra вызывает менеджер миграции базы данных: менеджер распечатывает изменения, которые Hydra планирует применить к базе данных, а затем выполняет эти изменения.

Кстати, для красивой модификации подачи данных мы используем небольшую библиотеку под названием tablewriter — это избавляет нас от рутинной задачи форматирования отступов в выводе консоли. Также tablewriter делает настройку базы данных управляемой, потому что его можно применять к существующим базам данных для добавления столбцов, индексов или удаления устаревших схем. Hydra управляет этим с помощью инструмента sql-migrate. Это также родной для Golang инструмент, в который Hydra напрямую интегрируется. Инструмент требует, чтобы изменения базы данных были написаны на SQL, как на их наиболее естественном языке, и сохранены в файлах.

Каждый файл содержит операторы SQL, которые сгруппированы в специальных комментариях +migrate Up и +migrate Down. Два комментария представляют собой инструкции для sql-migrate, чтобы взять набор операторов SQL в качестве миграции или отката и запустить их в транзакционном режиме.

Интересный и тонкий момент заключается в том, что, когда у вас есть несколько файлов SQL, sql-migrate сортирует их по имени файла и выполняет в указанном порядке.

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

Что еще стоит упомянуть: Hydra поддерживает несколько продуктов баз данных, таких как MySQL, PostgreSQL и CockroachDB. Также существует еще один уровень абстракции, который обрабатывает операции с базой данных, чтобы скрыть сложность различных продуктов баз данных.

Как и почти любое другое современное программное обеспечение, Hydra предоставляет базу данных в памяти для тестирования. База данных в оперативной памяти построена с использованием простых списков и карт для объектов, которые были бы записаны в таблицы базы данных. Эффективность не является первостепенной задачей, поскольку большинство компьютеров могут в мгновение ока перебирать сотни элементов списка / карты в памяти, и этого достаточно для тестирования.

Servers

Точка входа в основной корпус — hydra serve, который запускает серверы для потоков Oauth2. У серверов Hydra два набора конечных точек: административные и общедоступные.

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

Общедоступные API интерфейсы предназначены для операций приложения, например, для запроса авторизации, обмена токенами и других. Чтобы включить отдельные конфигурации безопасности, Hydra позволяет пользователям запускать два набора конечных точек на отдельных серверах: hydra serve public и hydra serve admin. Конечно, можно запустить их вместе hydra serve all.

Несмотря на два типа серверов, настройка серверов очень похожа. По сути, он создает легкий HTTP-сервер с соответствующей маршрутизацией и обработчиками. Hydra использует negroni. Есть много других подобных библиотек, конечная цель которых — создавать модульные веб-приложения. Интерфейсы этих библиотек обеспечивают инкрементную регистрацию обработчиков запросов для конечных точек.

Чтобы уточнить терминологию, конечная точка — это метод HTTP на пути URL.

В эти библиотеки также встроено множество настраиваемых «промежуточных программ» для оптимизации рабочих аспектов, таких как ведение журнала, анализ запросов, логика до / после, ограничение скорости и т. д.

Кстати, на мой взгляд, «промежуточное ПО» — это слишком перегруженный термин. В этом контексте это в основном означает слои оберток вокруг обработчика, через которые запрос и ответ будут изменяться / дополняться / отслеживаться по мере их прохождения.

В настройках сервера настроены четыре типа конечных точек. Некоторые из них являются конечными точками администратора, другие — общедоступными.

Первый тип интерфейсов — это клиентские API. API интерфейсы клиента — это API интерфейсы администратора. Внутренне логика довольно проста: client-структура определяется как информационная модель концепции клиента, которая содержит такие поля, как идентификатор клиента, секрет клиента, зарегистрированные области, URI перенаправления и многое другое. Клиентские API интерфейсы поддерживают операции create, get, list и delete с client-объектами, что приводит к изменению в текущей базе данных.

Второй тип интерфейсов — это API интерфейсы администратора, которые поддерживают как вход в систему, так и управление пользователем. Внутренне Get/Accept/Reject операции выполняются для входа пользователя и управление пользователем. Это API интерфейсы только для администратора, нацеленные на интеграцию с поставщиком удостоверений (IDP).

Чтобы использовать логин пользователя в качестве примера, в перенаправленный из Hydra к IDP запрос на вход включен параметр challenge. IDP будет использовать этот параметр challenge в качестве ключа поиска для Get-статуса входа в систему вместе с другой информацией о потоке авторизации от Hydra.

Если возвращается действительный сеанс входа из предыдущего входа в систему, IDP пропускает вход — в противном случае IDP требует входа в систему. После успешного входа в систему IDP отправляет Accept-запрос на подтверждение входа и перенаправляет приложение обратно в Hydra.

Если войти не удалось, IDP Reject вместо этого отправит ошибку. Теперь приложение вернулось в Hydra, и Hydra получила подтверждение входа в систему для авторизации. Согласие пользователя обрабатывается примерно так же. Очевидно, что это Get/Accept/Reject соответствует чтению / записи логина пользователя и данных авторизации в базе данных.

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

Третий тип конечных точек — это API интерфейсы веб-ключа JSON (JWK). Самый примечательный веб-ключ — это конечная точка для ./well_known/jwk.jsonвозврата открытого ключа для проверки токена. Существуют и другие API интерфейсы администратора для создания, установки, обновления и удаления ключей.

Последний тип конечных точек — это API интерфейсы Oauth2. Кроме того, администратор только introspect и flush(зачистка истекших лексем), наиболее важными являются два oauth2/authи oauth2/token API интерфейсы. oauth2/auth конечная точка используется для авторизации пользователя. После доступа Hydra выполнит типичный танец Oauth2 и вызовет рабочий процесс IDP, подробно описанный в конечных точках согласия выше. oauth2/token конечная точка используется для получения маркеров.

Есть много хороших материалов, которые представляют потоки Oauth2 в разной степени, например:

Cloing

В целом Hydra — очень лаконичная реализация, основная логика которой составляет менее 10 000 строк кода. Я настоятельно рекомендую прочитать исходный код, чтобы понять суть реализации Oauth2 и надеюсь, что это пригодится в ваших проектах.

Теги:аналитикhydraopensourcecobraviperjwkoauth2sqlmysqlcockroachdb
Хабы: Блог компании Parimatch Tech Информационная безопасность Программирование IT-стандарты Распределённые системы
Всего голосов 6: ↑5 и ↓1 +4
Просмотры1.5K

Комментарии 0

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

Лучшие публикации за сутки

Информация

Дата основания
Сайт
pm.tech
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре