Запрещающая политика доступа

Вопросы и проблемы
#1

Здравствуйте!

В настоящий момент подсистема безопасности CUBA “из коробки” функционирует на основе разрешающей политики доступа (принцип “разрешено все, что явно не запрещено”):

  1. Если доступ к объекту явно не запрещен, то пользователь имеет доступ к этому объекту.
  2. При назначении двух ролей, одна из которых запрещает, а другая разрешает доступ, пользователю разрешен доступ (объединение с помощью логического “ИЛИ”).

Хочется реализовать запрещающую политику доступа (принцип “запрещено все, что явно не разрешено”):

  1. Пользователю запрещен доступ к объекту, если на него явно не выдано разрешение.
  2. При назначении двух ролей, одна из которых запрещает, а другая разрешает доступ, пользователю запрещен доступ (объединение с помощью логического “И”).

Возможно ли сделать подобные изменения, например, путем переопределения логики платформы?

Изучая механизмы платформы, пришел к следующим выводам:

  • Запрет на доступ по умолчанию можно реализовать, создав запрещающую роль и точечно разрешая в ней доступ к сущностям, но:
    • не получится реализовать объединение разрешений из нескольких ролей с помощью логического “И”;
    • наверняка пользователь все-таки должен иметь доступ к каким-то системным сущностям (например, тот же sec$User) для минимального функционирования системы, а определить набор таких сущностей затруднительно.
  • Права доступа проверяются внутри класса com.haulmont.cuba.security.global.UserSession, который не является бином и имеет наследников - соответственно не очень понятно, как переопределить его реализацию. Можно изменить логику наполнения UserSession путем переопределения com.haulmont.cuba.security.sys.UserSessionManager, но детально с этим еще не разбирался.

Еще один связанный вопрос: можно ли запретить пользователю доступ к системным сущностям через стандартный REST API? В текущей парадигме получается, что пользователь по умолчанию через REST может получить доступ к списку пользователей (http://{server}:{port}/app/rest/v2/entities/sec$User), назначенных заданий (http://{server}:{port}/app/rest/v2/entities/sys$ScheduledTask) и т.п.

Заранее спасибо за ответы!

1 симпатия
#2

Добрый день!

Действительно, переделать логику объединения разрешений из разных ролей на “И” сейчас проблематично. Мы подумаем над этим, см. тикет.

Что касается минимального доступа для функционирования пользователя в системе, он разрешается автоматически на базе описателя cuba-default-permission-values.xml, поэтому смело назначайте Denying роль всем пользователям и они тем не менее смогут входить в систему и работать с теми прикладными сущнностями, на которые вы явно дадите разрешения.

По REST API:

  • во-первых, пока вы не дадите роли явное Specific Permission: Use REST API, пользователи будут получать ошибку “User is not allowed to use the REST API” при любом запросе.

  • во-вторых, по умолчанию чтение пользователей (как и других системных сущностей) запрещено и получить их через REST без явных разрешений невозможно (опять же, если использовать Denying роль).

3 симпатии
#3

Константин, здравствуйте!

Действительно, переделать логику объединения разрешений из разных ролей на “И” сейчас проблематично. Мы подумаем над этим, см. тикет.

Большое спасибо!

Что касается минимального доступа для функционирования пользователя в системе, он разрешается автоматически на базе описателя cuba-default-permission-values.xml, поэтому смело назначайте Denying роль всем пользователям и они тем не менее смогут входить в систему и работать с теми прикладными сущнностями, на которые вы явно дадите разрешения.

Очень ценная информация. В процессе изучения платформы я на упоминание этого дескриптора наткнулся, а вот в документации про него ничего нет. Кроме того, в этом файле перечислено всего две системные сущности, и среди них нет sec$User. В то же время доступ к этой сущности явно необходим, чтобы можно было авторизоваться в системе. В связи с этим хотелось бы в общих чертах понять, как происходит авторизация пользователя - запрос к sec$User выполняется в другом контексте или в процедуре авторизации права не проверяются?

пока вы не дадите роли явное Specific Permission: Use REST API, пользователи будут получать ошибку “User is not allowed to use the REST API” при любом запросе.

Насколько я понимаю, это опять же справедливо лишь для denying роли. Ведь если пользователю назначить обычную роль и явно не определить permission Use REST API (или вообще не назначать ролей), то у него будет доступ и к REST API, и ко всем системным сущностям.

#4

Не проверяются, так как механизм авторизации работает на уровне EntityManager, а права автоматически проверяются только в API более высокого уровня - DataManager (и только при его вызове с клиентов).

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

1 симпатия