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

Реализация типа предоставления пароля

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Тип предоставления доступа «пароль владельца ресурса» (или «password») в основном используется в случаях, когда приложению доверяют очень высоко. В этой конфигурации пользователь предоставляет свои учетные данные сервера ресурсов (имя пользователя/пароль) клиентскому приложению, которое отправляет ему запрос на получение токена доступа в Apigee Edge. Сервер идентификации проверяет учетные данные, и если они действительны, Edge генерирует токен доступа и возвращает его приложению.

По этой теме

В этой теме дается общее описание и обзор процесса предоставления пароля владельцу ресурса по протоколу OAuth 2.0, а также рассматривается, как реализовать этот процесс на Apigee Edge.

Примеры, которые могут вам пригодиться

Запрос токена доступа: Тип предоставления пароля : показывает, как сформировать запрос токена, настроить политику OAuthV2 для типа предоставления пароля и как настроить конечную точку для этой политики в Edge.
oauth-validate-key-secret : Пример прокси-сервера на GitHub, который можно развернуть в Edge и протестировать. Это сквозной пример, демонстрирующий тип предоставления доступа по паролю. Он показывает рекомендуемую практику: аутентифицировать учетные данные клиентского приложения (ключ/секрет) перед отправкой учетных данных пользователя поставщику идентификации.

Видео

Видео: Посмотрите это видео о реализации типа предоставления доступа по паролю.

Варианты использования

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

Блок-схема

На следующей блок-схеме показан процесс предоставления пароля владельцу ресурса, в котором Apigee Edge выступает в качестве сервера авторизации.

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

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

Ниже приведено краткое описание шагов, необходимых для реализации типа предоставления доступа по паролю, где Apigee Edge выступает в качестве сервера авторизации.

Предварительное условие: клиентское приложение должно быть зарегистрировано в Apigee Edge для получения идентификатора клиента и секретных ключей клиента. Подробнее см. раздел «Регистрация клиентских приложений» .

1. Пользователь запускает процесс и вводит учетные данные.

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

2. Приложение запрашивает токен доступа у Apigee Edge.

Приложение отправляет запрос на получение токена доступа, включая учетные данные пользователя, на конечную точку GenerateAccessToken в Apigee Edge.

Вот пример POST-запроса, включающий необходимые параметры для данного типа гранта:

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

В качестве альтернативы, эту команду можно выполнить следующим образом, используя опцию -u в curl для создания заголовка Basic Authentication в кодировке base64.

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

(Все эти команды должны быть на одной строке.)

Учетные данные пользователя содержатся в параметрах формы, а учетные данные клиента закодированы в заголовке базовой аутентификации HTTP. Подробное описание этого вызова API, включая сведения о необходимом заголовке Basic Auth, см. в разделе предоставления пароля в документе « Запрос токенов доступа и кодов авторизации ».

3. Edge проверяет клиентское приложение.

Прежде чем отправлять имя пользователя и пароль поставщика идентификации, Edge необходимо убедиться, что клиентское приложение, отправляющее запрос, является действительным и доверенным. Один из способов сделать это — использовать аутентификацию по ключу API при вызове API. В некоторых случаях может потребоваться проверка как ключа клиента, так и секрета. Пример прокси-сервера, иллюстрирующий этот альтернативный метод, находится в репозитории api-platform-samples на GitHub .

4. Edge обрабатывает учетные данные для входа в систему.

После проверки клиентского приложения вы можете использовать вызов службы или политику JavaScript для обращения к службе идентификации и отправки учетных данных пользователя. Например, это может быть служба LDAP или любая другая служба, которую вы хотите использовать для проверки учетных данных. Подробную информацию об этих политиках см. в разделах «Политика извлечения переменных» и «Политика JavaScript» .

Если служба идентификации подтвердит учетные данные и вернет ответ с кодом 200, Edge продолжит обработку запроса; в противном случае Edge прекратит обработку и вернет ошибку клиентскому приложению.

5. Политика OAuthV2 выполняется.

Если учетные данные действительны, следующим этапом обработки является выполнение политики OAuthV2, настроенной для типа предоставления пароля. Вот пример. Элементы <UserName> и <PassWord> являются обязательными, и вы можете получить их из переменных потока, сохраненных с помощью политики ExtractVariables. Подробную справочную информацию об этой политике см. в разделе «Политика OAuthV2» .

<OAuthV2 name="GetAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>360000000</ExpiresIn> 
  <SupportedGrantTypes> 
     <GrantType>password</GrantType> 
  </SupportedGrantTypes> 
  <GrantType>request.queryparam.grant_type</GrantType> 
  <UserName>login</UserName>
  <PassWord>password</PassWord>
  <GenerateResponse/> 
</OAuthV2>

Если эта политика сработает, клиенту будет отправлен ответ, содержащий токен доступа. Ответ будет в формате JSON. Вот пример. Обратите внимание, что access_token является одним из элементов:

{
    "issued_at": "1420258685042",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420258685042",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799",
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
    "organization_name": "docs",
    "refresh_token_expires_in": "0",
    "refresh_count": "0"
}

6. Клиент вызывает защищенный API.

Теперь, имея действительный код доступа, клиент может совершать вызовы к защищенному API. В этом сценарии запросы отправляются в Apigee Edge (прокси), и Edge отвечает за проверку токена доступа перед передачей вызова API на целевой сервер ресурсов. Токены доступа передаются в заголовке Authorization. Например:

$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282