Привет всем! Сегодня я попытаюсь подробно объяснить, как реализовать Client Id Enforcement в Mule 4. Целью политики Client ID Enforcement является предоставление доступа только авторизованным клиентским приложениям.
Политика Client Id Enforcement используется для ограничения доступа к защищенному ресурсу, разрешая запросы только от зарегистрированных клиентских приложений. Политика гарантирует, что каждый запрос, который содержит действительные учетные данные клиента, может получить доступ к защищенным ресурсам.
Клиентское приложение должно быть зарегистрировано на платформе AnyPoint для генерации учетных данных клиента ( client_Id
и client_secret
). После регистрации клиентского приложения все последующие запросы должны пройти client_id
и client_secret
, как часть запроса, при вызове API.
Существуют некоторые политики, которые обеспечивают внутреннее применение учетных данных клиентских приложений. Это:
- Ограничение скорости — политика на основе SLA.
- Использование токенов доступа OAuth 2.0.
- Проверка JWT .
Прежде чем клиентскому приложению будет разрешено использовать API, защищенный политикой применения идентификатора клиента, клиентское приложение должно запросить доступ к API. После того, как между клиентским приложением и API существует утвержденный договор, каждый запрос должен включать учетные данные клиентского приложения в соответствии с настройкой политики.
Например, если политика настроена на ожидание идентификатора клиента и секрета клиента в качестве заголовков, приложение должно отправить эти учетные данные в запросе, используя соответствующие заголовки:
Вам также может понравиться:
Четыре способа сохранить секреты Кубернетеса в секрете .
Получение учетных данных с использованием заголовков HTTP
# [attributes.headers. [ ‘client_id’]]
# [attributes.headers. [ ‘client_secret’]]
В этом примере политика настроена на ожидание двух заголовков: client_id и client_secret с парой учетных данных. Политика является гибкой, чтобы разрешить и другие типы заголовков. Это конфигурация по умолчанию для политики.
Получение учетных данных с использованием параметров HTTP-запроса
# [Attributes.queryParams.’client_id ‘]
# [Attributes.queryParams.’client_secret ‘]
Запрашивающая сторона должна отправить два указанных параметра запроса вместе с запросом. Хотя это поддерживаемая конфигурация, она создает возможные угрозы безопасности. Рекомендуемый метод — использовать заголовки.
Получение учетных данных с использованием HTTP-запроса
# [Payload.client_id]
# [Payload.client_secret]
Хотя вы можете настроить политику для получения учетных данных из полезных данных запроса, этот параметр не рекомендуется, поскольку его сложнее отразить в спецификации API.
Политики на основе идентификатора клиента по умолчанию предполагают получение идентификатора клиента и секрета в качестве заголовков. Чтобы обеспечить это в определении API, в RAML может быть определена черта, как показано ниже.
Затем эта черта должна применяться к ресурсу или методам с использованием
|
Ниже приведены шаги, которые мы предпримем для создания проекта и применения нашей политики:
Разработка API с использованием RAML
YAML
1
#%RAML 1.0
2
title product-service
3
version v1
4
description Product Service
5
protocols HTTP HTTPS
6
documentation
7
title Product Detail Service API
8
content Product DetailAPI Content
9
traits
11
client-id-required
12
headers
13
client_id
14
type string
15
description client Id provided by API Manager
16
requiredtrue
17
client_secret
18
type string
19
requiredtrue
20
description The Client secret key provided by the API Manager
21
responses
22
401
23
description Unauthorized or invalid client application credentials
24
500
25
description Bad response from authorization server, or WSDL SOAP Fault error
26
types
28
ProductDetail
29
type object
30
properties
31
productId? number
32
productName? string
33
productPrice? number
34
/products
37
description Retrieve All Orders
38
post
39
is
40
client-id-required
41
description Get Order Information by CLient Id
42
responses
43
200
44
body
45
application/json
46
type ProductDetail
47
example !include examples/all-products.json
все-products.json
JSON
xxxxxxxxxx
1
[
2
{
3
"productId": 1001,
4
"productName": "Apple",
5
"productPrice" : 300
6
},
7
{
8
"productId": 1002,
9
"productName": "Google",
10
"productPrice" : 1000
11
},
12
{
13
"productId": 1003,
14
"productName": "Samsung",
15
"productPrice" : 100
16
}
17
]
Опубликовать API в обмен
На платформе Anypoint мы публикуем API для обмена.
Создайте проект спецификации API в API Manager, используя взамен опубликованный API (запишите идентификатор API)
После публикации API в Anypoint создайте проект спецификации API
Нажмите Управление API из Exchange
Выберите API (у меня есть создать продукт службы API- продукт-сервис ) и сохраните его. Как только мы сохраним проект спецификации API, он создаст идентификатор экземпляра API; пожалуйста, запомните это.
Now, check your client policies on policies -> Apply New Policy than select Client Id Enforcement policy. After you select Client Id Enforcement Policy, click on Configure Policy.
Do take note of how are we passing client_id and client_secret, and click the apply button.
Create a new mule project in AnyPoint Studio using API specification from exchange
Now, right-click on the project explorer canvas and click create a new mule project and select API specification from the exchange. Select API and click the finish button to create a Mule project.
This will create a default Mule flow using the API Kit router. Now, run the project in local Mule runtime.
Test the application using Postman or an equivalent testing tool.
As per API specification, client_id and client_secret must be passed through a request header. So, we are getting an error here. Once we start passing client credentials, we get a successful response; however, we have not applied our client id enforcement policy yet.
Using API discovery, apply API ID to the project
Click on Global Elements -> create and search for API Autodiscovery
Enter API ID (from Mule Anypoint platform policy application created in the previous step) and select the main flow and click on the ok button. Save the project.
Deploy the project on CloudHub.
After we deploy the application and run it from Postman, we get the following error, as client id enforcement policy has been applied, and we are not passing the correct value of client_id and client_secret.
So, we have to create a proxy application and create client_id and client_secret from that. Here are the steps for the same.
In the API Manager, click on the policy version and then click on "View API in exchange" on right hand side.
Here, click on three vertical dots and request access.
Create an application, select the API version, and click on Request Access. It will give you a popup with client_id and client_secret.
Make note of those client_id and client_secret values and pass them as part of the Http header.
Once we pass the correct values of client_id and client_secret, we are able to receive a successful response.