Сопоставление запросов к клиентам в мультитенантном решении

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

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

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

Подходы к идентификации клиентов

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

Доменные имена

Если вы используете имена доменов или поддоменов для конкретного клиента, скорее всего, запросы можно легко сопоставить с клиентами с помощью Host заголовка, заголовка или другого HTTP-заголовка X-Forwarded-Host , включающего исходное имя узла для каждого запроса.

Однако рассмотрим следующие вопросы:

• Как пользователи будут знать, какое доменное имя использовать для доступа к службе?
• У вас есть центральная точка входа, например целевая страница или страница входа, которую используют все клиенты? Если вы делаете, как пользователи будут выбирать клиент, с которым они работают?
• Какие другие сведения используются для проверки доступа к ресурсам клиента, таким как маркеры авторизации? Включают ли маркеры авторизации доменные имена для конкретного клиента?

Свойства HTTP-запроса

Если вы не используете доменные имена для конкретного клиента, возможно, вы по-прежнему сможете использовать аспекты HTTP-запроса для идентификации клиента, для которому предназначен конкретный запрос. Например, рассмотрим HTTP-запрос, определяющий имя клиента как tailwindtraders. Это может быть передано с помощью одного из следующих подходов:

• Структура пути URL-адреса, например https://app.contoso.com/tailwindtraders/.
• Строка запроса в URL-адресе, например https://contoso.com/app?tenant=tailwindtraders.
• Пользовательский заголовок HTTP-запроса, например Tenant-Id: tailwindtraders.

При использовании этого подхода следует учитывать следующие вопросы:

• Будут ли пользователи знать, как получить доступ к службе? Например, если вы используете строку запроса для идентификации клиентов, потребуется ли центральная целевая страница направить пользователей на правильную страницу клиента, добавив строку запроса?
• У вас есть центральная точка входа, например целевая страница или страница входа, которую используют все клиенты? Если вы делаете, как пользователи будут выбирать клиент, к которому они должны получить доступ?
• Предоставляет ли ваше приложение API? Например, веб-приложение является одностраничным приложением (SPA) или мобильным приложением с серверной частью API? Если это так, вы можете использовать шлюз API или обратный прокси-сервер для сопоставления клиентов.

Утверждения токена

Многие приложения используют протоколы проверки подлинности и авторизации на основе утверждений, такие как OAuth 2.0 или SAML. Эти протоколы предоставляют маркеры авторизации клиенту. Маркер содержит набор утверждений, которые представляют собой фрагменты сведений о клиентском приложении или пользователе. Утверждения можно использовать для обмена данными, такими как адрес электронной почты пользователя. Затем система может включить адрес электронной почты пользователя, просмотреть сопоставление пользователей с клиентом, а затем перенаправить запрос в соответствующее развертывание. Кроме того, вы даже можете включить сопоставление клиента в систему удостоверений и добавить утверждение идентификатора клиента в маркер.

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

• Будет ли вы использовать утверждение для идентификации клиента? Какое утверждение будет использоваться?
• Может ли пользователь быть членом нескольких клиентов? Если это возможно, то как пользователи будут выбирать клиент, с которыми они хотели бы работать для конкретного запроса?
• Существует ли центральная система проверки подлинности и авторизации для всех клиентов? Если нет, как убедиться, что все центры маркеров выдают согласованные маркеры и утверждения?

Ключи API

Многие приложения предоставляют API. Они могут быть для внутреннего использования в организации или внешнего использования партнерами или клиентами. Распространенный метод проверки подлинности для API — использовать ключ API. Ключи API предоставляются с каждым запросом. Если вы записываете идентификатор клиента, для которому был выдан ключ, можно найти идентификатор клиента при использовании ключа.

Ключи API можно создать несколькими способами. Ниже приведены два распространенных подхода.

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

Рассмотрим следующие вопросы:

• Как создавать и выдавать ключи API?
• Как клиенты API безопасно получают и хранят ключ API?
• Требуется ли срок действия ключей API после периода времени? Как вы поворачиваете ключи API клиентов, не вызывая простоя?
• Обеспечивают ли ключи API, созданные клиентом, достаточный уровень безопасности для API?

Сертификаты клиентов

