Эта страница переведена с помощью Cloud Translation API.

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

Edge для частного облака v. 4.16.09

В этом документе описывается, как включить получение и отзыв токенов доступа 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 использует в качестве идентификатора разработчика, а не адрес электронной почты разработчика. Вы можете определить идентификатор разработчика по адресу электронной почты разработчика, используя вызов API Get Developer.

После того, как вы настроите 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 по идентификатору пользователя и идентификатору приложения.

Используйте следующие API для доступа к токенам OAuth по идентификатору пользователя, идентификатору приложения или тому и другому:

Процедура включения доступа по токену

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

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

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

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

> curl -H "Content-type:text/xml" -X POST \
  https://<ms-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 {userEmail}:{mypassword}

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

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

https://<ms-ip>:8080/v1/organizations/{org_name}/oauth2

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

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

Вы можете использовать вызов API «Получить разрешение для одного ресурса», чтобы узнать, какие роли имеют разрешения для ресурса /oauth2 .

На основе ответа вы можете использовать вызовы API «Добавить разрешения для ресурса в роль» и «Удалить разрешение для ресурса», чтобы внести необходимые изменения в разрешения ресурса /oauth2.

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

> curl -X POST -H 'Content-type:application/xml' \
  http://<ms-ip>:8080/v1/organizations/{org}/userroles/opsadmin/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions>
        <Permission>get</Permission>
        <Permission>put</Permission>
      </Permissions>
    </ResourcePermission>' \
  -u {USEREMAIL}:{PWD}

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

> curl -X DELETE -H 'Content-type:application/xml' \
  http://<msip>:8080/v1/organizations/{org-name}/userroles/{roles}/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions></Permissions>
    </ResourcePermission>' \
   -u {USEREMAIL}:{PWD}

Шаг 3. Установите свойство oauth_max_search_limit.

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

conf_keymanagement_oauth_max_search_limit = 100

Если этот файл не существует, создайте его.

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

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

> /<inst_rt>/apigee/apigee-service/bin/apigee-service edge-management-server restart
> /<inst_rt>/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.
Используйте переменную потока, предоставляющую идентификатор конечного пользователя.