Для реализации микросервисов в основном приложении используется Flask, небольшой и мощный веб-фреймворк для Python. Он прост в освоении и использовании, что позволяет создавать веб-приложения за короткий промежуток времени.

3.1.1 Хранение данных

В качестве СУБД, с которой будут взаимодействовать микросервисы приложения выбраны NoSQL СУБД Redis и MongoDB.

MongoDB -- это NoSQL база данных с открытым исходным кодом, ориентированная на документы. MongoDB позволяет хранить записи в коллекциях (альтернатива таблицам) в виде документов в формате JSON. В проекте MongoDB будет использоваться как основная СУБД, в которой будут храниться данные пользователей и клиентов. [17]

Redis является NoSQL СУБД с открытым исходным кодом (лицензия BSD), in-memory хранилища структуры данных, используется в качестве базы данных, кэша и брокера сообщений. Он поддерживает структуры данных, такие как строки, хэши, списки, наборы, сортированные наборы с запросами диапазона, растровые изображения, гиперлоги, геопространственные индексы с запросами radius и потоками. Redis имеет встроенную репликацию, сценарии Lua, исключение LRU, транзакции и различные уровни сохраняемости на диске, а также обеспечивает высокую доступность через Redis Sentinel и автоматическое секционирование с помощью кластера Redis. Redis используется в проекте для хранения токенов доступа пользователей к сервисам приложения до тех пор, пока время жизни токена не истечет. [18]

3.1.2 Elasticsearch

Elasticsearch - продукт с открытым исходным кодом, осуществляющий распределенный поиск и аналитику, построенный на базе на Apache Lucene. Продукт обеспечивает restful стиль взаимодействия с клиентами. [19] С момента своего выпуска в 2010 году Elasticsearch быстро стал самой популярной поисковой системой и обычно используется для анализа журналов, полнотекстового поиска, аналитики безопасности, бизнес-аналитики и вариантов использования оперативной аналитики.

В Elasticsearch схема данных изначально может быть не задана. Сервер Elasticsearch умеет строить предположения о типе данных на основе полученного JSON-документа. Но для того, чтобы производительность была достаточно высокой, разработчику стоит задавать схемы данных изначально, используя специализированные инструменты Elasticsearch.

В Elasticsearch авторизация пользователей СУБД реализована в виде отдельного модуля, приобретаемого дополнительно. В отсутствие данного модуля доступ к Elasticsearch-кластеру есть у любого пользователя (в том числе возможность получения прав суперпользователя).

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

3.1.3 Развертывание

Приложение разворачивается посредством развертывания docker-machine.

Docker -- это инструмент, предназначенный для упрощения создания, развертывания и запуска приложений с помощью контейнеров. Контейнеры позволяют разработчику упаковать приложение со всеми необходимыми ему частями, такими как библиотеки и другие зависимости, и отправить все это как один пакет. Таким образом, благодаря контейнеру разработчик может быть уверен, что приложение будет запущено на любой другой машине Linux, независимо от любых настраиваемых параметров, которые могут отличаться от машины, используемой для написания и тестирования кода. [20]

В некотором смысле Docker немного похож на виртуальную машину. Но в отличие от виртуальной машины вместо того, чтобы создавать целую виртуальную операционную систему, Docker позволяет приложениям использовать то же ядро Linux, что и система, в которой они работают, и требует, чтобы приложения были отправлены с вещами, которые еще не запущены на хост-компьютере. Это дает значительный прирост производительности и уменьшает размер приложения.

Рис. 4. Структура виртуальных машин и контейнеров [37]

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

Рис. 5. Структура системы в контейнере

Docker может создавать образы автоматически, читая инструкции из файла Dockerfile. Dockerfile -- это текстовый документ, содержащий все команды, которые пользователь может вызвать в командной строке для сборки изображения. С помощью docker build разработчик может создать автоматическую сборку, которая выполняет несколько команд командной строки подряд.

