Недавно начал разработку модуля управления правами доступа к объектам системы и столкнулся с некоторым кол-вом вопросов, которые можно решить двояко.

В двух словах есть несколько уровней пользователей:
1) Пользователи уровня системы (системные администраторы, пользователи, от лица которых будут выполняться системные службы).
2) Пользователи бизнес уровня (эти пользователи имеют разные бизнес-роли, хранят присущую персоне информацию, могут создавать других бизнес пользователей).

Существуют бизнес объекты ну и соответственно ACL'ы, которые определяют возможность выполнить пользователям ту или иную операцию.

В первую очередь интересуют материалы, какие-то стандартные шаблоны проектирования которые бы мне помогли определиться с тем как это реализовывать - интересует не схема БД, а общий подход.

Одна из проблем - это "взаимоотношение" пользователей 1ого и 2ого типов. Наследственной связи у них не получается - это разные объекты. Для системных пользователей (1ый тип) вся информация которая нужна - это логин и пароль. У бизнес пользователей для авторизации уже необходимо больше информации + много бизнес функций типа история, версионирование и т.д.

Если эти объекты разные, то получается, что ACL должен управлять правами пользователей двух типов. Соответственно получается, что и сессия приложения должна иметь возможность хранить пользователей двух типов? Правильно ли это?

BelyЧто-то как-то мутно у вас все...
Могли бы пояснить на реальном примере какие пользователи что должны уметь делать, а что нет?


Как я себе это вижу.

1) Есть пользователь ИС (инф. системы) - это бизнес пользователь.
Физ. человек заходит в систему под этими логин/паролем.

2) Есть несколько серверов БД и ОС (ресурсы), с которыми человек может работать.
Oracle, MS SQL, cisco, Web-сервер

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

Пользователи уровня системы могут ыбть привязаны к:
- бизнес-пользователю
- к действию (операции)
Например резервное копирование все делают из под специального пользователя, созданного на сервере, а не из под своей учетной записью.

4) Далее определяем какие у нас могут быть операции в системе и развешиваем ACL-и на эти операции и наделяем бизнес пользователя определенными правами.

Если БП попытается исполнить какое-то действие - то необходимо проверить права на выполнение этого действия.
Если прав хватает, то вычисляем системного пользователя под которым надо выполнять эту операцию.

Если будут более детальные примеры ЧТО и КАК должен уметь и не уметь БП - то можно подумать над механизмом, применимом для вашей задачи.

Я понял, давайте попробую на примере выразить мысль более понятно. Речь сейчас идёт не об учётных записях серверов.

Пример такой:
Существует бизнес-объект "Отдел". В рамках одного отдела существуют "бизнес-пользователи", которые в этом отделе управляют (создают/меняют/удаляют) разными бизнес-объектами, другими бизнес-пользователями опять же в рамках одного отдела. Права бизнес пользователя на объект определяет ACL. К слову, для авторизации такой пользователь должен указать не только свой логин и пароль, но и отдел, хотя это не суть важно, пока всё понятно.

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

Лично я вижу здесь два совершенно разных типа пользователей и не могу понять как правильно организовать их права на объект.

П.С. Есть мысль, что раз пользователи совершенно разные, то и объекты должны иметь два разных ACL для каждого типа пользователей...