Как включить доступ к токенам OAuth 2.0 по идентификатору пользователя и приложения

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

Идентификаторы приложений автоматически добавляются в токен доступа 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",
  "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",
  "refresh_count" : "0"
}

Обратите внимание:

  • Поле application_name содержит UUID приложения, связанного с токеном. Если вы включили получение и отзыв токенов доступа OAuth 2.0 по идентификатору приложения, используйте этот идентификатор.
  • Поле access_token содержит значение токена доступа OAuth 2.0.

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

Идентификатор конечного пользователя – это строка, которую Edge использует в качестве идентификатора разработчика, а не адрес электронной почты разработчика. Идентификатор разработчика можно определить по его адресу электронной почты, используя вызов Get Developer API.

После того как вы настроите 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",
  "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",
  "refresh_count" : "0"
}

API для получения и отзыва токенов доступа OAuth 2.0 по идентификатору пользователя и приложения

Чтобы получить доступ к токенам OAuth по идентификатору пользователя, идентификатору приложения или обоим этим идентификаторам, используйте следующие API:

Как включить доступ к токену

Чтобы разрешить получение и отзыв токенов доступа OAuth 2.0 по идентификатору конечного пользователя и идентификатору приложения, выполните следующие действия:

Шаг 1. Включите поддержку доступа к токену для организации

Для каждой организации необходимо включить доступ к токену отдельно. Вызовите указанный ниже API PUT для каждой организации, в которой вы хотите разрешить получение и отзыв токенов доступа OAuth 2.0 по идентификатору конечного пользователя или идентификатору приложения.

Пользователь, выполняющий указанный ниже вызов, должен иметь роль orgadmin или opsadmin для организации. Замените values на значения, относящиеся к вашей организации:

curl -H "Content-type:text/xml" -X POST \
  https://management_server_IP;:8080/v1/organizations/org_name \
  -d '<Organization name="org_name">
      <Properties>
        <Property name="features.isOAuthRevokeEnabled">true</Property>
        <Property name="features.isOAuth2TokenSearchEnabled">true</Property>
      </Properties>
    </Organization>' \
  -u USER_EMAIL:PASSWORD

Шаг 2. Настройте разрешения для роли opsadmin в организации

Только роли orgadmin и opsadmin в организации должны иметь разрешения на получение (HTTP GET) и отзыв (HTTP PUT) токенов OAuth 2.0 на основе идентификатора пользователя или приложения. Чтобы контролировать доступ, задайте разрешения на получение и размещение для ресурса /oauth2 для организации. У этого ресурса есть URL в следующем формате:

https://management_server_IP:8080/v1/organizations/org_name/oauth2

У роли orgadmin уже должны быть необходимые разрешения. Для роли opsadmin для ресурса /oauth2 разрешения должны выглядеть следующим образом:

<ResourcePermission path="/oauth2">
  <Permissions>
    <Permission>get</Permission>
    <Permission>put</Permission>
  </Permissions>
</ResourcePermission>

Чтобы узнать, какие роли имеют разрешения для ресурса /oauth2, можно использовать вызов Get Permission for a Single Resource API.

На основе полученного ответа вы можете использовать вызовы API Add Permissions for Resource to a Role (Добавить разрешения для ресурса в роль) и Delete Permission for Resource (Удалить разрешение для ресурса), чтобы внести необходимые изменения в разрешения для ресурса /oauth2.

Используйте следующую команду curl, чтобы предоставить роли opsadmin разрешения get и put для ресурса /oauth2. Замените values на значения, относящиеся к вашей организации:

curl -X POST -H 'Content-type:application/xml' \
  http://management_server_IP:8080/v1/organizations/org_name/userroles/opsadmin/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions>
        <Permission>get</Permission>
        <Permission>put</Permission>
      </Permissions>
    </ResourcePermission>' \
  -u USEREMAIL:PASSWORD

Используйте следующую команду curl, чтобы отозвать разрешения get и put для ресурса /oauth2 у ролей, отличных от orgadmin и opsadmin. Замените values на значения, относящиеся к вашей организации:

curl -X DELETE -H 'Content-type:application/xml' \
  http://management_server_IP:8080/v1/organizations/org_name/userroles/roles/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions></Permissions>
    </ResourcePermission>' \
   -u USEREMAIL:PASSWORD

Шаг 3. Задайте свойство oauth_max_search_limit

Убедитесь, что свойство conf_keymanagement_oauth_max_search_limit в файле /opt/apigee/customer/application/management-server.properties имеет значение 100:

conf_keymanagement_oauth_max_search_limit = 100

Если такого файла нет, создайте его.

Это свойство задает размер страницы, используемый при получении токенов. Apigee рекомендует значение 100, но вы можете задать любое другое.

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

/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Шаг 4. Настройте правило OAuth 2.0, которое генерирует токены, чтобы включить идентификатор конечного пользователя

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

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

Приведенные ниже правила 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=k3nJyFJIA3p62TKIkLO6OJNXFmP&client_secret=gk5K5lIp943AY4'

В этом примере appuserID передается в виде заголовка запроса. Существует несколько способов передавать информацию в запросе. Например, вы можете:

  • Используйте переменную параметра формы: request.formparam.appuserID.
  • Используйте переменную потока, содержащую идентификатор конечного пользователя.