Команда docker build создает образ из файла Dockerfile и контекста. Контекст сборки -- это набор файлов по указанному пути или URL-адресу. Путь -- это каталог в локальной файловой системе. URL-адрес является местоположением репозитория Git.

Контекст обрабатывается рекурсивно. Таким образом, путь включает любые подкаталоги, а URL-адрес включает репозиторий и его подмодули. В этом примере показана команда сборки, использующая текущий каталог в качестве контекста:

Рис. 6. Команда сборки контейнера

Сборка выполняется процессом (linux daemon) Docker. Первое, что делает процесс сборки, -- это отправляет весь контекст (рекурсивно) демону. В большинстве случаев лучше всего начать с пустого каталога в качестве контекста и сохранить Dockerfile в этом каталоге. Добавляются только файлы, необходимые для создания Dockerfile.

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

Для использования файла в контексте сборки Dockerfile ссылается на файл, указанный в инструкции, например инструкции копирования. Чтобы повысить производительность сборки, исключаются файлы и каталоги, добавив файл .dockerignore в контекстный каталог.

Традиционно файл Dockerfile называется Dockerfile и находится в корне контекста. Флаг -f в команде docker build используется для указания на файл Dockerfile в любом месте файловой системы.

Рис. 7. Пример Dockerfile

3.1.4 Интеграция

Continuous Integration (CI) и Continuous Deployment (CD) -- это две аббревиатуры, которые часто упоминаются, когда люди говорят о современной практике развития. CI прост и выступает за непрерывную интеграцию, практику, которая фокусируется на упрощении подготовки выпуска. CD может означать либо непрерывную доставку, либо непрерывное развертывание, и, хотя эти две практики имеют много общего, они также имеют существенное различие, которое может иметь критические последствия для бизнеса.

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

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

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

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

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

Непрерывное развертывание - отличный способ ускорить цикл обратной связи с вашими клиентами и снять давление с разработчиков, поскольку больше нет дня выпуска. Разработчики могут сосредоточиться на создании программного обеспечения, и они видят, что их работа идет в прямом эфире после того, как они закончили работу над ним. [21]

3.2 Аутентификация

Блок аутентификации реализован посредством использования библиотеки с открытыми исходным кодом Flask-sentinel [22].

Flask-Sentinel является реализацией сервера OAuth2, шаблона предоставления учетных данных владельца ресурса, описанного в разделе 1.3.3 RFC 6749. Он работает в связи с Flask-Oauthlib, Redis и MongoDB и поставляется в комплекте в качестве расширения, поэтому он может быть использован для добавления возможностей OAuth2 к существующему приложению.

Итак, представим стандартный клиентский сценарий. Пользователь только что установил приложение на своем устройстве. При первом запуске его/ее просят предоставить его /ее имя пользователя и пароль. Они отправляются на сервер OAuth2 по зашифрованному каналу SSL/TLS. Если пользователь зарегистрирован для службы и идентификатор клиента, который также был отправлен вместе с учетными данными пользователя, распознается, сервер отправляет обратно действительный маркер доступа. В противном случае отвечает 401 Unauthorized.

Отныне приложение будет использовать маркер доступа только для всех запросов до истечения срока действия маркера. Если это происходит, цикл повторяется. Стоит обратить внимание, что в этом случае клиенту не нужно (и, вероятно, не следует) хранить имя пользователя и/или пароль в локальном кэше. Шаблон учетных данных пользователя обычно зависит от долгоживущих токенов, поэтому повторный запрос имени пользователя и пароля не имеет большого значения (также возможно выбрать постоянные, отзываемые токены.)

Flask-Sentinel предоставляет две конечные точки: одну для создания токена, который по умолчанию /oauth/token и используется клиентами, и другую для управления пользователями и клиентами, доступную в /oauth/management:

Рис. 8. Менеджмент пользователей и клиентов.

Пароль хэшируется и солится на сервере, поэтому простой пароль не хранится по обе стороны канала.

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

Рис. 9. Получение токена для клиента и пользователя

Рис. 10. Получение токена аутентификации

Рис. 11. Использование токена

