ViPRosах вот оно что :)
те галочки относятся к конкретным элементам (кнопкам и т.д.) - надо создавать данный функционал и кнопку или нет (например кнопку "групповое удаление записей")
или к режимам - вообще можно ли редактировать челу что нить
а вот все остальное в скрипте

Всё равно жестянство какое-то. Я бы постеснялся такое отдать на продакшен, и мне было бы страшно писать мануал к этому. ABAC полностью решает проблему перегруженности интерфейса управления доступом, в том числе к рисованию бесчисленного количества кнопок. Если на каждый чих добавлять разрешение, галочку, это можно рехнуться однажды.

ViPRosНеужели ты думаешь что написать nnое количество правил легче чем ткнуть на галочку - Да, Нет?
Правила надо писать тогда, когда невозможно обойтись - Да, Нет.

А что бы не ткать каждый раз - есть дефолты, есть клонирование и т.д.

Я думаю, что написать нужное и определённое количество правил гораздо легче и это проще, чем найти среди сотни тысяч галочек, разбросанных неизвестно как и где, чтобы тыкнуть нужную. И ответить на вопрос: а что вообще можно этому пользователю, а что нельзя в целом по всей системе? И тут же это поправить.

Про дефолты и клонирование «чтобы не тыкать каждый раз», это не более чем костыли, на мой взгляд.

ViPRosА ты вооще то покажи - как у тебя такие вещи сделаны и сравним.
Лучшее познается в сравнении.

Описывается обычным DSL, который переводится на русский вполне прозрачно:

Политика: Правила для менеджеров

1. Пользователями группы «Менеджеры»:
1.1. для группы объектов «Объекты доступные менеджерам»:
1.1.1. доступны операции «Все»
1.1.2. не доступна операция «Просмотр истории»

и т.д.

Сложность состоит в полноценной реализации модуля ABAC для имеющейся схемы данных и бизнес-логики, это действительно вызов для разработчика

В текущем проекте у нас ещё в реализации, и даже в недоработанном виде он устраивает всех более чем.

ViPRosХвост, ты кажись даже не думаешь что вообще то критикуешь?

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

ViPRos"Группа объектов", "операция" , "все", "доступно".... - все это семантические единицы как то ведь должны быть доступны :) контексту менеджера правил? Ты представляешь что это за монстр?

Почему монстр? Всё описывается в едином месте. Ты заходишь и описываешь правило доступа. Не надо никуда лазить. Хочешь посмотреть, что может конкретный пользователь, нажимаешь кнопульку и тебе согласно текущим политикам вычисляются абсолютно ВСЕ доступные возможности для пользователя: что он может, что не может, какая кнопка ему показывается, а какая нет в рамках всей системы в целом, без исключений.

Ты в своей системе можешь ответить на такой вопрос? Или надо собрать и агрегировать безопасность, раскиданную в виде ошмётков и галочек по всей системе? А это точно всё работает? А ты уверен? Всё-всё? С точки зрения доказательной базы, тебе тут поможет разве что 100% покрытие тестами, да и то не обязательно, что этого хватит.

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


ViPRosТы, блин, хоть немного подумай.
Прежде чем реализовать это (как не странно ABAC) я забраковал много фигни типа Drool и т.д.

А почему забраковал ABAC?


ViPRosА если учитывать, что в ВИПРОС нет ничего, кроме метаданных и интерпретатора и данных, то я должен был бы написать целый язык для такого ABAC. Я поступил иначе - встроил C#.

Мы используем Lua, не надо писать новый язык, определи термины DSL и используй хоть брейнфак. При чём правило безопасности может быть сколько угодно сложным, а учитывая странности и сложности каждой отдельной предметки, мне нафик не упёрлось программировать каждый отдельный случай упоротой фантазии любого из задействованных в иерархии разработки лиц.

Можно было, кстати, и C# использовать, сегодня это вообще не проблема. Но Lua проще для интеграторов, не хотим ещё обучать их сишарпам.


ViPRosА ты не стесняйся - покажи недоработанную. Посмеемся вместе.

Ничего показывать не буду, политика компании, ни кусков кода, ни скриншотов, мы не делаем публичных приложений, по крайне мере пока. Но я планирую запилить модуль ABAC в open source, по результатам текущих исследований. Это разрешено.

ViPRosА если учитывать, что в ВИПРОС нет ничего, кроме метаданных и интерпретатора и данных

Собственно текущая разработка у нас именно такая :)

Все бизнес-сущности описываются мета-данными, в SQL хранится только история (операции UPDATE/DELETE отсутствуют напрочь, только SELECT/INSERT). Агрегированные данные в чистом виде в MongoDB, в виде документов (предметка). Бизнес описывается на уровне конечного приложения в виде сервисов, модулей и Lua-скриптов, для которых предусмотрена версионность.

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

