Mike SikaloВаше мнение? Может, известны какие-н. стандартные подходы к решению таких задач?

ИМХО, проверять права нужно в момент размещения заявки в очереди, чтобы в очереди не было "левых" заявок. Т.е. защищать службу нужно уже на входе в очередь, а дальше служба будет просто выполнять заявки со своими привилегиями.
Дополнительно можно ввести цифровую подпись заявки, чтобы служба была уверена, что заявка поступила именно от авторизованного пользователя или через авторизованный интерфейс.

Mike SikaloТак а как сохранить проверенные права, чтобы потом ими воспользоваться? Идея хранить логин/пароль вместе с заявкой в БД, пусть даже в зашифрованном/подписанном виде все же, мягко говоря, смущает.. Или я чего-то не понял?

Храни в заявке список привилегий или роль пользователя без пароля. Ведь ты можешь проверить, что у пользователя на момент размещения заявки была некая роль?

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

softwarer mcureenabИМХО, проверять права нужно в момент размещения заявки в очереди,
Не годится хотя бы из соображения "права меняются со временем". Допустим, я размещу на сервере задачу "ежемесячно выписывать сотруднику mcureenab премию в $1000". Если теперь мой лимит обрежут до премий в $100 - эта задача, весьма вероятно, должна перестать выполняться.

Согласен. Зависит от постановки задачи. Можно и так и эдак делать.

Мой вариант мне нравится в 10 раз больше. :o)))

softwarer mcureenabа дальше служба будет просто выполнять заявки со своими привилегиями.
А это еще и значит создание автоматического суперпользователя с суперправами. Значит, возникает проблема защиты его пароля.

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