Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info
В этом разделе описывается, как включить получение и аннулирование токенов доступа OAuth 2.0 по идентификатору конечного пользователя, идентификатору приложения или обоим параметрам. Функция идентификации конечного пользователя требует специальной настройки, описанной в этом разделе. Под конечным пользователем мы подразумеваем пользователя приложения, которое вызывает API.
Когда следует разрешать доступ по идентификатору конечного пользователя?
Иногда бывает полезно хранить идентификатор пользователя в токене доступа. Включайте функцию доступа по идентификатору конечного пользователя только в том случае, если для этого есть веские основания. Например:
- Функция для вашего веб-сайта или приложения, позволяющая пользователям видеть, каким сторонним приложениям они разрешили доступ, и предоставляющая возможность отозвать доступ к этим приложениям.
- Функция, позволяющая авторизованному пользователю отозвать все токены доступа, связанные с конкретным приложением разработчика.
О токенах доступа OAuth
Идентификаторы приложений автоматически добавляются к токену доступа OAuth. Поэтому после включения доступа к токенам для организации, как описано ниже, вы можете отозвать токены доступа по идентификатору приложения.
Для получения и отзыва токенов доступа OAuth 2.0 по идентификатору конечного пользователя, идентификатор конечного пользователя должен присутствовать в токенах доступа. Ниже описана процедура добавления идентификатора конечного пользователя к существующему токену.
По умолчанию, когда Edge генерирует токен доступа OAuth 2.0, этот токен имеет формат, показанный ниже:
{ "issued_at" : "1421847736581", "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a", "scope" : "READ", "status" : "approved", "api_product_list" : "[PremiumWeatherAPI]", "expires_in" : "3599", //--in seconds "developer.email" : "tesla@weathersample.com", "organization_id" : "0", "token_type" : "BearerToken", "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP", "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL", "organization_name" : "myorg", "refresh_token_expires_in" : "0", //--in seconds "refresh_count" : "0" }
Обратите внимание на следующее:
- Поле application_name содержит UUID приложения, связанного с токеном. Если вы включили получение и аннулирование токенов доступа OAuth 2.0 по идентификатору приложения, то следует использовать именно этот идентификатор приложения.
- Поле access_token содержит значение токена доступа OAuth 2.0.
В стандартном токене доступа OAuth отсутствует поле для идентификатора конечного пользователя. Чтобы разрешить получение и аннулирование токенов доступа OAuth 2.0 по идентификатору конечного пользователя, необходимо настроить политику OAuth 2.0 таким образом, чтобы идентификатор пользователя был включен в токен, как описано в приведенной ниже процедуре. Обратите внимание, что если вы хотите получать и аннулировать токены доступа OAuth 2.0 только по идентификатору приложения, то нет необходимости разрешать доступ по идентификатору конечного пользователя.
В конечную точку создания токена передается идентификатор конечного пользователя. Идентификатор конечного пользователя можно передать в качестве параметра запроса, параметра формы или в заголовке (как будет объяснено далее в этой теме). После настройки Edge для включения идентификатора конечного пользователя в токен, он будет включен в поле app_enduser , как показано ниже:
{ "issued_at" : "1421847736581", "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a", "scope" : "READ", "app_enduser" : "6ZG094fgnjNf02EK", "status" : "approved", "api_product_list" : "[PremiumWeatherAPI]", "expires_in" : "3599", //--in seconds "developer.email" : "tesla@weathersample.com", "organization_id" : "0", "token_type" : "BearerToken", "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP", "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL", "organization_name" : "myorg", "refresh_token_expires_in" : "0", //--in seconds "refresh_count" : "0" }
Чтобы узнать, как выполнять вызовы API для получения и аннулирования этих данных, см. следующие документы Smart Docs:
- Отзыв токена доступа OAuth2 по идентификатору конечного пользователя или приложения.
- Получение токена доступа OAuth2 по идентификатору конечного пользователя или приложения.
Предоставление доступа к токенам OAuth 2.0 по идентификатору пользователя и идентификатору приложения.
Способ предоставления доступа к токенам OAuth 2.0 по идентификатору пользователя и идентификатору приложения зависит от способа развертывания Edge:
Развертывание на основе облачных технологий
Облачное развертывание Edge означает, что большая часть конфигурации выполняется Apigee. Вам нужно лишь настроить политику OAuth 2.0 для добавления идентификатора пользователя к токену доступа. Подробнее см. процедуру ниже.
Edge для развертывания частного облака
В Apigee Edge для частного облака (локальная установка) вы полностью отвечаете за конфигурацию. Подробнее см. раздел «Эксплуатация и конфигурация» .
Гибрид Апигии
Доступ к токенам OAuth 2.0 по идентификатору пользователя включен по умолчанию. Вам нужно лишь настроить политику OAuth 2.0 для добавления идентификатора пользователя к токену доступа. Подробнее см. шаг 5 описанной ниже процедуры.
Обеспечение доступа в облаке
Шаг 1: Обеспечьте поддержку этой функции в организации.
Эту функцию необходимо включить для каждой организации, для которой вы хотите ее поддерживать.
Обратитесь в службу поддержки Apigee Edge , чтобы они обновили вашу организацию.
Шаг 2: Предоставьте права доступа к ресурсам oauth2 ролям opsadmin и orgadmin.
Только ваши роли orgadmin и opsadmin должны иметь разрешения на выполнение этих запросов retrieve ( get ) и revoke ( put ) к ресурсу oauth2 на основе идентификатора конечного пользователя или идентификатора приложения.
Вы можете использовать вызов API «Получить разрешения для ресурса», чтобы узнать, какие роли имеют разрешения get и put данных для ресурса oauth2 .
Если вам необходимо добавить или удалить какие-либо разрешения, обратитесь в службу поддержки Apigee Edge , чтобы они выполнили обновления.
Шаг 3: Скопируйте существующие токены доступа OAuth 2.0 на узлы Cassandra.
Выполняется службой поддержки Apigee : В рамках этой задачи копии существующих токенов доступа OAuth 2.0 в затронутых организациях будут скопированы и сохранены на ваших узлах Cassandra. Эта процедура будет выполнена на узлах Cassandra для каждого из ваших модулей Apigee Edge. Это позволит выполнять вызовы API для получения и отзыва всех ваших токенов доступа OAuth 2.0, как существующих, так и вновь сгенерированных.
Шаг 4: Настройте политику OAuth 2.0 для генерации токенов доступа, содержащих идентификаторы конечных пользователей.
Настройте политику OAuth 2.0, используемую для генерации токенов доступа, таким образом, чтобы она включала идентификатор конечного пользователя в токен. Включение идентификаторов конечных пользователей в токены доступа позволит вам выполнять получение и отзыв токенов доступа по идентификатору конечного пользователя.
Чтобы настроить политику таким образом, чтобы идентификатор конечного пользователя включался в токен доступа, необходимо указать входную переменную, содержащую этот идентификатор. Используйте тег <AppEndUser> для указания переменной.
Приведённая ниже политика OAuth 2.0, названная GenerateAccessTokenClient , генерирует токен доступа OAuth 2.0. Обратите внимание на добавление выделенного жирным шрифтом тега <AppEndUser> :
<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessTokenClient"> <DisplayName>OAuth 2.0.0 1</DisplayName> <ExternalAuthorization>false</ExternalAuthorization> <Operation>GenerateAccessToken</Operation> <SupportedGrantTypes> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <GenerateResponse enabled="true"/> <GrantType>request.queryparam.grant_type</GrantType> <AppEndUser>request.header.appuserID</AppEndUser> <ExpiresIn>960000</ExpiresIn> </OAuthV2>
Затем вы можете использовать следующую команду cURL для генерации токена доступа OAuth 2.0, передав идентификатор пользователя в заголовке appuserID :
curl -H "appuserID:6ZG094fgnjNf02EK" / https://myorg-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials / -X POST / -d 'client_id=k3nJyFJIA3p62TKIkLO6OJNi87GYXFmP&client_secret=gk58jK5lIp943AY4'
В этом примере идентификатор пользователя (appuserID) передается в заголовке запроса. Передавать информацию в рамках запроса можно разными способами. Например, в качестве альтернативы можно:
- Используйте переменную параметра формы: request.formparam.appuserID
- Используйте переменную потока, указывающую идентификатор конечного пользователя.