2.5 Интеграционный шлюз

Для реализации управления доступом в защищаемой информационной системе, реализован подход – управление безопасностью API. В основе лежит принцип построения web-приложений, компоненты которого полностью отделены друг от друга и используют API-интерфейсы для осуществления информационного обмена.

2.5.1 Общее описание модуля Security Proxy

Модуль Security Proxy представляет небольшой, быстрый и масштабируемый шлюз API для реализации функций безопасности, который находится между API (интерфейсом объекта доступа) и инициатором запроса (субъектом доступа или его посредником).

Данный модуль отвечает за применение политик доступа, настроенных в консоли управления TVS и при успешном выполнении политик отвечает за ретрансляцию запроса, с сохранением всей его полезной нагрузки: параметров, заголовков и т.д.

Для инициатора запроса, взаимодействие с тем или иным API, осуществляется аналогично, как если бы он взаимодействовал с API напрямую, внутренние механизмы обеспечения безопасности и ретрансляции, равно как и данные о местоположении компонентов защищаемой информационной системы (интерфейсы объекта доступа) максимально скрыты.

2.5.1.1 Общие положения

2.5.1.1.1 Базовые требования

Компонент Security Proxy соответствует следующим базовым требования информационной безопасности:

  • Перехват HTTP запросов от инициатора запроса (субъекта доступа или его посредника) к API-интерфейсам информационной системы (интерфейсам объекта доступа), в режиме обратного прокси-сервера (reverse-proxy).
  • Выделение из заголовка, перехваченного HTTP запроса JWT токен, а так же проверка подписи токена, путем запроса к серверу безопасности (либо по загруженному публичному ключу). Если токен не соответствует установленным политикам доступа (не валиден, просрочен) происходит отклонение запроса с ошибкой 401.
  • Извлечение из токена роли и/или передаваемые параметры (опционально иметь возможность получения их с сервера безопасности с идентифицией субъекта доступа помощи JWT токена), а также параметры HTTP запроса, такие как метод, URI итд.
  • Сопоставление согласно списку зарегистрированных API-сервисов, подходящую под метод и URI роли и проверка ее наличия в токене (или по данным сервера безопасности). Если такая роль отсутствует в списке имеющихся, либо URI не найден в таблице настроек - происходит отклонение запроса с ошибкой 403.
  • Проверка в параметрах запроса (или URI) идентификаторов, запрашиваемых данных и сравнение их с передаваемыми параметрами JWT токена (или полученными с сервера безопасности). Если прав на доступ с нужными параметрами запроса нет - происходит отклонение запроса с ошибкой 403.
  • Ретрансляция HTTP запроса в целевой API-сервис (интерфейс объекта доступа), идентифицированный при проверке доступа.
  • Ретрансляция полученного от API-сервиса ответа к инициатору запроса (субъекту доступа или его посреднику).

2.5.1.1.2 Публикация API сервисов

Для управления публикацией API-сервисов на модуле Security Proxy реализован соответствующий раздел «Интеграционный шлюз», отображенный в консоли управления TVS с подразделами «Сервисы» и «Политики безопасности» (Рис. 2.127).

../_images/image648.png

Рис. 2.223 Раздел «Интеграционный шлюз»

Security Proxy используется для выполнения вызовов API-интерфейсов к опубликованным сервисам https://tvs.tionix.ru/api/apidoc/index.html

Формат конкретной конечной точки, используемой для вызова определенного API-сервиса, построен следующим образом:

http(s)://<хост Security Proxy>:<порт>/proxy/{идентификатор сервиса}/

Все сегменты пути за пределами сегмента {идентификатор сервиса} ретранслируются на конечную точку внутреннего реального API-сервиса. Кроме того, все HTTP-заголовки и все параметры запроса также передаются на реальный API-сервис (если политиками безопасности не предусмотрено иное).

2.5.1.1.3 Регистрация событий безопасности

Security Proxy фиксирует каждый сделанный к нему запрос. Минимально, в состав каждой записи о запросе, входит следующая информация:

  • время начала и окончания запроса;
  • путь к интерфейсу API-сервиса;
  • параметры запроса (включая заголовки, метод) к интерфейсу API-сервиса;
  • тип ответа;
  • информация о интерфейсе API-сервиса (идентификаторы ИС и сервиса);
  • информация о инициаторе запроса.

