Создание подписок в службе управления API Azure
При публикации API с Управление API вы определяете, кто может получить доступ к API через шлюз.
Для метеорологического приложения убедитесь, что только клиенты, которые подписаны на вашу службу, могут получить доступ к API и использовать данные прогноза, Этот контроль доступа осуществляется путем выдачи ключей подписки.
Внимание
Подписки в этом контексте не связаны с подписками Azure, используемыми для управления учетной записью Azure.
Далее вы узнаете, как защитить свои API с использованием ключей подписки.
Подписки и ключи
Вы можете сделать API-интерфейсы и сведения, которые они содержат свободно. Но обычно вы хотите ограничить доступ к пользователям, которые заплатили или организации, с которыми у вас есть рабочие отношения. Одним из способов управления доступом к API является использование подписок. Подписки используются для сегментирования доступа пользователей к API.
Ключи подписки обеспечивают авторизацию, чтобы включить доступ для этих подписок. Каждый раз, когда клиент отправляет запрос через защищенный API, он должен включать действительный ключ подписки в HTTP-запрос, или вызов будет отклонен.
Ключ подписки — это уникальный автоматически созданный ключ, который можно передать в рамках вызова API. Ключ напрямую связан с подпиской, которая может применяться к различным областям. Подписки предоставляют детальный контроль над разрешениями и политиками.
К трем основным областям подписок относятся следующие:
Область | Сведения |
---|---|
Все API | Применяется к каждому API, доступному из шлюза. |
Один API | Применяется к одному импортированному API и всем его конечным точкам. |
Продукт | Продукт является коллекцией из одного или нескольких API, настроенных в службе управления API. Один и тот же API может быть назначен нескольким продуктам. Вы можете определять для продуктов различные правила доступа, квоты и условия использования. Таким образом, если вы планируете предоставить партнерам и поставщикам разные права доступа к API WeatherData, следует назначить этот API продукту, а затем связать API с продуктом на портале Azure. |
Все вызовы приложения к защищенному API должны содержать ключ подписки.
Вы можете в любое время заново создать ключ подписки. Например, это может потребоваться в том случае, если вы подозреваете, что ключ мог попасть к не имеющим соответствующих полномочий пользователям.
Каждая подписка содержит два ключа — первичный и вторичный. Такой подход позволяет упростить повторное создание ключа. Например, если вы хотите изменить первичный ключ, не допуская при этом простоя, используйте в приложениях вторичный ключ.
При выполнении вызовов к API в продуктах с активированной подпиской клиентам необходимо предоставлять ключ. Разработчики могут получить ключ, отправив запрос на подписку. При утверждении запроса необходимо отправить им ключ подписки безопасным образом, например в зашифрованном сообщении. Этот шаг является основной частью рабочего процесса службы управления API.
Вызов API с использованием ключа подписки
При выполнении вызовов к конечным точкам API, которые защищены с использованием подписки, приложения должны включать в HTTP-запросы действительный ключ. Ключи могут передаваться как в заголовке запроса, так и в виде параметра строки запроса в URL-адресе.
По умолчанию используется имя заголовка ключа подписки Ocp-Apim-Subscription-Key или имя строки запроса subscription-key.
Чтобы протестировать вызовы API, можно использовать тестовую консоль на портал Azure или на портале разработчика или средства командной строки, например curl. Ниже приведен пример запроса GET
, который содержит заголовок с ключом подписки и выполняется с помощью портала разработчика.
Ниже приведен пример передачи ключа в заголовке запроса с помощью curl:
curl --header "Ocp-Apim-Subscription-Key: <key string>" https://<apim gateway>.azure-api.net/api/path
Ниже приведен пример использования команды curl для передачи ключа в виде строки запроса в URL-адресе:
curl https://<apim gateway>.azure-api.net/api/path?subscription-key=<key string>
Если необходимый ключ не передается в заголовке или в качестве строки запроса в URL-адресе, вы получите ответ 401 Access Denied из шлюза API.