ViPRosТы опять не понимаешь.
Вот есть какая та коллекция (ну например тот же список недвижимости).
Иванов (в роли какого то козла) может видеть все объекты, в редактировать может только объекты находящиеся в Владимирской области (а то и только те, у которого площадь меньше 40 кв. м.)

И это отлично описывается политикой. Роли здесь вообще не нужны, если только это не нужно чисто для бизнеса. При чём правило может быть ещё более сложным. Например, Иваном может редактировать объекты в определённой области с определённой площадью и только на период, когда он замещает начальника, но только в високосный год, и только если он сам в своей должности не менее месяца.

Любое правило.


ViPRosЧто бы это в Lua описать, надо что бы Lua знала все коллекции, все типы ссылок в этой коллекции (так как там нет слов "Владимирская обл" - стоит GUID), самого Иванова, и т.д.
Или все это фуфло кому то надо было все время передавать в контекст Lua (так как она нифига не знает), ты представляешь тормоза?

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

ViPRosТы понимаешь что указанный мной механизм не только на жамкание кнопочек рассчитан, а и на любой код в любом прикладном методе?
Прогер НЕ вычисляет права, не просит разрешения для Иванова - ВИПРОС без него все это делает.

Управлять этим -- ад. Доступ на объекты, через его тип отстой. Есть например, 100 справочников, доступ на которые нужно управлять группой. Предлагаешь заходить, отфильтровывать эти 100 штук и прожмакивать галочки по 100 раз на каждое разрешение? Или какой-то кривой костыль, типа скопировать права и вставить на выбранные объекты?

ViPRoshVosttСобственно текущая разработка у нас именно такая :)

Купите ВИПРОС. Там все уже сделано.

То, что там сделано, никому не нужно. В 60% случаев нужна система с полноценным веб-клиентом, в 40% случаев нужно веб + мобильные приложения. В 0% процентов случаев нужен десктоп-клиент.

ViPRosкакие блин прокси объекты? кто их писать будет? админ по безопасности?
а тормоза у вас будут просто ужасными, если конечно ты не просто ляля на эту тему

Прокси-объекты пишутся один раз. У нас также есть мета-типы, получаешь объекты мета-тип по его имени, интерфейс одинаков. У него есть характеристики. Пожалуйста, у каждого типа свой набор характеристик. В чём проблема-то? С чего быть тормозам?

ViPRos,

Ты можешь вывести все правила для одного юзера человеческим русским языком? Нажал кнопку и увидел, что пользователь вообще может? И почему он может? Провести полную трассировку безопасности? Выполнить набор тестов по доступу, без лазания и тыкания мышкой, чтобы удостовериться, что так оно и есть? Если в обслуживаемой вами организации отсутствует как класс аудит безопасности, то вам очень и очень крупно повезло получается.

ViPRosПроблема у того, кто минуя свою ж систему безопасности имеет доступ ко всему что бы передать все это какому то Lua :)

Ты очень странно рассуждаешь. На кой что-то там передавать? Передаётся интерфейс, который разыменовывает ссылки, никакие объекты реально не передаются. Формируются проверки и условия, никакие данные и никуда вытащить нельзя при этом.


ViPRosи заметь, надо что бы этот сраный луа все эти вещи понимал - то бишь работал так же как и основной язык (между прочим есть там лямбды? что нить похожее на Linq?)

Лямбд нету, и много чего нету, поэтому Lua и выбран. Сложные запросы формируются через паттерн-матчинг. Ну и другие есть приёмы, чтобы состряпать запрос. На деле запросы делаются к монге, так как там лежат агрегированные данные. Поэтому лепить SQL запросы из Lua ни к чему вообще.

ViPRosмогу все это вывести на русском (правда это не сделано), но это будет книга, если включить дефолтные настройки :)

А ответить, почему сможешь? На основе чего пользователю можно то или другое?

Мы отвечаем, вот такая-то конкретная политика, сделанная Васей Пупкиным 18 ноября, разрешает Иванову вот это и вот это. Некоторые политики в комментарии содержат информацию на основе чего это разрешение было выдано, а также срок и условия действия политики. И так как по умолчанию ничего нельзя, т.е. всё запрещено кроме того, что явно не разрешено, книги не будет.

Ну и ролей нет как класса. Вообще. Никаких ролей. Пользователи, группы пользователей и политики.

ViPRosчто нить похожее на Linq?)

LINQ классный, но лямбды, LINQ, замыкания... лучше оградить их от интеграторов, которые будут писать бизнес-логику. Нафик-нафик. Чем проще язык, тем лучше. Мы рассматривали VB.NET, но надо было ещё проще.