Проверка подлинности сертификата клиента, иногда называемая взаимной tls (mTLS), обычно используется для обмена данными между службами, а также для автоматических устройств или киосков, используемых пользователями без проверки подлинности. Сертификаты клиента обеспечивают безопасный способ проверки подлинности клиентов. Аналогично маркерам и утверждениям, клиентские сертификаты предоставляют атрибуты, которые можно использовать для определения арендатора. Например, тема сертификата может содержать адрес электронной почты пользователя, который можно использовать для поиска клиента.

При планировании использования сертификатов клиентов для сопоставления клиентов следует учитывать следующие факторы:

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

Обратные прокси-серверы

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

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

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

• Azure Front Door — это глобальный балансировщик нагрузки и брандмауэр веб-приложения. Она использует глобальную сеть Microsoft edge для создания быстрых, безопасных и высокомасштабируемых веб-приложений. С помощью наборов правил можно извлечь идентификаторы клиента и поместить их в другую часть запроса.
• Шлюз приложений Azure — это подсистема балансировки нагрузки управляемого веб-трафика, которая развертывается в том же физическом регионе, что и серверная служба.
• Управление API Azure оптимизировано для трафика API. Управление API Azure предоставляет комплексный механизм политики , который обеспечивает большую гибкость для извлечения сведений о клиенте из запросов.
• Коммерческие и открытые технологии (которые вы размещаете самостоятельно) включают nginx, Traefik и HAProxy.

Проверка запроса

Важно убедиться, что ваше приложение проверяет, разрешены ли полученные запросы для клиента. Например, если приложение использует имя личного домена для сопоставления запросов с клиентом, приложение должно по-прежнему проверять, что каждый запрос, полученный приложением, авторизован для этого клиента. Несмотря на то что запрос содержит доменное имя или другой идентификатор клиента, он не означает, что вы автоматически предоставляете доступ. При использовании OAuth 2.0 проверка выполняется путем проверки утверждений аудитории и области .

При реализации проверки запроса учитывайте следующие факторы:

• Как авторизовать все запросы к приложению? Необходимо авторизовать запросы независимо от подхода, используемого для сопоставления запросов с физической инфраструктурой.
• Используйте доверенные, широко используемые и хорошо поддерживаемые платформы проверки подлинности и авторизации, а не по промежуточному слоям, а не реализуйте всю логику проверки самостоятельно. Например, не создавайте логику проверки подписи маркера или библиотеки шифрования сертификатов клиента. Вместо этого используйте функции платформы приложений (или известные доверенные пакеты), которые были проверены и протестированы.

Performance

Логика сопоставления клиентов, скорее всего, выполняется при каждом запросе к приложению. Рассмотрим, насколько хорошо будет масштабироваться процесс сопоставления клиентов по мере роста решения. Например, если вы запрашиваете таблицу базы данных в рамках сопоставления клиента, база данных будет поддерживать большую нагрузку? Если для сопоставления клиента требуется расшифровка маркера, требования к вычислениям будут слишком высокими с течением времени? Если ваш трафик довольно скромный, то это не может повлиять на общую производительность. Однако, если у вас есть высокомасштабное приложение, затраты, связанные с этим сопоставлением, могут стать значительными.

Файлы cookie сеанса

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

Рассмотрим следующие вопросы:

• Можно ли использовать файлы cookie сеанса для уменьшения затрат на сопоставление запросов к клиентам?
• Какие службы используются для маршрутизации запросов к физическим развертываниям для каждого клиента? Поддерживают ли эти службы сеансы на основе файлов cookie?

Миграция клиента

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

• Если в приложении используются доменные имена для запросов сопоставления, может потребоваться также изменение DNS во время миграции. Изменение DNS может занять время для распространения на клиенты в зависимости от времени жизни (TTL) записей DNS в службе DNS.
• Если миграция изменяет адреса любых конечных точек во время миграции, попробуйте временно перенаправить запросы клиента на страницу обслуживания, которая автоматически обновляется.

Contributors

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основной автор:

• Даниэль Скотт-Райнсфорд | Стратег технологий партнеров

Другие участники:

• Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure
• Паоло Сальватори | Главный инженер клиента, FastTrack для Azure
• Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Дальнейшие шаги

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