Статьи

Mule 4 – принудительное применение идентификатора клиента

Привет всем! Сегодня я попытаюсь подробно объяснить, как реализовать 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 может быть определена черта, как показано ниже.

traits:
  client-id-required:
    headers:
      client_id:
        type: string
      client_secret:
        type: string
    responses:
      401:
        description: Unauthorized or invalid client application credentials
      500:
        description: Bad response from authorization server, or WSDL SOAP Fault error

Затем эта черта должна применяться к ресурсу или методам с использованием isатрибута RAML.

/products:
  get:
    is: [client-id-required]
    description: Gets a list of all the inventory products.

 

 

Ниже приведены шаги, которые мы предпримем для создания проекта и применения нашей политики: 

Разработка API с использованием RAML


YAML