Интеграционный шлюз находится между API (интерфейсом объекта доступа) и инициатором запроса (субъектом доступа или его посредником) и предназначен для реализации функций безопасности.

Данный модуль отвечает за применение политик доступа, настроенных в консоли управления TVS и, в случае успешного их прохождения - ретрансляцию запроса с сохранением всей его полезной нагрузки, параметров, заголовков и т.д.

2.5.1.1.4 Описание политик безопасности

2.5.1.1.4.1 Политика аутентификации

Базовая политика аутентификации для Security Proxy поддерживает механизм аутентификации по протоколу OAuth2. Сервер безопасности TVS является централизованным провайдером аутентификации и политика имеет с ним тесную интеграцию.

Сервер безопасности TVS обрабатывает запросы аутентификации к API-сервису, относительно привязки к информационной системе, зарегистрированной в TVS. Существует возможность применения политики как к API-сервису, так и к группе API-сервисов в рамках одной информационной системы.

Политика включает в себя минимальные параметры:

  • обязательность безопасности транспорта (SSL, TLS);
  • удаление токена (для удаления токена перед ретрансляцией запроса);
  • информационную систему/пользователей/сервисные учетные записи (указание субъекта доступа);
  • максимальный допустимый сдвиг времени жизни токена;
  • тип ошибки аутентификации, возвращаемый HTTP код
  • переподписание токена (с дополнительными параметрами).

Параметр может быть активен, если не активен параметр удаления токена. Формат передачи токена стандартизирован протоколом OAuth2 (RFC6750) в заголовке Authorization как параметр: «Bearer <jwt_token>». Для аутентификации используется как access_token так и id_token. Для всех вариантов токена обязателен параметр «aud», с дополнительным идентификатором – security-proxy.

В зависимости от указанных параметров, запросы с некорректной подписью токена и вышедшим временем жизни токена, будут отклонены с указанным возвращаемым HTTP-кодом.

При активации параметра переподписания токена Security Proxy, после процедуры аутентификации, добавляет в запрос к API-сервису заголовок Authorization с параметром: «Bearer <jwt_token>». Данный токен по функциональной нагрузке соответствует переданному токену аутентификации.

Security Proxy осуществляет процедуру переподписания токена. Параметры проверки подписи токена Security Proxy, доступны двумя методами, выбираемыми опционально в настройках TVS:

  1. Добавлением в заголовочную часть токена параметров «n» и «e»
согласно спецификации JSON Web Signature (RFC7515), которые позволяют восстановить публичный RSA ключ, для проверки сигнатуры подписи токена, переподписанного Security Proxy.
  1. Добавлением в заголовочную часть токена параметров «kid» согласно

