Конфигурация удостоверений Azure Active Directory для Azure API для FHIR

  • Статья

При работе с медицинскими данными важно обеспечить безопасность данных и доступ к ним неавторизованных пользователей или приложений. Серверы FHIR используют OAuth 2.0 для обеспечения безопасности данных. Azure API для FHIR защищен с помощью Azure Active Directory, который является примером поставщика удостоверений OAuth 2.0. В этой статье представлен обзор авторизации сервера FHIR и действия, необходимые для получения маркера для доступа к серверу FHIR. Хотя эти действия применимы к любому серверу FHIR и любому поставщику удостоверений, в этой статье мы рассмотрим Azure API для FHIR в качестве сервера FHIR и Azure Active Directory (Azure AD) в качестве поставщика удостоверений.

Общие сведения о контроле доступа

Чтобы клиентское приложение получите доступ к Api Azure для FHIR, оно должно предоставить маркер доступа. Маркер доступа — это подписанная в кодировке Base64 коллекция свойств (утверждений), которые передают сведения об удостоверении клиента, ролях и привилегиях, предоставленных клиенту.

Существует множество способов получения маркера, но API Azure для FHIR не заботится о том, как он будет получен, если он является надлежащим образом подписанным маркером с правильными утверждениями.

Например, при использовании потока кода авторизации доступ к серверу FHIR выполняет следующие четыре этапа:

Авторизация FHIR

  1. Клиент отправляет запрос к конечной точке /authorize Azure AD. Azure AD перенаправит клиент на страницу входа, где пользователь будет проходить проверку подлинности, используя соответствующие учетные данные (например, имя пользователя и пароль или двухфакторную проверку подлинности). См. сведения о получении кода авторизации. После успешной проверки подлинности клиенту возвращается код авторизации . Azure AD позволит возвращать этот код авторизации только на зарегистрированный URL-адрес ответа, настроенный при регистрации клиентского приложения.
  2. Клиентское приложение обменивается кодом авторизации на маркер доступа в конечной точке /token Azure AD. При запросе маркера клиентскому приложению может потребоваться предоставить секрет клиента (пароль приложения). См. сведения о получении маркера доступа.
  3. Клиент отправляет запрос к Api Azure для FHIR, например GET /Patient, для поиска всех пациентов. Когда клиент выполняет запрос, он включает маркер доступа в заголовок HTTP-запроса, например Authorization: Bearer eyJ0e..., где eyJ0e... представляет маркер доступа в кодировке Base64.
  4. Api Azure для FHIR проверяет, содержит ли маркер соответствующие утверждения (свойства в маркере). Если все будет извлечено, он завершит запрос и вернет клиенту пакет FHIR с результатами.

Важно отметить, что API Azure для FHIR не участвует в проверке учетных данных пользователя и не выдает маркер. Проверка подлинности и создание маркера выполняются Azure AD. Api Azure для FHIR просто проверяет правильность подписи маркера (он является подлинным) и наличие соответствующих утверждений.

Структура маркера доступа

Разработка приложений ресурсов быстрого взаимодействия в сфере здравоохранения (FHIR®) часто включает отладку проблем с доступом. Если клиенту отказано в доступе к Azure API для FHIR, полезно понять структуру маркера доступа и способ его декодирования для проверки содержимого (утверждений) маркера.

Серверы FHIR обычно ожидают json Web Token (JWT, иногда произносится как "jot"). Он состоит из трех частей:

Часть 1. Заголовок, который может выглядеть следующим образом:

    {
      "alg": "HS256",
      "typ": "JWT"
    }

Часть 2. Полезные данные (утверждения), например:

    {
     "oid": "123",
     "iss": "https://issuerurl",
     "iat": 1422779638,
     "roles": [
        "admin"
      ]
    }

Часть 3. Сигнатура, которая вычисляется путем объединения содержимого заголовка и полезных данных в кодировке Base64 и вычисления криптографического хэша из них на основе алгоритма (alg), указанного в заголовке. Сервер сможет получить открытые ключи от поставщика удостоверений и убедиться, что этот маркер был выдан определенным поставщиком удостоверений и что он не был подделан.

Полный токен состоит из версий этих трех сегментов в кодировке Base64 (фактически в кодировке Base64 URL). Три сегмента объединяются и разделяются . точкой.

Пример маркера показан следующим образом:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvaWQiOiIxMjMiLCAiaXNzIjoiaHR0cHM6Ly9pc3N1ZXJ1cmwiLCJpYXQiOjE0MjI3Nzk2MzgsInJvbGVzIjpbImFkbWluIl19.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

Маркер можно декодировать и проверять с помощью таких средств, как https://jwt.ms. Результат декодирования маркера:

{
  "alg": "HS256",
  "typ": "JWT"
}.{
  "oid": "123",
  "iss": "https://issuerurl",
  "iat": 1422779638,
  "roles": [
    "admin"
  ]
}.[Signature]

Получение маркера доступа

Как уже упоминалось, существует несколько способов получения маркера из Azure AD. Они подробно описаны в документации разработчика Azure AD.

Используйте один из следующих протоколов проверки подлинности:

Существуют и другие варианты (например, из-за потока) для получения маркера. Дополнительные сведения см. в документации по Azure AD. При использовании Azure API для FHIR существуют некоторые сочетания клавиш для получения маркера доступа (например, для отладки) с помощью Azure CLI.

Дальнейшие действия

В этом документе вы узнали о некоторых основных понятиях, связанных с защитой доступа к API Azure для FHIR с помощью Azure AD. Сведения о развертывании службы Azure API для FHIR см. в этой статье.

Развертывание Azure API для FHIR

FHIR® является зарегистрированным товарным знаком HL7 и используется с разрешения HL7.