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

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

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

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

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

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

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

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

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

Свойства 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 — это подсистема балансировки нагрузки управляемого веб-трафика, которая развертывается в том же физическом регионе, что и серверная служба.
• Azure Управление API оптимизирован для трафика API.
• Коммерческие и открытые технологии (которые вы размещаете самостоятельно) включают nginx, Traefik и HAProxy.

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

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

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

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

Производительность

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

Сходство сеансов

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

Оцените следующие вопросы.

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

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

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

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

Соавторы

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

Автор субъекта:

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

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

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

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

Следующие шаги

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