Как определить принцип 4 глаз в ALFA (/XACML)?

Мне нравится, как в ALFA можно определить принцип четырех глаз. (аксиоматика)

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

Таким образом, когда сотрудник банка нажимает кнопку «активировать учетную запись», политика должна обеспечить, чтобы его менеджер сначала одобрил это. Звучит как обязательство передо мной, или есть лучшие способы обеспечить это с помощью политики?

Может ли кто-нибудь дать мне пример ALFA, как это сделать?


xacml alfa
person Morei    schedule 03.12.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Это большой вопрос. Есть два способа сделать это. Как вы указали, вы можете использовать обязательство. Ваша политика будет следующей:

  • пользователь с ролью == сотрудник может выполнить действие == активировать на ресурсе типа == банковский счет, если и только сотрудник создал учетную запись -> РАЗРЕШЕНИЕ + обязательство «всплывающее диалоговое окно утверждения для менеджера, чтобы подписать активацию» .

Если PEP не выполняет обязательство, учетная запись не может быть активирована (решение переключается на DENY).

Это, однако, дает PEP много работы (обязательство реализовать) и создает синхронный поток.

Альтернативой является создание другого атрибута, который будет использоваться в политике. Этот атрибут может быть managerApproved и employeeApproved. Это создает асинхронный поток, но это означает, что вам нужно где-то хранить значения managerApproved и employeeApproved в базе данных.

Политики станут:

  • пользователь с ролью == сотрудник может выполнить действие == активировать на ресурсе типа == банковский счет, если и только сотрудник создал учетную запись -> РАЗРЕШЕНИЕ + обязательство «отправить менеджеру ссылку по электронной почте для подтверждения активации».
  • пользователь с ролью == сотрудник может выполнить действие == активировать на ресурсе типа == банковский счет тогда и только тогда, когда isManagerApproved == true
  • пользователь с ролью==менеджер может выполнить действие==одобрить на ресурсе типа==банковский счет тогда и только тогда, когда создатель находится в списке подчиненных.
person David Brossard    schedule 04.12.2014
comment
IMO, асинхронный поток был бы более подходящим, учитывая, что процесс утверждения менеджером и т. Д. По своей природе является потоком асинхронного процесса, и политика должна иметь возможность поддерживать это изначально. - person Srijith Nair; 04.12.2014
comment
Да, у меня тоже есть склонность к асинхронному потоку - person David Brossard; 04.12.2014