Мне понятно откуда возникает эта ошибка, не хочу вдаваться в тему "безопасно или нет получение пользователем списков групп и пользователей" не имея особой роли, пусть эта роль будет. Но это же не должна быть роль "Администратор"!
Решение переложить на Job-ы в данном случае не подходит.. Пользователю нужно выбрать кому отправлять или каким группам отправлять. Для этого нужно показать этот список. Ну и можно придумать большое количество задач, где нужен такой выбор.
На текущий момент есть решение использовать другую учетную запись.. Приведу цитату из документации:
Here is a common problem. You have a custom command that you want people to
use, but it does something that requires admin privileges. Making everyone
an administrator is a bad idea. A better solution is for your command to
perform an action as another user.
Vault doesn't support a true impersonation model, but there is a workaround
that works pretty well. Just have your program log in as another user to
perform the special task. Log out as soon as the task is done and let the
rest of the operations be performed by the logged-in user.
Recycle Bin 2.0 makes liberal use of this technique. The whole program rests
on a special "Recycle Bin" folder where files go before they are deleted.
Obviously this folder needs to be locked down from normal use. All
interaction with the Recycle Bin folder needs to be through one of the
custom commands. To enforce this, the administrator needs to designate a
special Recycle Bin User, which is the only one allowed to interact with the
Recycle Bin folder. Any time a Recycle Bin command is executed, the code
logs in as the Recycle Bin user in order to interact with the folder.
Considerations:
First, your code needs a way to know how to log in as the impersonated user.
In practice the impersonated user is usually an administrator, so you have
to keep the password hidden from the end user. There are various ways to fix
this. You can hard-code the password, or you can encrypt the password and
put it in a common location.
Next, there is the issue of licensing. If you log in as two different users,
you will consume 2 licenses. If licenses are tight, then impersonation might
not be an option. Logging out the original user is not a good idea because
what if all the licenses are used up when the operation is over an they try
to log back in?
The best approach is to use the impersonated user only as long as needed.
When the operation is over, log out immediately to free up the license. If
all goes well, it shouldn't have a noticeable impact on the licenses being
consumed.
Also, make sure to handle errors properly. If errors come up during the
operation, you still want to make sure the impersonated user get logged out
at the end.
Lastly, impersonation has an impact on data history. Let's say you have an
operation that uses impersonation to move a file to the Released state.
Later in time you want to see who released a certain file. That becomes hard
to do since the history of the item will show the impersonated user as the
one who made the change. What you want to see is the actual user.
This can be solved by storing the actual user as a piece of meta-data, such
as a UDP value. It's not a perfect workaround because the data you want is
not in the place where you expect it to be.
С точки зрения безопасности, предложенное решение куда хуже, нежели:
-либо специальная роль, дающая возможность readonly видеть какие-то части хранилища (назовем её ReadOnlyRole),
-либо непосредственно специальные методы API дающие такую возможность ( дополнительные методы из того же AdminService.. например GetReadOnlyGroupByName ) Vault Explorer по-прежнему вызывает GetGroupByName, а через API мы можем вызвать любой из этих 2-х
И если через API любой пользователь может "увидеть" эти данные (имея навыки программирования), то ReadOnlyRole устанавливается Админом. и он контролирует кому можно видеть такого рода информацию.
Ну или 3-й вариант - Метод GetReadOnlyGroupByName доступен пользователю с ролью ReadOnlyRole
Такой подход более безопасен, чем предложенный в документации.
Не по теме: Капчу можно упростить? А то головоломки втоpой дeнь нeдeли, последний день недели, тpи+чeтыpе/двa*пять (буkвaми).. )))