спецификации JSON Web Signature (RFC7515) и получением с REST сервиса Security Proxy, в формате JWKS согласно спецификации JSON Web Key (RFC7517), публичного RSA ключа, для проверки сигнатуры подписи токена, переподписанного Security Proxy (адрес REST сервиса:

http(s)://<хост Security Proxy>:<порт>/proxy/__service/jwks).

Проверяющая данный токен сторона валидирует параметры:

  • «azt» – должен соответствовать идентификатору ИС, которая производит запрос к защищенному ресурсу;
  • «aud» – должен соответствовать идентификатору security-proxy;
  • сигнатура JWT токена, которая соответствует публичному RSA ключу Security Proxy (который получен по одному из двух методов выше).

Время жизни токена находится в пределах текущего времени обработки токена.

2.5.1.1.4.2 Политика авторизации

Эта политика обеспечивает авторизацию для ресурсов API-сервиса на основе ролей аутентифицированных пользователей. Политика используется для предоставления доступа к API-сервисам (аутентифицированным пользователям) с произвольной детализацией.

Конфигурация этой политики состоит из ряда правил, которые применяются к любому входящему запросу к API-сервису. Каждое правило состоит из шаблона регулярного выражения, HTTP-команды и роли, которой обладает аутентифицированный пользователь для предоставления доступа.

Система ограничивает настройку политики, для возможности ее настройки только после того, как настроена политика аутентификации, так как политика аутентификации отвечает за извлечение ролей аутентифицированного пользователя, то есть данных, необходимых для того, чтобы политика авторизации могла корректно функционировать.

Политика должна включать в себя массив (возможен множественный набор правил с разными условиями) правил, которые выполняются последовательно.

Минимальные параметры правил:

  • шаблон, который соответствует пути ресурса запроса, к которому необходимо применить политику (Например: /users/*);
  • HTTP-команда, которая соответствует запросу, к которому необходимо применить политику (Все, GET, POST, PUT, DELETE, OPTIONS, HEAD, TRACE, CONNECT);
  • роль, которую имеет пользователь, если этот шаблон соответствует запросу (доступную как для ручного ввода, так и опционально может быть выбрана из ролей информационной системы), а также откуда она извлекается при проверке (токен, параметр пользователя из TVS);
  • параметр запроса, с указанием какой элемент запроса (только QUERY PARAMETERS и HEADERS) берется для проверки и какому параметру соответствует (явно заданный параметр, параметр токена, параметр информационной системы из TVS), а также откуда он извлечен (если не задан явно) при проверке (токен, параметр пользователя из TVS).

Пример формирования правил:

Правило 1:

Шаблон: /admin/*
HTTP-команда: *
Роль: admin

Правило 2:

Шаблон: /*
HTTP-команда: GET
Роль: user

Также для массива параметров предусмотрены следующие флаги:

  • соответствие всем правилам: значение истина, если обязательно соответствие всему набору правил; ложь, если должно соответствовать только одно правило;
  • инверсия правил: значение истина, если нужно, чтобы политика аутентификации отрабатывала при несовпадении всего набора правил;
  • тип ошибки авторизации, возвращаемый HTTP код.

В зависимости от параметров проверки политики авторизации, запросы будут отклонены с указанным возвращаемым HTTP кодом.

2.5.2 Вкладка Сервисы

2.5.2.1 Создание сервиса

В рамках выбранного домена в левой вертикальной навигационной панели выберите вкладку «Интеграционный шлюз» и перейдите на страницу:

Интеграционный шлюз>> Сервисы.

Откроется таблица со списком сервисов и указанием параметров каждого сервиса. Для создания сервиса нажмите на кнопку «Создать».

В появившемся окне введите данные о сервисе и подтвердите создание нажатием одноименной кнопки (Рис. 2.128).

../_images/image649.png

Рис. 2.224 Раздел «Интеграционный шлюз»

  • Клиентская система – клиентская система, которая предоставляет сервис;

Примечание.

Данная клиентская система не имеет доступа к сервису по умолчанию, необходимо добавить доступ клиентской системе в политике сервиса (Раздел 2.5.3)

  • Наименование – наименование сервиса;

  • Описание – описание сервиса;

  • Путь – путь сервиса, генерируется автоматически, также его можно указать вручную. После создания сервиса конечная точка, используемая для вызова целевого API-сервиса, будет доступна по следующему адресу:

  • Адрес – адрес конечной точки целевого API-сервиса;

  • кнопка Публичный – если включена, то для публичного сервиса не проверяется токен пользователя и не применяются политики;

  • кнопка Разрешен CORS – если включена, то разрешает прохождение preflight-запросов (для CORS);

  • кнопка Активность - признак активности сервиса, при обращении к неактивному сервису будет возникать ошибка «Сервис отключен».

Нажмите на кнопку «Создать» (Рис. 2.128). Произойдет переход на страницу сервиса со вкладками «Основное», «Политики», «Журнал запросов».

Вкладка «Основное» имеет параметры, заполненные во время создания сервиса (Рис. 2.225).

../_images/image650.png

Рис. 2.225 Сервисы. Вкладка «Основное».

На вкладке «Политики» можно назначать политики сервиса, а также изменять их приоритет. Политики аутентификации приоритетнее политик авторизации. Данная вкладка отображается только у непубличного сервиса.

Для добавления политики нажимите кнопку «Добавить». В появившемся окне выберите тип и наименование политики, затем нажите кнопку «Добавить» (Рис. 2.226)

../_images/image651.png

Рис. 2.226 Добавление политики.

Для удаления политики из списка политик сервиса выделите нужную политику и нажите кнопку «Удалить». Для того, чтобы повысить или понизить приоритет политики нажмите на кнопку показанную на (Рис. 2.227)

../_images/image652.png

Рис. 2.227 Удаление политик. Выставление приоритета политик.

На вкладке «Журнал запросов» отображается информация о запросах к сервису (Рис. 2.228).

../_images/image653.png

Рис. 2.228 Журнал запросов

Имеется возможность поиска запросов по определенным параметрам и сортировке. Для поиска запросов раскройте панель с фильтрами, нажав на кнопку «+» как на (Рис. 2.228). Затем заполните нужный фильтр и нажмите на кнопку «Поиск» (Рис. 2.229).

../_images/image654.png

Рис. 2.229 Журнал запросов (Поиск)

Фильтры поиска:

  • Дата и время запроса – промежуток времени, в течение которого поступил запрос;
  • Дата и время ответа – промежуток времени, в течение которого был отправлен ответ;
  • Метод запроса – HTTP-метод запроса;
  • Путь запроса – путь конечной точки запроса;
  • Параметры запроса – параметры, указанные в запросе, например, query=limit(10);
  • Клиентская система запроса – клиентская система, через которую произвел вход пользователь, отправивший запрос;
  • Пользователь запроса – пользователь, отправивший запрос;
  • IP адрес пользователя – IP адрес, с которого был отправлен запрос;
  • Статус код ответа – HTTP код ответа сервиса;
  • Узел системы – узел, на который пришел запрос;
  • Ошибочный запрос – признак некорректного запроса.

2.5.3 Вкладка Политики безопасности

Политики интеграционного шлюза включают в себя Политики аутентификации и Политики авторизации.

2.5.3.1 Политики аутентификации

Для создания политики аутентификации выберите пункт меню:

Интеграционный шлюз >> Политики безопасности >> Политики аутентификации.

Нажмите кнопку «Создать» (Рис. 2.230).

../_images/image655.png

Рис. 2.230 Политики безопасности

В появившемся окне введите данные о политике (Рис. 2.231).

../_images/image656.png

Рис. 2.231 Политики безопасности (Создание политики аутентификации)

Параметры политики аутентификации:

  • Наименование – наименование политики;

  • Описание – описание политики;

  • Время жизни токена – максимальное время действия токена. По истечении этого времени вернется ошибка с кодом, указаным в параметре «Код ошибки»;

  • Требуется SSL – если параметр активен, то политика требует, чтобы запросы к сервису осуществлялись только посредством SSL, в противном случае при запросе вернется ошибка с кодом, указаным в параметре «Код ошибки»;

  • Удалять токен – если параметр активен, токен будет удален перед ретрансляцией запроса;

  • Переподписать токен - если параметр активен, то интеграционный шлюз заменяет токен в заголовке Authorization;

  • Тип ключа - тип ключа для подписи токена, данный параметр обязателен, если активен параметр «Переподписать токен».

    Если выбран тип «Вложенный», то в заголовочную часть токена добавляются параметры «n» и «e», согласно спецификации JSON Web Signature (RFC7515). Данные параметры позволяют восстановить публичный RSA ключ для проверки подписи токена, переподписанного интеграционным шлюзом.

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

    {
    "kid": "N-DIRW_Pjztwnk-NbpagJUQPK3JAtCXNLQxldHh30Go",
    "typ": "JWT",
    "alg": "RS256",
    "jwk": {
      "kty": "RSA",
      "e": "AQAB",
      "kid": "N-DIRW_Pjztwnk-NbpagJUQPK3JAtCXNLQxldHh30Go",
      "n": "qQGGBtZRgtaWhDYYGjT-CfEDZb9mO5dWJYPZ0Gw5RQpEgy8QoNzyz4d_-Pue
      -Q5hOKpAtoWV4uEk0gCq3YxbRGmGPdoM1x5PvuDn6utlXczkZA7f0MJj3XR4jpa4yFeDkOHGBY
      -1PJ0s3K6OHv2ToLUyEf7ciG2bBVg9ZZ9SforviZVPVKKt87l3Kg3Q2nPWFzdcepPodyWGULsUwd9ScFYOT3NO8k19URb3KuXOTQx
      _QLixY-4NxO2sHVr7wEQnYOWpFn4dxSUd0kXAA3aB6VM1brI123Rao0Vc8cJqI8vZVmOCuo22xkmOIjcHnvdQJJAmPrADvLnVa0mis8jdbw"
    }
    

    }

    Если выбран тип «Невложенный», то в заголовочную часть токена добавляется параметр «kid» согласно спецификации JSON Web Signature (RFC7515). Публичный RSA ключ для проверки подписи токена, переподписанного интеграционным шлюзом, можно получить с REST сервиса: http://tvsdemo.ru:8080/proxy/__service/jwks по параметру «kid».

    Пример заголовочной части токена:

    {
    "kid": "N-DIRW_Pjztwnk-NbpagJUQPK3JAtCXNLQxldHh30Go",
    "typ": "JWT",
    "alg": "RS256"
    

    }

  • Код ошибки – HTTP код ошибки, который возвращается политикой, если активен параметр «Требуется SSL», но при передаче запроса не использовался SSL, если истекло время жизни токена;

  • Активность – признак активности политики.

Нажмите на конпку «Сохранить».

После создания политики осуществляется автоматический переход на страницу созданной политики, где можно настроить следующие параметры: «Основное», «Доступы клиентских систем», «Доступы пользователей», «Сервисы».

На вкладке «Основное» отображены параметры, которые вводились при создании политики аутентификации (Рис. 2.232).

../_images/image657.png

Рис. 2.232 Политики безопасности. Вкладка «Основное»

На вкладке «Доступы клиентских систем» можно добавлять и удалять доступ клиентским системам. Если клиентской системе добавлен доступ, то все пользователи, которые произвели вход через данную клиентскую систему, имеют доступ к сервисам.

Для добавления доступа нужно выбрать клиентскую систему в списке и нажать кнопку «+» (Рис. 2.233).

../_images/image658.png

Рис. 2.233 Политики безопасности. Вкладка «Доступы клиентских систем»

Вкладка «Доступы пользователей» предназначена для добавления и удаления доступа пользователям. Доступ к сервису будут иметь только указанные пользователи.

Для добавления доступа нужно выбрать пользователя в списке и нажать кнопку «+» (Рис. 2.234)

../_images/image659.png

Рис. 2.234 Политики безопасности. Вкладка «Доступы пользователей»

Вкладка «Сервисы» предназначена для добавления и удаления применимости политики к сервису интеграционного шлюза. Для добавления сервиса нужно выбрать сервис в списке и нажать кнопку «+» (Рис. 2.235)

../_images/image660.png

Рис. 2.235 Политики безопасности. Вкладка «Сервисы»

2.5.3.2 Политика авторизации

2.5.3.2.1 Создание политики авторизации

Для создания политики авторизации выберите пункт меню:

Интеграционный шлюз >> Политики безопасности >> Политики авторизации

Нажмите на кнопку «Создать» (Рис. 2.236).

../_images/image661.png

Рис. 2.236 Создание политики авторизации

Заполните параметры политики авторизации:

  • Наименование – наименование политики;
  • Описание – описание политики;
  • Код ошибки – HTTP код ошибки, который возвращается политикой;
  • Активность – признак активности политики.

Нажмите на кнопку «Сохранить».

После создания политики авторизации осуществляется автоматический переход на страницу созданной политики, где можно настроить следующие параметры: «Основное», «Правила доступа», «Сервисы» (Рис. 2.237).

../_images/image662.png

Рис. 2.237 Политики авторизации. Вкладка «Основное».

2.5.3.2.2 Создание правила доступа

Вкладка «Правила доступа» предназначена для добавления и удаления правил доступа, а также изменения их приоритета.

Для добавления правила доступа нажмите кнопку «Создать». В появившемся окне введите данные правила и сохраните введенную информацию (Рис. 2.238).

../_images/image663.png

Рис. 2.238 Политики авторизации (Окно создания правила доступа)

Параметры правила доступа:

  • Шаблон – шаблон, который должен соответствовать пути ресурса запроса, к которому необходимо применить правило. Допускакется использование формата регулярного выражения, например: /users/*, /.*/user;

  • HTTP-метод– HTTP-метод, который должен соответствовать запросу, к которому необходимо применить правило;

  • Режим работы – указывает критерий применимости ролей/параметров:

    Примечание.

    При пустых ролях и параметрах режимы работы «Соответствие всем ролям/параметрам» и «Соответствие одному или нескольким из ролей/параметров» работают на пропускание запроса, а режим работы «Инверсия ролей/параметров» – на запрет запроса с кодом ошибки.

  • Код ошибки – HTTP код ошибки, возвращаемый политикой, может быть пустым;

    Если этот параметр непустой, то возвращается код ошибки правила; в противном случае возвращается код ошибки политики.

  • Роли – роли, которые должен иметь пользователь, если шаблон соответствует запросу;

  • Параметры – параметры проверки политики авторизации.

2.5.3.2.3 Добавление роли

Для добавления роли нажмите кнопку «+» и заполните поля в появившемся окне (Рис. 2.239).

../_images/image664.png

Рис. 2.239 Создание роли для правила доступа.

Параметры роли правила доступа:

  • Роль – наименование роли, которую должен иметь пользователь. Может быть выбрана из списка или задана вручную;

  • Утверждение – наименование утверждения, которое содержит роль;

  • Тип проверки – место, откуда роль должна быть извлечена при проверке.

    «Информация о пользователе» – это информация из ресурса UserInfo.

Нажмите кнопку «Создать».

2.5.3.2.4 Создание параметра для правила доступа

Для добавления параметра нажмите кнопку «+» и заполните поля в появившемся окне (Рис. 2.240).

../_images/image665.png

Рис. 2.240 Создание параметра для правила доступа.

Для создания параметра необходимо заполнить следующие поля:

  • Тип параметра – указывает, какой элемент запроса должен быть взят для проверки;
  • Наименование – наименование параметра;
  • Тип проверки – тип проверки параметра: «Значение» - параметр должен соответствовать значению, заданному в поле «Значение»; «Токен» - параметр должен соответствовать утверждению токена; «Информация о пользователе» – параметр должен соответствовать утверждению из ресурса UserInfo;
  • Значение – значение, которому должен соответствовать параметр. Отображается, если выбран тип проверки «Значение»;
  • Утверждение – утверждение, которому должен соответствовать параметр. Отображается, если выбран тип проверки «Токен» или «Информация о пользователе».

Нажмите кнопку «Создать».

2.5.3.3 Примеры правил доступа

Правило, которое применяется к POST запросу на ресурс, путь которого соответствует шаблону /users (Рис. 2.241).

../_images/image666.png

Рис. 2.241 Изменение правила доступа.

Данное правило проверяет, что в утверждении realm_access.roles в информации о пользователе указана роль admin и параметр запроса role соответствует утверждению realm_access.roles в информации о пользователе. В противном случае, политика вернет ошибку с кодом 403 (Рис. 2.241).

2.5.4 Примеры запросов

  • Успешный запрос, так как в утверждении realm_access.roles информации о пользователе указана роль «admin» и указан параметр запроса role со значением admin.
curl -X 'POST' -H 'Content-Type: application/json' -H 'Authorization: Bearer <access_token>' --data
'<данные запроса>' http://tvsdemo.ru:8080/proxy/test_rule/users?role=admin -i
HTTP/1.1 201 Created
  • Неуспешный запрос, так как в утверждении realm_access.roles информации о пользователе не указана роль «admin» и не указан параметр запроса role.
curl -X 'POST' -H 'Content-Type: application/json' -H 'Authorization: Bearer <access_token>' --data
'<данные запроса>' http://tvsdemo.ru:8080/proxy/test_rule/users -i
HTTP/1.1 403 Forbidden
  • Правило, которое применяется к DELETE запросу на ресурс, путь которого соответствует шаблону «/users/.*».

Данное правило проверяет, что в утверждении realm_access.roles в токене указана роль admin или параметр role в заголовке запроса соответствует значению admin. В противном случае политика вернет ошибку с кодом 403 (Рис. 2.242).

../_images/image667.png

Рис. 2.242 Изменение правила доступа.

  • Успешный запрос, так как в утверждении realm_access.roles токена пользователя указана роль «admin».
curl -X 'DELETE' -H 'Authorization: Bearer <access_token>'
http://tvsdemo.ru:8080/proxy/test_rule/users/0e73783e-90dd-4de7-ac8c-709ab116f6b2 -i
HTTP/1.1 204 No Content
  • Успешный запрос, так как указан заголовок role со значением admin.
curl -X 'DELETE' -H 'role: admin' -H 'Authorization: Bearer <access_token>'
http://tvsdemo.ru:8080/proxy/test_rule/users/0e73783e-90dd-4de7-ac8c-709ab116f6b2 -i
HTTP/1.1 204 No Content
  • Неуспешный запрос, так как в утверждении realm_access.roles токена пользователя не указана роль «admin» и не указан заголовок role.
curl -X 'DELETE' -H 'Authorization: Bearer <access_token>'
http://tvsdemo.ru:8080/proxy/test_rule/users/0e73783e-90dd-4de7-ac8c-709ab116f6b2 -i
HTTP/1.1 403 Forbidden

Для того, чтобы повысить приоритет правила нажимите на кнопку «Вверх», чтобы понизить - на кнопку «Вниз».