andreymxДоступ пользователя к данным/услугам у нас в настоящее время двухуровневый, примерно такой

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

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


тру-SCSM-ы утверждают, что второй уровень во всем мире устарел, давно похерен и тру-системы все доступы выдают только на группу.
Нам выдали совет: размножайте группы по цехам. Типа 20 групп на 30 цехов - делайте 600 групп, куйня какая. Ну или делайте кусты из цехов, чтобы групп поменьше.
также говорят, что в SAPах и прочих одноэсках та же ситуация, один уровень, и всё.

Из личного опыта:

I УРОВЕНЬ: разграничение доступа по 10 направлениям деятельности:
1. Управление имуществом
2. Управление запасами
3. Управление производством
4. Управление продукцией
5. Управление финансами
6. Управление поставщиками
7. Управление покупателями
8. Управление персоналом
9.Управление капиталом
10. Управление доходами и расходами

II УРОВЕНЬ: разграничение доступа по 10 этапам деятельности в рамках вышеуказанных направлений:
1. Формирование номенклатурных справочников
2. Формирвоание норм, спецификаций, цен
3. Формирование бизнес-плана
4. Проектирование
5. Бюджетирование
6. Заключение договоров
7. Формирование календарного плана и графика
8. Приход
9. Расход
10. Бухгалтерский учет

III УРОВЕНЬ: разграничение доступа по подразделениям - местам деятельности.

Три уровня не используем, а сворачиваем в один как декартово производение 10х10х100(подразделений) = 10000 групп (ролей)
Количество ролей по пользователям не пугает, да и в реальной задаче ролей гораздо меньше.

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

Со стандартным Row-Level Security у администратора БД крышу снесет

Petro123sereginsereginСо стандартным Row-Level Security у администратора БД крышу снесет
Win + NTFS
http://citforum.ru/operating_systems/winntadm/winntadm_05.shtml

Традиционный подход к разделению доступа к каталогам и файлам не подходит (даже вреден) для бизнес данных.

Пример c расходной накладной: "Кладовщик склада №5 передает мастеру цеха №10 материал."

Накладная:
I. Два направления деятельности: из Управления запасами, в Управление производством
II. Один этап: Расход
III. Два подразделения: из №5, в №10

Кладовщик должен иметь доступ к документам на Запись:
I. Из направления деятельности: Управление запасами
II. Этап: Расход
III. Из подразделения: №5

Мастер должен иметь доступ к документам на Чтение:
I. В направление деятельности: Управление производством
II. Этап: Расход
III. В подразделение: №10

Как Вы будете организовывать Win + NTFS файловый архив подобных документов?
Это кошмарный сон администратора и пользователей для традиционного файлового архива!

Sergey_rbОдин пользователь имеет доступ к нескольким проектам

Как пользователей разносить по проектам-группам-ролям понятно.
У меня, как я понял и у автора топика, стоит задача раздать пользователям доступ к однотипным документам по принадлежности их к цехам/подразделениям

У себя мы решаем через промежуточную таблицу:
- Роль
- Объект(таблица) БД
- Поле в таблице (ИзЦеха, ВЦех, любое другое)
- Значение поля для которого разрешен доступ данной роли
- Уровень доступа (Чтение/Запись)

Универсальная функция для любоко пользователя по его ролям строит индивидуальные условия отбора записей к любому объекту БД.

Это не супер удобно в плане программирования, но админится гораздо проще, чем настраивать RLS к каждой таблице БД вручную

Petro123sereginsereginКак Вы будете организовывать Win + NTFS файловый архив подобных документов?
Это кошмарный сон администратора и пользователей для традиционного файлового архива!
вы вроде вопрос задавали другой
sereginsereginИнтересен другой вопрос, какие стандартные решения есть для соотноесени роли с объектами БД.
выше - стандартное решение. Есть роль - проверяйте при бизнес-методе "Хочу удалить".
Дополнительно "Если нужно", навешайте права на конкретный объект как в винде.
Не надо - не вешайте.
Роль - "может править".
Объект - свой отдел.
В чём проблема?
...
По поводу накладных - зовите аналитика. Технические средства - есть.

Как вы себе предстваляеете вешать ВСЕ права на конкретную накладную, кто это будет делать, кладовщик, администратор, автомат?:
- Кладовщик должен редактировать накладные, по которым отпущен материал (в т.ч. другим кладовщиком) со своего склада
- Матер должен видеть накладные, по которым поступили материалы к нему в цех
- Диспетчер склада должен видеть расходы по накладным склада, чтобы сверять их с планом обеспечения
- Диспетчер производства должен видеть отпущенные на производство материалы, чтобы сверять их с планом производства
- Бухгалтер должен видеть все накладные, чтобы учитывать себестоимость материальных затрат
- Экономист должен видеть все накладные, чтобы контролировать видеть исполнение лимитов по местам возникновения затрат
- ....


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

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

На практике для распределения прав видел четыре подхода:
1. Ограничивать доступ по месту возникновения проблемы - в каждой форме свой запрос к БД со своими ограничениями
2. Реализовывать свою универсальную кривоватую балалайку - пример описан выше
3. Используя стандартные механизмы внедрять для каждого подразделения свой экземпляр приложения и организовать между подразделениями синхронизацию данный с учетом прав доступа
4. Послать на ... все разграничения прав по подразделениям, раздать доступ только по типам документов, остальное контролировать административным ресурсом, запрещая редактирование документов по концу отчетного периода