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

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

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

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

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

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

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

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

../_images/image649.png

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

../_images/image650.png

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

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

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

../_images/image651.png

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

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

../_images/image652.png

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

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

../_images/image653.png

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

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

../_images/image654.png

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

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

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

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

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

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

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

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

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

../_images/image655.png

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

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

../_images/image656.png

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

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

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

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

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

  • Требуется 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, если истекло время жизни токена;

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

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

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

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

../_images/image657.png

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

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

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

../_images/image658.png

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

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

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

../_images/image659.png

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

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

../_images/image660.png

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

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

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

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

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

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

../_images/image661.png

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

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

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

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

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

../_images/image662.png

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

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

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

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

../_images/image663.png

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

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

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

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

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

    Примечание.

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

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

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

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

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

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

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

../_images/image664.png

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

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

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

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

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

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

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

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

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

../_images/image665.png

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

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

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

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

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

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

../_images/image666.png

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

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

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

  • Успешный запрос, так как в утверждении 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 (Рис. 3.241).

../_images/image667.png

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

  • Успешный запрос, так как в утверждении 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

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