Конечно, есть несколько вариантов конфигурации, например, можно задать персональный url-адрес маркера и конечных точек управления, установить срок действия маркера, настроить соединение с базой данных и т. д. Redis используется библиотекой для хранения активных маркеров доступа, что обеспечивает максимальную производительность.

При реализации прототипа в качестве хранилища данных вместо MongoDB для данных и Redis для маркеров доступа может использоваться Elasticsearch (ES). [23]

3.3 Микросервисы

В прототипе реализовано 3 микросервиса, каждый из которых отвечает за конкретную функциональность:

- менеджер паролей;

- рассылка почты;

- телеграм-рассылка.

В каждом микросервисе реализовано два метода: GET и POST для базовой демонстрации работы сервисов.

Рис. 12. Схема взаимодействия микросервисов

3.3.1 API

Менеджер паролей:

GET /my

В случае, когда пользователь не указал токен аутентификации, когда токен аутентификации не найден, когда не указан логин пользователя, пользователю возвращается ответ `User not authorized/found' с кодом ответа HTTP 401 Unauthorized.

В случае успешного выполнения описанных выше условий, пользователю возвращается ответ в формате 'Your login: <login>, You introduced yourself as <username>, Your notifications are sent at <email>, Our bot knows you as <telegram_id> Your role at our service is <role>.', код ответа HTTP 200, success.

POST /restore

В случае, когда пользователь не указал токен аутентификации, когда токен аутентификации не найден, когда не указан логин пользователя, пользователю возвращается ответ `User not authorized/found' с кодом ответа HTTP 401 Unauthorized.

В случае, если почта пользователя неизвестна, возвращается ответ в формате 'Cannot change your password. We need your email for password recovery.', код ответа HTTP 403, Access denied.

В случае успешного выполнения описанных выше условий, пользователю возвращается ответ в формате `Email was sent. ', код ответа HTTP 200, success.

Рассылка почты:

GET /my

В случае, когда пользователь не указал токен аутентификации, когда токен аутентификации не найден, когда не указан логин пользователя, пользователю возвращается ответ `User not authorized/found' с кодом ответа HTTP 401 Unauthorized.

В случае, если почта пользователя неизвестна, возвращается ответ в формате 'You did not specified your email.', код ответа HTTP 200, Success.

В случае успешного выполнения описанных выше условий, пользователю возвращается ответ в формате `Your email: <email>', код ответа HTTP 200, success.

POST /send

В случае, когда пользователь не указал токен аутентификации, когда токен аутентификации не найден, когда не указан логин пользователя, пользователю возвращается ответ `User not authorized/found' с кодом ответа HTTP 401 Unauthorized.

В случае, если пользователь не указал текст письма и/или перечень получателей, возвращается ответ в формате 'Please, specify text and recipients.', код ответа HTTP 400, Bad request.

В случае успешного выполнения описанных выше условий, пользователю возвращается ответ в формате `Email was sent.', код ответа HTTP 200, success.

Телеграм-рассылка:

GET /my

В случае, когда пользователь не указал токен аутентификации, когда токен аутентификации не найден, когда не указан логин пользователя, пользователю возвращается ответ `User not authorized/found' с кодом ответа HTTP 401 Unauthorized.

В случае, если почта пользователя неизвестна, возвращается ответ в формате 'You did not specified your nickname.', код ответа HTTP 200, Success.

POST /send

В случае, когда пользователь не указал токен аутентификации, когда токен аутентификации не найден, когда не указан логин пользователя, пользователю возвращается ответ `User not authorized/found' с кодом ответа HTTP 401 Unauthorized. В случае, если пользователь не указал текст письма и/или перечень получателей, возвращается ответ в формате 'Please, specify text for sending and chat id.', код ответа HTTP 400, Bad request.

В случае успешного выполнения описанных выше условий, пользователю возвращается ответ в формате `Text was sent.', код ответа HTTP 200, success.

3.3.2 Базовый помощник

Базовый помощник - общий файл формата .py, содержащий в себе две функции:

