Как заставить моих конечных пользователей (под сервером идентификации wso2) подписаться на api в диспетчере wso2 api?
В настоящее время я занимаюсь PoC для диспетчера API WSO2 (v2.6.0). У меня уже есть веб-приложение (например, заказ пиццы), а также зарегистрированные клиенты (конечные пользователи), которые используют приложение для бронирования пиццы. Теперь я хотел использовать серверные службы приложения для бронирования пиццы, такие как
- Выберите местонахождение магазина,
- Заказать пиццу,
- Отследить заказ и т. Д.
в качестве API в диспетчере API WSO2. Для этого я бы создал необходимый API в диспетчере API. Затем я хотел перенести существующих пользователей веб-приложений (конечных пользователей) в диспетчер API и предоставить доступ к этим API.
Как лучше всего это реализовать?
- Перенести моих пользователей на сервер идентификации WSO2 и использовать сервер идентификации в качестве менеджера ключей для моего менеджера API?
- Перенести моих пользователей в хранилище дополнительных пользователей / использовать пользовательское хранилище пользователей API-менеджера?
В таком случае, как мне предоставить доступ к определенным API (подписка на API) без входа в хранилище диспетчера API и подписки вручную для каждого пользователя?
Также,
Какая польза от создания поставщика услуг и создания приложения Oauth при входящей аутентификации?
Что я могу делать с этим приложением?
Это то же самое, что и приложение, которое мы создаем перед подпиской на API в хранилище диспетчера API?
Могу ли я добавлять пользователей в это приложение и предоставлять им общий доступ?
Могу ли я подписаться на API с помощью этого приложения, чтобы все пользователи этого приложения имели к нему доступ?
2 ответа
Вы можете сделать это в любом случае. Использование IS в качестве диспетчера ключей (если вы уже используете IS) или добавление в качестве хранилища дополнительных пользователей.
Итак, если вы уже используете WSO2 Identity Server в своем развертывании, настройка его в качестве диспетчера ключей (путем совместного использования хранилищ пользователей) автоматически позволит всем пользователям в IS (с соответствующими разрешениями) получить доступ к API.
Если вы в настоящее время не используете IS, лучшим вариантом будет добавить хранилище дополнительных пользователей в существующее развертывание APIM.
Пожалуйста, найдите ответы на остальные вопросы ниже.
- Какая польза от создания поставщика услуг и создания приложения Oauth при входящей аутентификации?
- Что я могу делать с этим приложением?
- Это то же самое, что и приложение, которое мы создаем перед подпиской на API в хранилище диспетчера API?
- Могу ли я добавлять пользователей в это приложение и предоставлять им общий доступ?
- Могу ли я подписаться на API с помощью этого приложения, чтобы все пользователи этого приложения имели к нему доступ?
Ответ
Поставщик услуг создается автоматически при создании приложения Oauth и генерации ключей. Но у этих двух сущностей есть разные аспекты.
Поставщик услуг обычно используется для генерации ключей приложения, чтобы получить токен доступа для вызова API.
Приложение OAuth (при создании через хранилище API) имеет несколько других применений, таких как подписка на API, применение политик регулирования для подписок и т. Д.
Чтобы использовать токен, сгенерированный приложением, соответствующий API должен быть подписан приложением. В противном случае вы не сможете вызвать этот API, хотя у вас есть действующий токен доступа.
Вы можете подписаться на API только из приложения OAuth, созданного через API Store.
Ваши пользователи могут использовать то же приложение OAuth (которое создается через портал магазина и подписано на API) для создания для них токена доступа. То есть, предоставив им ключи приложения и используя тип предоставления пароля, они могут сгенерировать для них токен.
Обратитесь к этой документации для получения дополнительной информации об API токенов и типах грантов. https://docs.wso2.com/display/AM260/Token+API
Добавляя к тому, что объяснил @Menaka.
Конечным пользователям не нужно подписываться на API. Только разработчик приложения должен подписаться и встроить ключ / секрет потребителя в свое приложение. Затем приложение должно сгенерировать токены для конечных пользователей, используя эту пару ключей + учетные данные конечного пользователя.