Проверка подлинности и авторизация в приложении

Безопасность важна для современных веб-приложений. Fluid Framework в рамках архитектуры веб-приложения является важной частью инфраструктуры для обеспечения безопасности. Fluid Framework — это многоуровневая архитектура, и концепции, связанные с проверкой подлинности, реализуются на основе службы "Жидкость", к ней подключается. Это означает, что, хотя существуют распространенные темы проверки подлинности во всех службах Жидкости, сведения и особенности будут отличаться для каждой службы.

Служба Ретранслятора Жидкости Azure

Каждый создаваемый клиент службы Azure Fluid Relay назначает идентификатор клиента и собственный уникальный секретный ключ клиента.

Секретный ключ — это общий секрет. Ваше приложение или служба знает его, и служба Ретранслятора Azure знает его. Так как секретный ключ клиента однозначно привязан к клиенту, используя его для подписывания запросов в службу Ретранслятора Azure Fluid Relay, что запросы отправляются от авторизованного пользователя клиента.

Секретный ключ заключается в том, как служба Azure Fluid Relay знает, что запросы, поступающие из вашего приложения или службы. Это важно, так как после того, как служба Ретранслятора Жидкости Azure может доверять тому, что приложение выполняет запросы, оно может доверять отправляемым данным. Это также значит, что секрет обрабатывается безопасно.

Веб-токены JSON и служба Azure Fluid Relay

Azure Fluid Relay использует веб-маркеры JSON (JWTs) для кодирования и проверки данных, подписанных секретным ключом. Веб-маркеры JSON — это подписанный бит JSON, который может содержать дополнительные сведения о правах и разрешениях.

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

• ContainerId Службе "Жидкость" требуется идентификатор контейнера, чтобы определить, какая служба соответствует вызывающему контейнеру. Примечание. JWT вызывает этот идентификатор поля documentId, но служба "Жидкость" ожидает идентификатор контейнера в этом поле.
• tenantId: служба Ретранслятора Azure использует идентификатор клиента для получения общего секрета, который будет использоваться для проверки подлинности запроса.
• область: области определяют разрешения вызывающего контейнера. Содержимое поля область является гибким, что позволяет создавать собственные пользовательские разрешения.

{
  "alg": "HS256",
  "typ": "JWT"
}.{
  "documentId": "azureFluidDocumentId",
  "scopes": [ "doc:read", "doc:write", "summary:write" ],
  "user": {
    "name": "TestUser",
    "id": "Test-Id-123"
  },
  "iat": 1599098963,
  "exp": 1599098963,
  "tenantId": "AzureFluidTenantId",
  "ver": "1.0"
}.[Signature]

Режим пользователя указывает, находится ли подключение в режиме чтения или чтения или записи. Это можно просмотреть из connections поля в AzureAudience. Маркер область разрешения можно обновить в бессерверной функции Azure под функциейgenerateToken.

const token = generateToken(
  tenantId,
  documentId,
  key,
  scopes ?? [ "Token Scope" ],
  user
);

Маркер область вместе с поведением контейнера и режимами ниже.

Поставщик токенов

Каждый запрос к Ретранслятору Жидкости Azure должен быть подписан с помощью допустимого JWT. Жидкость делегирует ответственность за создание и подписание этих маркеров поставщикам маркеров.

Поставщик токенов отвечает за создание и подписывание маркеров, которые @fluidframework/azure-client используются для выполнения запросов к службе Azure Fluid Relay. Необходимо предоставить собственную реализацию поставщика маркеров безопасности. Тем не менее, Fluid предоставляет, InsecureTokenProvider который принимает секрет клиента, а затем локально создает и возвращает подписанный маркер. Этот поставщик токенов полезен для тестирования, но не может использоваться в рабочих сценариях.

Безопасный поставщик маркеров без сервера

Один из вариантов создания поставщика безопасных маркеров — создать бессерверную функцию Azure и предоставить ее в качестве поставщика маркеров. Это позволяет хранить секретный ключ клиента на защищенном сервере. Затем приложение вызовет функцию Azure, чтобы создать маркеры, а не подписывать их локально, как это InsecureTokenProvider делает. Дополнительные сведения см. в статье "Практическое руководство. Запись tokenProvider с помощью функции Azure".

Подключение аутентификация пользователя в службе "Жидкость"

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

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

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

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

См. также

• Общие сведения о JWTs
• Создание веб-маркера JSON
• Утверждения полезных данных в Ретрансляторе Жидкости Azure