- base_response(text[str], code[int]);

- check_auth(db[connector.Database]).

Функция base_response возвращает ответ формата flask.Response с маркированным текстом и кодом ответа, по умолчанию 200.

Функция check_auth производит валидацию токена при запросе в микросервис, в случае, когда токен не выдан, истекло время жизни или пользователь, которому принадлежит токен, не найден, возвращается ответ `User not authorized/found' с кодом ответа HTTP 401 Unauthorized.

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

3.3.3 Подключение к MongoDB

Подключение к СУБД производится посредством вызова функции connect(), внутри которой происходит проверка конфигурации микросервиса. Для подключения к СУБД необходимы следующие параметры:

- DB_USER;

- DB_PASSWORD;

- DB_HOSTS;

- DB_PORT;

- DB_NAME.

Из перечисленных параметров формируется строка подключения формата 'mongodb://{user}:{password}@{hosts}/{database}'.

Функция возвращает базу данных, заданную в параметре DB_NAME.

Исходный код приложения хранится в открытом репозитории GitHub. [24]

Заключение

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

В ходе исследования были получены следующие результаты:

- проведен подробный обзор микросервисной архитектуры приложений;

- составлен перечень основных требований к реализации сквозного механизма аутентификации с учетом особенностей архитектуры приложений;

- составлен перечень требований безопасности, предъявляемых к механизму аутентификации;

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

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

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

Выпускная квалификационная работа выполнена в полном объеме в соответствии с поставленными целями и задачами, обозначенными в начале работы.

Реализация прототипа приложения выполнена на языке Python3.6.6 с использованием фреймворка Flask в микросервисах, библиотек Authlib и Flask-sentinel для реализации сквозной аутентификации.

Для хранения данных выбрана NoSQL система управления базами данных MongoDB, поскольку является документоориентированной и гибкой СУБД в сравнении с SQL.

Созданный прототип использует публичную систему контроля версий GitHub, развертывание производится посредством контейнеризации в Docker.

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

Литература

1) Identification, Authentication, and Authorization. URL: https://blogs.getcertifiedgetahead.com/identification-authentication-authorization/ (дата обращения 04.12.18)

2) Понятие модульности. URL: https://ru.wikipedia.org/wiki/Модульность (дата обращения 05.01.19)

3) Service-oriented architecture. URL: https://en.wikipedia.org/wiki/Service-oriented_architecture (дата обращения 05.01.19)

4) Nadareishvili I., Mitra R., McLarty M., Amundsen M., Microservice Architecture: Aligning Principles, Practices, and Culture. O'Reilly 2016

5) Модели доменов. URL: https://studopedia.ru/2_83871_modeli-domenov.html (дата обращения 13.02.19)

6) Single responsibility principle. URL: https://en.wikipedia.org/wiki/Single_responsibility_principle (дата обращения 21.11.18)

7) Stateless protocol. URL: https://en.wikipedia.org/wiki/Stateless_protocol (дата обращения 30.11.18)

8) Best practices for microservices app sec. URL: https://techbeacon.com/app-dev-testing/8-best-practices-microservices-app-sec

9) Abate, Aiken, Burke, Robert J., Dr. Peter, Joseph N. (2000). Achieving EAI Using A Services-Based Architecture. Wiley & Sons.

10) Istio / Security. URL: https://istio.io/docs/concepts/security/ (дата обращения 14.04.19)

11) Аутентификация и авторизация в микросервисных приложениях. URL: https://habr.com/company/dataart/blog/311376/ (дата обращения 03.12.18)

12) SSL. URL: https://en.wikipedia.org/wiki/SSL (дата обращения 19.03.19)

13) Man-in-the-middle attack. URL: https://en.wikipedia.org/wiki/Man-in-the-middle_attack (дата обращения 19.03.19)

14) How does Multi-Factor Authentication work? URL: https://www.onelogin.com/learn/what-is-mfa (дата обращения 18.04.19)

15) Hardt D., ed. "Interoperability". The OAuth 2.0 Authorization Framework. IETF. sec. 1.8. doi:10.17487/RFC6749. RFC 6749. Retrieved 8 May 2013.

16) Welcome to OpenID Connect. URL: https://openid.net/connect/ (дата обращения 10.02.19)

17) MongoDB. URL: https://www.mongodb.com (дата обращения 07.12.18)

18) Redis. URL: https://redis.io (дата обращения 07.12.18)

19) Elasticsearch as a NoSQL Database. URL: https://www.elastic.co/blog/found-elasticsearch-as-nosql

20) Dockerfile. URL: https://docs.docker.com/engine/reference/builder/ (дата обращения 18.04.19)

21) Continuous integration vs. continuous delivery vs. continuous deployment. URL: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment (дата обращения 18.04.19)

22) How about a Sentinel for your Flask Application? URL: https://nicolaiarocci.com/a-sentinel-for-your-flask-applications/ (дата обращения 04.12.18)

23) Elasticsearch как NoSQL база данных. URL: https://habr.com/ru/company/percolator/blog/222765/ (дата обращения 18.04.19)

24) Microservices: Source code. URL: https://github.com/valkharb/microservices (дата обращения 20.04.19)

25) Brandner M., Zimmermann O., Oellermann F., Craes M., Web Services-Oriented Architecture in Production in the Finance Industry, Informatik-Spektrum 02/2004, Springer-Verlag, 2004

26) Authlib 0.11.dev documentation. URL: https://docs.authlib.org/en/latest/flask/2/grants.html (дата обращения 13.03.19)

27) Микросервисы (Microservices). URL: https://habr.com/post/249183/ (дата обращения 04.12.18)

28) Example of Microservices written using Flask. URL: https://github.com/umermansoor/microservices (дата обращения 20.12.18)

29) Быстрый запуск и использование своего открытого docker-registry. URL: https://habr.com/post/279659/ (дата обращения 27.12.18)

30) OAuth2 Server bundled as a Flask extension. URL: https://github.com/pyeve/flask-sentinel/tree/342f49a650a9c31663b1ce9e83721a4c2512e1b8 (дата обращения 27.12.18)

31) How to Create a Microservices Setup. URL: https://smartbear.com/learn/api-design/how-to-create-a-microservices-setup/ (дата обращения 14.12.18)

32) Microservices Authentication and Authorization Solutions. URL: https://medium.com/tech-tajawal/microservice-authentication-and-authorization-solutions-e0e5e74b248a (дата обращения 05.12.18)

33) Microservices Authentication & Authorization Best Practice. URL: https://codeburst.io/i-believe-it-really-depends-on-your-environment-and-how-well-protected-the-different-pieces-are-7919bfa6bc86 (дата обращения 08.12.19)

34) 3 Common Methods of API Authentication Explained. URL: https://nordicapis.com/3-common-methods-api-authentication-explained/

35) Сравнение шаблона шлюза API с прямым взаимодействием клиента и микрослужбы. URL: https://docs.microsoft.com/ru-ru/dotnet/standard/microservices-architecture/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern (дата обращения 30.11.18)

36) Мартынова Л.Е., Назарова К.Е., Попков С.М. Определение критериев оценки для подбора оптимального метода аутентификации // Молодой ученый. -- 2016. -- №27. -- С. 119-122. URL: https://moluch.ru/archive/131/36402/ (дата обращения: 18.04.2019)

37) Introducing OAuth 2.0. URL: https://hueniverse.com/introducing-oauth-2-0-b5681da60ce2?gi=b76df7e90eae (дата обращения 16.02.19)

38) Containers vs. Virtual Machines (VMs): What's the Difference? URL: https://blog.netapp.com/blogs/containers-vs-vms/ (дата обращения 11.05.2019)

39) Введение в OAuth 2. URL: https://www.digitalocean.com/community/tutorials/oauth-2-ru (дата обращения 13.05.2019)

40) Representational state transfer. URL: https://en.wikipedia.org/wiki/Representational_state_transfer



Размещено на Allbest.ru

...