В этом посте я хочу поделиться своим опытом и знаниями с помощью WSO2 API Manager (API-M) для очень распространенного и полезного сценария в отрасли.
Вкратце следующее — это поток.
API предоставляется разработчикам приложений для использования под управлением API Manager (который добавляет контроль доступа для API). Затем разработчики приложений делают свои приложения потребляющими эти API. После завершения разработки и тестирования они становятся доступными для конечных пользователей в магазине приложений. Затем конечные пользователи могут зарегистрироваться в магазине и использовать приложения с собственными учетными данными. Приложение предоставит нужные сервисы, вызывающие API, на которые оно подписано.
Вышеописанный сценарий хорошо продемонстрирован в WSO2 API-M на примере пиццерии, описанном в документации [1].
Для ясности я буду включать шаги вкратце. Для подробных шагов мы можем обратиться к документации в [1].
Роль разработчика API
- Мы внедряем фоновые сервисы, связанные с «заказом пиццы», на сервере приложений WSO2 или любом другом сервере приложений. (Загрузите код из примеров API-M svn , соберите его с помощью Maven3 и разверните его в AS WSO2. Если мы проверим WADL, мы сможем проверить ресурсы, которые он предоставляет. Обратите внимание на URL-адрес конечной точки.)
- Затем мы публикуем эти сервисы как API-интерфейсы в WSO2 API-M Publisher, чтобы они были доступны в магазине API-M (вход в API-M Publisher, в пакете по умолчанию https: // localhost: 9443 / publisher и публикуем API-интерфейсы как руководствуясь примером документа. Мы должны убедиться, что URL конечной точки производства совпадает с тем, что мы наблюдали на первом этапе).
Роль разработчика приложений
- Теперь вот приходит разработчик приложения, который хочет разработать приложение для заказа пиццы. Он / она может зарегистрировать это приложение в магазине и подписаться на эти API-интерфейсы, необходимые для разработки приложения. Таким образом, этот разработчик приложения будет использовать сервисы, предоставляемые API, опубликованными предыдущим разработчиком. Код для примера веб-приложения для заказа пиццы можно также загрузить с svn.
- При подписке он / она получает секретный ключ пользователя и потребительский ключ, которые затем используются для запроса токенов OAuth для доступа к API (в этом примере мы используем имя пользователя и пароль, которые требуются в типе предоставления «пароль». Существует несколько других возможных типов предоставления а также, если мы не хотим отправлять пароль).
Получите ключ пользователя и секрет из «Моих подписок».
- Разработчик встраивает ключ потребителя и секрет потребителя в приложение заказа пиццы (в большинстве случаев в web.xml).
|
1
2
3
4
5
6
7
8
|
<context-param> <param-name>consumerKey</param-name> <param-value>FyfSK4RNHqGETmnNkaI87hIoNFQa</param-value> </context-param> <context-param> <param-name>consumerSecret</param-name> <param-value>1NFr7jb8JBA3IFa6gkjoN_PoYAca</param-value> </context-param> |
На этом этапе мы можем проверить работу токена с помощью простой команды curl следующим образом. Укажите маркер доступа, взятый из вышеуказанного интерфейса.
|
1
|
curl -k -H "Authorization: Bearer <access_token>" https://localhost:8245/pizzashack/menu/1.0.0 |
который вернет детали меню для пиццы следующим образом,
|
1
|
[{"price":"13.99","icon":"/images/6.png","description":"Grilled white chicken, hickory-smoked bacon and fresh sliced onions in barbeque sauce","name":"BBQ Chicken Bacon"},{"price":"24.99","icon":"......................:"/images/5.png","description":"Rich and creamy blend of spinach and garlic Parmesan with Alfredo sauce","name":"Spinach Alfredo"},{"price":"15.99","icon":"/images/4.png","description":"Six cheese blend of mozzarella, Parmesan, Romano, Asiago and Fontina","name":"Tuscan Six Cheese"}] |
Поскольку мы уже видели токен доступа, мы можем использовать его здесь. Но когда конечный пользователь приходит и пытается заказать пиццу, он не видит их. Также этот токен связан с USER_TYPE: APPLICATION, который имеет больше привилегий, чем конечный пользователь, поэтому мы не можем позволить ему использовать его. Таким образом, то, что происходит ниже, — это создание отдельного токена для конечных пользователей с использованием встроенного ключа / секретного ключа потребителя и введенных учетных данных конечного пользователя (если используется тип предоставления пароля), который будет связан с USER_TYPE: APPLICATION_USER.
Конечный пользователь
Итак, вот и конечный пользователь, который зарегистрировался в App Store.
Затем конечные пользователи могут использовать приложение для заказа пиццы в Интернете, введя свои учетные данные в приложении по адресу http: // localhost / pizzashack .
API-M, находящийся посередине, выступает в качестве сервера авторизации в сценарии, управляя использованием открытых API.
Так, где утверждение JWT вступает в игру?
Утверждение JWT — это формат, используемый для отправки сведений о конечном пользователе, который вызвал API. Так же, как утверждение SAML будет переносить пользовательские утверждения, JWT также переносит пользовательские утверждения в нотации JSON. Более подробную информацию об этом можно найти в [2]. Это используется для передачи этих подробностей во внутреннюю службу, которая может потребовать их для мониторинга или какой-либо другой цели. Маркер JWT по умолчанию будет выглядеть следующим образом.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
{ "iss":"wso2.org/products/am", "exp":1391029971429,} |
Ура!
Ресурсы: