ViPRosМСУ, последнее очень точно подмечено, потому все с этого и начинается
Не согласен. Задача тимлида или руководителя девелоперов как раз-таки организовать правильно процесс, чтобы такого не было. Достигается элементарно - разграничение ответственности в разрезе задач (а не всего приложения(-ний)). Задача не выполнена.

ViPRosконей на переправе не меняют, больше овса!!! кони устали и мчутся хз куды а им овса жалко блин
Согласен, ибо поздно уже. Посему, наслаждайтесь "процессом" и не ворчите, что "у нас всё так плохо".

ViPRosМСУ, как спеца по безопасника советы нужны куда эту фигню развивать?
Правила есть - это уже гуд.
Как сделано у меня тут: Membership Administrator
Добавьте возможность множественности (plural relations). То есть, [блок-1] {может использовать} [блок-2], [блок-3], ..., [блок-n]. [блок] - это пользователь, роль или правило.

Добавить возможность динамик кода (dynamic blocks of code C#). То есть в момент вызова Can{x} можно выполнить определенный код (хранится в БД).



P.S. А, вообще, оффтоп уже конкретный пошел.

ViPRosда каой наифг офтоп
Оставляю Вас один на один с Вождём для урегулирования данного вопроса.

ViPRos
Надеюсь, описывать плюсы "plural relations" безопасности Вам не нужно.

P.S. Иногда в задаче часто можно встретить такую политику:

юзер 1 может редактировать документы юзера 2 и юзера 3

"может редактировать документы" - это правило ( в частном случае , можно использовать и роль )
"юзер 1", "юзер 2", "юзер 3" - прльзователи

Многие программисты, встречая такую задачу, стараются слать в топку такие требования, ссылаясь на то, что современные готовые ролевые политики не обладают таким функционалом ("правила", наследования правил или ролей, групп, plural relations и иже). Но задача остаётся ею быть.

Можно и так задать:

юзер 1 и юзер 2 может редактировать документы юзера 3 и юзера 4

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

Опишу плюсы динамической имплементации (dynamic blocks of code C#). Скажу честно, идею украл из рекламированную Севой системы NetSqlAzMan.

Например, рассмотрим правило CanEditDocuments (может редактировать документы).

Что имеем:

(1) Вызов CanEditDocument

(1.5) dynamic blocks of code

(2) Получение результата (true/false)

Суть динамической имплементации (dynamic blocks of code C#) - выполняться между первым и вторым пунктом. То есть, выполниться после пункта 1 и повлиять на пункт 2.

В простом понимании можно описать следующий алгоритм:


Пример - в галерее .

По умолчанию - "DynamicCodeResult" возвращает true. Но есть возможность проверить какое-то условие и повлиять на резултат. В результате имеем еще более гибкую конфигурацию политики.

Например, не трудно составить такое правило:

разрешать пользователю редактировать доументы, если возраст пользователя > 30 лет и email пользователя начинается на "superuser" :)

Результатом будет создание правила "CanEditDocument" и соответствующей правкой в "dynamic blocks of code" этого правила.

Есть возможность отключить вообще "dynamic blocks of code" в приложении (в случае ненужности) для того, чтобы не выполнять лишнее условие через reflection.

+ ко всему, желательно ввести понятие "Группа", чтобы можно было манипулировать безопасностью через группы. Ведь удобно выделить ряд пользователей в группу и накинуть на группу парвило(-а) или роль(-и). Все участники группы автоматически получат эту привелегию. Так же, реализовать наследование прав (если имеется иерархия групп). Так же дать возможность в группы класть не только пользоватлей, а роли и правила. Вот это будет уже вкусно. Можете посмотреть, как это у меня сделано ))

Так что, Сахават, работать еще много над расширением безопасности :)

iMCУ, у тебя неправильный справочник. Это делегирование прав. Многие программисты, которые про это знают, используют уже готовые велосипеды
Сева, Вы оперируете не теми терминами - делегирование прав - это просто (абстрактоно) раздача полномочий. У меня же - именно множестенные отношения.

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

Сева, если что, - из энциклопедия менеджмента: Делегирование прав и ответственности подчиненным

Предлагаю не вступать в полемику: плюс системы в том, что она является враппером над готовоым майкрософтским мембершипом, который используют очень многие .NET разработчики (особенно, что касается ASP.NET). Плюс, система работает и с AD. То есть, переход от обычного мембершипа к расширенному мембершипу - плавный и безболезненный.

Самое главное правило, которое я сформулировал - не должен сломаться работающий код.

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

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

Большой минус NetSqlAzMan - нужно иметь свою таблицу юзверей, нужно писать (для веба) левые педальные роле провайдеры, профиль-провайдеры, юзер-провайдеры и т.д. То есть, возможность безболезненного и быстрого перехода с родного популярного мембершипа - нет в принципе. Нету наследования групп. Нету plural relations как класс.

iСотрудник готовит документ, согласовывает его с другими, начальник отдела утверждает, директор подписывает. У каждого свои должностные обязанности без всякого наследования(босс не будет сидеть за печатной машинкой и телефоном).
Если директора нет, то он передает(делегирует) эту возможность вполне конкретному лицу/лицам
Это уже процесс , а не политики безопасности. Решается легко с помощью WWF или своими средствами, кои никак не коррелируют с администрированием , о котором я вещаю :)

iТы правильно подчеркнул, то что ты вещаешь, действительно,
МСУ никак не коррелируют с администрированием :)
Еще раз. Имеем:
1. Секьюрити, описанный мной.
2. Воркфлоу, описанный тобой.

Внимание вопрос: кто "не правильно" вещает. Просьба подумать, прежде чем отвечать.

iК чему относятся: имеет право "подписывать документ","согласовывать документ", "опубликовывать документ"?
К секьюрити, конечно.

iА Workflow - последовательность, в которой могут выполнятся эти действия. На нее могут накладываться правила разграничений прав доступа.
Могут. А к чему тогда в начале вот это сказал:

iЭто делегирование прав. Многие программисты, которые про это знают, используют уже готовые велосипеды

?

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

Если отталиваться от твоего изначального потал, то делегирование - абстрактное понятие в рамках обсуждения темы. Любой пук админа в разере секьюрити - это делегирование. Тогда непонятно, зачем ты стал акцентировавть внимание на этом делегировании, когда я начал рассказывать о "plural relations". Ясен пень, что всё это делегирование.

iMCУ, велосипеды были способны на все это задолго до того, как ты передрал частично функционал у них.
Ну давай на пальцах:
Наследования привилегий - нету

Множественного отношения - нету

Костыль в БД у них - есть (у меня же юзается родная мембершип БД, которая развертывается готовым инсталлятором от MS)

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

У меня - миграция на расширенную безопасность - пнул дистриб, он сам расширил существующий мембершип. Всё. Программист получил расширенную безопасность + ASP.NET сайт админка в подарок.

iА в их документации нет русского понимания общепринятых и всем понятных терминов
Эти термины в той или иной степени сводятся к одному - к задаче, которую нужно выполнить. Не важно как ты называешь алычу - алычёй или сливой, абрикос - абрикосом или жердёлой. Факт только один - нужно сделать так, чтобы работало должным образом. И не важно, где это будет работать - в Шанхае, Страссбурге или Удмутрии, - оно должно работать.

+ в подарок девелопер получает

"Health Monitoring module" (логи, кстати тоже родные, с удобным ридером + командами, вшитыми в объектную модель мембершип-расширения)

Пакет отчетов для мониторинга секьрити компании (естессно, всё расширяется по надобности)

+ система адаптирована и оттестирована под работу с большими массивами данных, собсно всё это в 1.8 версии

P.S. Плюс даётся урезанная редакция безопасности: Membership Administrator Standard Edition , без всех вкусностей полной редакции.

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