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. Послать на ... все разграничения прав по подразделениям, раздать доступ только по типам документов, остальное контролировать административным ресурсом, запрещая редактирование документов по концу отчетного периода

Мы ведь говорим о применении прав доступа к объектам базыданных

Petro123Кто и как в винде вешает права на файл?
Вы наверно про наследование там и не знаете.


Аналог присвоения ролей доступа к объектам БД как к файлам в винде - я понимаю.
А что по Вашему в БД является аналогом виндового каталога(папки) по которому предлагаете присваивать наследуемые права?

Вы наверное не работаете с БД?

Petro123например, в оракле роли наследуются.
В базе данных таблицы тоже "наследуются"...... и чеее?

Распишите вашими стандартными средствами доступ к таблице с накладными для кладовщиков и мастеров с разграничением по подразделениям (складам, цехам).

Стандартными средствами без RLS этого не сделать. А через RLS - админ БД через 3 дня уволится.

Petro123sereginsereginСтандартными средствами без RLS этого не сделать. ...
т.е. вы ведёте к третьему варианту? .... Дак не томите).

Был бы третий - тыкнул пальцем, но его нет.

- Внедренцы коробок (типа 1с) для разграничения доступа пилят базы между подразделениями, затем их сложно синхронизят.
- Крупные внедренцы (типа SAP) допиливают разграничение доступа на уровне бизнес логики - получается как правило костыль
- Эксперементаторы при первой возможности (типа меня ;-) строят велосипед в котором никто не может разобраться, включая создателя
- Живого применения RLS не видел, слишком сложная логика получается для админа

Каждый выбирает то, что менее затратно. Четкого ответа автору топика, что выбрать для разграничения доступа у меня НЭТ!
У Вас видимо тоже.

ViPRos

Связка Роли с Объектами БД радует. Но без документации этот велосипед не понять. На сайте из лички информации маловато.

Напрягает, например:
r.GetChildRows("Земельный участок_Площадка").AsEnumerable()

Что это, условие отбора записей для доступа? Как это работает? Как быстро это работает?

Отдельно по применению системы есть сомнения, но обсуждать их предлагаю с другом Вашем топике

[quot ViPRos]sereginsereginпропущено...
чем напрягает? это обычное правило, если оно истина, то можно имеешь право добавить туда еще что нить.
Работает очень просто, запускается этот код (скомпилированный и закешированный) и проверяется возврат (код не может ничего менять (компилятор не пропустит), может только вычислить истинность утверждения), если истина то права имеются
Работает как и любой код в NET
ну, тот топик устарел на 4 года, все что там написано уже давно реализовано

Напрягает только тем, что самому не понять, только догадываться.
А еще вопрос можно?
Код запускается на приложении или на сервере БД?
Как выглядит и выполняется код проверки доступности для выборки множества записей, как это влияет на скорость выборки? Тот же пример, выдавать пользователю накладные только конкретного цеха.


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

Возвращаясь к первому сообщению

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

В SCSM второй уровень возможно не обязателен, задачу распределить заявок между цехами можно решать через каталоги с наследованием прав доступа, как это предлагал Petro123.

А вот для SAP и 1С многоуровневый доступ вполне актуален, так как есть потребность агрегировать документы, распределенные между цехами для расчета оборотов, остатков, отклонений в разрезе различных аналитических признаков. Не даром 1С добавила RLS в свои метаданные. Но только кто им пользуется? Слишком сложные выражение вставлять надо....