2017-01-16 19 views
1

Мы используем Apigee в качестве нашего сервера авторизации (AS), и у нас есть несколько служб Spring Restful, развернутых в общедоступном облаке IBM Bluemix, который действует как наш сервер ресурсов (RS).Подтвердить токен доступа oAuth 2 в APIGEE без политики VerifyOAuthTokens

Каждая из служб имеет эквивалентную прокси-службу, настроенную в Apigee. Для прокси-служб мы настроили политику VerifyOAuthTokens, чтобы проверить токен, переданный пользователем, и вернуть ошибку, если принят недопустимый токен.

Проблема заключается в том, что наш RS находится в общедоступном облаке (никаких планов или необходимости переход к выделенному или частному облаку) конечные точки api открыты и могут быть вызваны любым, кто знает URL. Хотя ожидание состоит в том, что каждый должен вызывать apis через прокси APIGEE, но мы не можем заставить это, поскольку мы находимся в общедоступном облаке, и есть нет вариантов открытия портов из apigee или чего-то еще. Мы хотели бы использовать следующий подход для защиты конечных точек api.

  1. Принять заголовок авторизации для каждого вызова
  2. Возьмите маркер и вызова службы маркеров Validate в Apigee

Для 2, мы не смогли найти апи APIGEE, который может проверить доступ лексем похож сказать Googles

https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg 

или Github-х

GET /applications/:client_id/tokens/:access_token 
  • Действительно ли существует внешняя служба APIGEE для проверки токена?
  • Если нет, то каким будет лучший способ убедиться, что только действительные пользователи с действительными токенами могут получить доступ к apis?

Спасибо, Татха

ответ

0

ли вы посмотрите на этот пост в Apigee сообщества: Using third-party OAuth tokens

Мы сделали что-то похожее на это, но не с помощью OAuth маркеров. Мы использовали Apigee для выполнения выноски стороннему IDP (поставщику удостоверений личности). Сторонний IDP не смог генерировать токены, но выставил веб-службу для аутентификации пользователя. Если пользователь был аутентифицирован успешно (на основе интерпретации результата, полученного обратно из целевой веб-службы конечной точки), вы сообщите Apigee, что он был успешным, установив статус внешней авторизации в значение true (шаг №2 в ссылке).

ПРИМЕЧАНИЕ: это должно быть сделано внутри шага политики присваивания сообщения PRIOR для операции маркера GenerateAccess. Apigee интерпретирует это как успешную авторизацию, а затем может генерировать действительный токен oauth, который вызывающий может затем отправить для доступа к защищенному API.

+0

Thank @Chris Я рассмотрю это. Хотя я не думаю, что мы можем использовать его, так как у нас нет сторонних IDP, наш - это простой сервис, который поддерживает только тип предоставления полномочий client_credentials, и мы не авторизуем пользователя, а только приложение. Приложения настроены как организации – Tatha