Здравствуйте, Aikin, Вы писали:

A>>Есть цикл сообщений в блоге Ayende на эту тему: Rhino Security
A>Странно, но исходное сообщение (которое дало старт проекту Rhino Security) не "затегено": A vision of enterprise platform: Security Infrastructure

Мммм поаккуратней со статьёй — там в схеме данных практически все ошибки о которых я предупреждал. Внимательно читайте схему — она крайне криво отрисована...

Здравствуйте, Sinix, Вы писали:

A>>>Есть цикл сообщений в блоге Ayende на эту тему: Rhino Security
A>>Странно, но исходное сообщение (которое дало старт проекту Rhino Security) не "затегено": A vision of enterprise platform: Security Infrastructure

S>Мммм поаккуратней со статьёй — там в схеме данных практически все ошибки о которых я предупреждал. Внимательно читайте схему — она крайне криво отрисована...
А можно их все же перечислить? Т.е. развернуть ответ?

В понедельник полно отвечу.
Сейчас:
1) сущности человек и пользователь объединены в 1
2) грабли с общим ID у пользователя/группы -его нет
3) уже не помню
4) все разрешения — в 1-й куче.

Здравствуйте, Aikin.
A>А можно их все же перечислить? Т.е. развернуть ответ?

Как и обещал — расписываю. Чтобы не лазить по всем постам про систему безопасности, распишу только косяки со схемой данных (о ней мы больше всего и говорили).

1) Общие косяки. Понятно, что ничего в продакшн не уйдёт и относиться надо снисходительно. Тем не менее:
1.1) Схема отвратительнейше нарисована. Дело даже не в том, что её тяжело читать. Дело в том, что из неё очень тяжко вытащить информацию которую она должна отражать. Найдите-ка связь между разрешениями и группами. Правда очевидно?
1.2) Косяки с именованием. Может товарищ и мегагуру, но большого опыта работы с базами у него явно нет. Потому что только садомазохист может называть поля с FK на табличку Groups вот так: Group, ParentGroup и OnGroup. Одновременно Есть ещё мелкие замечания по именованию остальных полей, ну да фиг с ними.
1.3) Навеки останется неизвестным, зачем товарищ убрал FK constraint между Permissions и EntitySecurityKeys. Если так надо — пусть хоть коммент на схеме оставит...
1.4) Ни одного естественного ключа. Я молчу об UQ на UsersGroups (название таблички явно тщательно выбиралось).

Summary: товарищ — асс в проектировании.

2) Пользователи и группы.
2.1) Группы вообще-то предназначены для одновременного назначения разрешений нескольким пользователям. И происходить это должно прозрачно для остальной части системы. Иначе, когда у нас появится новый тип принципалов (допустим, системные пользователи), придётся переделывать все остальные части системы. Я уже предлагал как это сделать — завести сквозной ID для пользователей и групп.
2.2) Очень любопытно посмотреть, как товарищ реализует дерево групп (а он это явно задумал, раз уж есть поле ParentGroup) с _NOT NULL_ ParentGroup.
2.3) Пользователи обычно используются для трёх вещей: представляют ID для разруливания разрешений, ассоциируют системного пользователя с некоторым реальным человеком и хранят инфу, необходимую для авторизации. С авторизацией всё по ходу мегаклассно — её просто нет. С информацией о реальном человеке ещё круче — одно поле. Зато текстовое и с запасом. Насчёт ID я уже говорил выше.

Summary: я не волшебник, я только учусь.

3) Разрешения. Вот здесь начинается помойка.
3.1) Самая грубейшая ошибка — все разрешения — в одной куче. Не, для примитивных систем это хорошо, но в реальной системе разрешения на документы и выписку накладной на шнурки надо как-то разделять
3.2) Зачем-то введены EntityGroup (он их для наследования разрешений что ли использует???)
3.3) Раз уж EntityGroup есть — как описываются разрешения на Entity Type и Specific Entity?
3.4) Что есть Type??? Учитывая специфический стиль именования — всё что угодно, начиная с типа разрешения (хотя выше уже есть allow) и заканчивая тем самым разрешением на Entity Type. Правда непонятно почему тогда поле так названо.
3.5) Совершенно крышесносящий способ назначать разрешения: на каждый тип сущностей — своё поле. При этом параллельно живут EntitySecurityKeys.

Summary: это были неправильные пчёлы.

4) Операции. Здесь мне уже страшно.
4.1) Почему Name такой же длины что и comment?
4.2) Что такое Type?
4.3) Раз уж у нас есть ParentOpertion — где FK??? Кстати, в отличие от групп, ParentOperation может содержать NULL. Гениально.
4.4) Зачем comment может содержать NULL? Пустой строки недостаточно чтобы выразить всю тоску по поводу отсутствия коммента?
4.5) Абсолютно непонятно зачем в одну кучу сваливать все возможные операции, а так же для чего они используются вообще? Для журнала? ТОгда зачем они связаны с Permission? Или это как раз элементарные действия, на которые навешиваются разрешения? А не загнёцца ли товарищ выставлять отдельно разрешения на каждое необходимое действие?

Summary: дайте мне лопату.

В сумме — если не придираться к мелочам — великолепный сборник антипаттернов. Дальнейшие статьи товарища комментировать не хочется.

P.S. Я кажется наврал — для авторизации есть accounts. Правда, почему они не связаны с пользователями —

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Aikin.
A>>А можно их все же перечислить? Т.е. развернуть ответ?

S>Как и обещал — расписываю. Чтобы не лазить по всем постам про систему безопасности, распишу только косяки со схемой данных (о ней мы больше всего и говорили).

S>1) Общие косяки. Понятно, что ничего в продакшн не уйдёт и относиться надо снисходительно. Тем не менее:
S>1.1) Схема отвратительнейше нарисована. Дело даже не в том, что её тяжело читать. Дело в том, что из неё очень тяжко вытащить информацию которую она должна отражать. Найдите-ка связь между разрешениями и группами. Правда очевидно?

Прямая связь, без доптаблиц. В чем проблема?

S>1.2) Косяки с именованием. Может товарищ и мегагуру, но большого опыта работы с базами у него явно нет. Потому что только садомазохист может называть поля с FK на табличку Groups вот так: Group, ParentGroup и OnGroup. Одновременно Есть ещё мелкие замечания по именованию остальных полей, ну да фиг с ними.

Просто стиль именования отличный от твоего, впрочем как и от моего.

S>1.3) Навеки останется неизвестным, зачем товарищ убрал FK constraint между Permissions и EntitySecurityKeys. Если так надо — пусть хоть коммент на схеме оставит...

Блог явно накидывался по только что созданой схеме, отсюда мелкие косяки (видно, что Accounts и EntitySecurityKeys не сохранены). Это vision, а не законченное решение.

S>1.4) Ни одного естественного ключа. Я молчу об UQ на UsersGroups (название таблички явно тщательно выбиралось).

Возможно он просто убежденный противник естественных ключей, это не преступление.

S>2) Пользователи и группы.
S>2.1) Группы вообще-то предназначены для одновременного назначения разрешений нескольким пользователям. И происходить это должно прозрачно для остальной части системы. Иначе, когда у нас появится новый тип принципалов (допустим, системные пользователи), придётся переделывать все остальные части системы. Я уже предлагал как это сделать — завести сквозной ID для пользователей и групп.

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

S>2.2) Очень любопытно посмотреть, как товарищ реализует дерево групп (а он это явно задумал, раз уж есть поле ParentGroup) с _NOT NULL_ ParentGroup.

Да, это явно невнимательность, для vision простительно.

S>2.3) Пользователи обычно используются для трёх вещей: представляют ID для разруливания разрешений, ассоциируют системного пользователя с некоторым реальным человеком и хранят инфу, необходимую для авторизации. С авторизацией всё по ходу мегаклассно — её просто нет. С информацией о реальном человеке ещё круче — одно поле. Зато текстовое и с запасом. Насчёт ID я уже говорил выше.

1. Ты путаешь авторизацию и аутентификацию, это серия постов именно по авторизации, аутентификация тут никаким боком.
2. Привязка пользователя к реальному человеку это часть бизнес логики, нет никакого смысла приплетать ее в этом посте.

S>3) Разрешения. Вот здесь начинается помойка.
S>3.1) Самая грубейшая ошибка — все разрешения — в одной куче. Не, для примитивных систем это хорошо, но в реальной системе разрешения на документы и выписку накладной на шнурки надо как-то разделять

Что мешает их разделять?

S>3.2) Зачем-то введены EntityGroup (он их для наследования разрешений что ли использует???)

In addition to all of that, we also have the concept of an EntityGroup to consider. Permissions can be granted and revoked on an Entity Group, and those are applicable to all the entities that are member in this group. This way, business logic that touches permissions doesn't need to be scattered all over the place, when a state change affects the permissions on an entity, it is added or removed to an entity group, which has a well known operations defined on it.

S>3.3) Раз уж EntityGroup есть — как описываются разрешения на Entity Type и Specific Entity?



S>3.4) Что есть Type??? Учитывая специфический стиль именования — всё что угодно, начиная с типа разрешения (хотя выше уже есть allow) и заканчивая тем самым разрешением на Entity Type. Правда непонятно почему тогда поле так названо.

Тип разрешения очевидно.

S>3.5) Совершенно крышесносящий способ назначать разрешения: на каждый тип сущностей — своё поле. При этом параллельно живут EntitySecurityKeys.

Не увидел вообще ни одного поля завязанного на конкретный тип бизнес сущности.

S>4) Операции. Здесь мне уже страшно.
S>4.1) Почему Name такой же длины что и comment?

Такие вещи тебя серьезно пугают?

S>4.2) Что такое Type?

Тип операции? Возможно это объясняется где-то позже, без этого знания вполне можно понять мысль автора.

S>4.3) Раз уж у нас есть ParentOpertion — где FK??? Кстати, в отличие от групп, ParentOperation может содержать NULL. Гениально.

Забыто FK, это тебя тоже очень пугает?

S>4.4) Зачем comment может содержать NULL? Пустой строки недостаточно чтобы выразить всю тоску по поводу отсутствия коммента?

А вот оракл вообще не различает NULL и пустую строку, может его заклеймить позором за это? Мелкая придирка.

S>4.5) Абсолютно непонятно зачем в одну кучу сваливать все возможные операции, а так же для чего они используются вообще? Для журнала? ТОгда зачем они связаны с Permission? Или это как раз элементарные действия, на которые навешиваются разрешения?

Как зачем? Разрешения определяют разрешена ли (запрещена ли) операция или доступ к сущности.

S>А не загнёцца ли товарищ выставлять отдельно разрешения на каждое необходимое действие?

Товарищ явно умеет автоматизировать свою деятельность, не загнется.

S>В сумме — если не придираться к мелочам — великолепный сборник антипаттернов. Дальнейшие статьи товарища комментировать не хочется.

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

S>P.S. Я кажется наврал — для авторизации есть accounts. Правда, почему они не связаны с пользователями —

Нет, аккаунты там как пример бизнес сущности. Вобщем ты просто пробежал статью по диагонали и половины не понял. Возмножно в этом виновата сама статья. Следовало обратить внимание на название (конкретно на слово vision) и "Just to note: this is not complete"

Здравствуйте, Ziaw.

О! Контркритика пошла
Чтобы не размазывать по цитатам: я рассматривал эту статью именно как пример как делать. С этой точки зрения там скорее пример как _не_ делать. Каждый мелкий косяк по отдельности не страшен конечно, но в целом оно производит впечатления сырого наброска. Ну и во многом говорит о том, насколько автор ответственно подходит к решению проблемы. Если эта статья чисто для понтов, типа "посмотрите как я могу", её вообще бессмысленно давать как пример (и облсуждать тоже). Если же это претензия на код, который в будущем уйдёт в продакшн, то автора надо срочно изолировать от написания security-sensitive кода.

Теперь по цитатам. То, что можно пообсуждать дальше, выделил жирным.

S>>1.1) Схема отвратительнейше нарисована. Дело даже не в том, что её тяжело читать. Дело в том, что из неё очень тяжко вытащить информацию которую она должна отражать. Найдите-ка связь между разрешениями и группами. Правда очевидно?
Z>Прямая связь, без доптаблиц. В чем проблема?
Дык читайте: "Схема отвратительнейше нарисована.". Я здесь говорю только о картинке-схеме. Диаграмме, если больше так нравится. Для вас сразу видно что разрешения и группы связаны? И можете даже из схемы сказать по каким столбцам?

Z>Просто стиль именования отличный от твоего, впрочем как и от моего.
Ну нелогично ведь одно и то же по смыслу поле три раза называть по-разному. Это не стиль именования а его отсутствие. Не, отдельные товарищи и tbl000123.fldstr12 как стиль понимают...

Z>Блог явно накидывался по только что созданой схеме, отсюда мелкие косяки (видно, что Accounts и EntitySecurityKeys не сохранены). Это vision, а не законченное решение.
Дык где большие красные буковки дисклаймера? Я привык что люди думают перед тем как постить картинки. А то кто-нить начитается и пойдёт реализовывать свои "системы безопасности"

Z>Возможно он просто убежденный противник естественных ключей, это не преступление.
Эммм... Вы знаете, здесь два варианта. Либо мы под естественными ключами понимаем две разные вещи, либо товарищ в принципе не знает азов реляционной теории. Суррогатный ключ вводится для того, чтобы не шарить естественный ключ между сущностями. Но это вовсе не значит что естественных ключей быть не должно — вся теория нормализации и функциональные зависимости в частности работают благодаря естественным ключам. Или вы считаете что пользователь может 2 раза входить в 1 и ту же группу?

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

Понятие принципала ведь не идиоты придумывали. Системе вычисления разрешений должно быть глубоко пофиг на пользователей и группы. Ей должны быть известны только id, соответствующие текущему контексту выполнения (id, разумеется может быть несколько). Как эти id сопоставляются контексту — глубоко не её дело. Чтобы объяснить почему так должно быть надо заводить отдельный топик. Если интересует — отпишусь.
Системные пользователи — это отдельный тип принципалов. Обычно заводятся для всяких внутренних процедур обслуживания по расписанию типа бэкапа и т.п.

Z>Да, это явно невнимательность, для vision простительно.
Дык тут эту статью уже советуют как образец. А для товарища, которому доверили разработать систему безопасности enterprise-уровня такое как раз непростительно. Об уровне однозначно свидетельствует.


Z>1. Ты путаешь авторизацию и аутентификацию, это серия постов именно по авторизации, аутентификация тут никаким боком.
Ага. Описка. Стыдно.

Z>2. Привязка пользователя к реальному человеку это часть бизнес логики, нет никакого смысла приплетать ее в этом посте.
Э неее, это часть системы безопасности, ибо никакая безопасность без индивидуальной ответственности смысла не имеет. Уж поверьте как человеку, немало на этом огрёбшему

S>>3) Разрешения. Вот здесь начинается помойка.
S>>3.1) Самая грубейшая ошибка — все разрешения — в одной куче. Не, для примитивных систем это хорошо, но в реальной системе разрешения на документы и выписку накладной на шнурки надо как-то разделять

Z>Что мешает их разделять?
Ну у товарища просто заведена общая сущность разрешения. Естесвенного ключа здесь быть не может. "Разрешениями вообще" рулить особого смысла не имеет. У вас же не будет одного администратора по шнуркам и документам? Так что абстрактные разрешения особого смысла не имеют.

S>>3.2) Зачем-то введены EntityGroup (он их для наследования разрешений что ли использует???)

Z>

Z>In addition to all of that, we also have the concept of an EntityGroup to consider. Permissions can be granted and revoked on an Entity Group, and those are applicable to all the entities that are member in this group. This way, business logic that touches permissions doesn't need to be scattered all over the place, when a state change affects the permissions on an entity, it is added or removed to an entity group, which has a well known operations defined on it.

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

S>>3.4) Что есть Type??? Учитывая специфический стиль именования — всё что угодно, начиная с типа разрешения (хотя выше уже есть allow) и заканчивая тем самым разрешением на Entity Type. Правда непонятно почему тогда поле так названо.
Z>Тип разрешения очевидно.
А Allow тогда зачем??? Уличная магия в общем.

S>>3.5) Совершенно крышесносящий способ назначать разрешения: на каждый тип сущностей — своё поле. При этом параллельно живут EntitySecurityKeys.

Z>Не увидел вообще ни одного поля завязанного на конкретный тип бизнес сущности.
Не, вы меня не поняли: на группы — свой fk, на пользователей — свой... это именно следствие кривого дизайна принципалов.

S>>4.1) Почему Name такой же длины что и comment?
Z>Такие вещи тебя серьезно пугают?
Ага. Это явное отсутсвие здравого разума: сделано абы было. Чисто логически коммент — подробное описание, имя — краткое имя. Если описание по длине может совпадать с именем — в чём его смысл? Для бизнесподелок ещё пойдёт, для системы безопасности -слишком халтурно.

S>>4.2) Что такое Type?
Z>Тип операции? Возможно это объясняется где-то позже, без этого знания вполне можно понять мысль автора.
См. самую первую претензию. Диаграммы рисуются чтобы их читали, а не чтобы показать что автор мегаумный чувак.

S>>4.3) Раз уж у нас есть ParentOpertion — где FK??? Кстати, в отличие от групп, ParentOperation может содержать NULL. Гениально.
Z>Забыто FK, это тебя тоже очень пугает?
Не, меня пугает быдлоподход в разработке.

S>>4.4) Зачем comment может содержать NULL? Пустой строки недостаточно чтобы выразить всю тоску по поводу отсутствия коммента?
Z>А вот оракл вообще не различает NULL и пустую строку, может его заклеймить позором за это? Мелкая придирка.
Неа, ещё один нюанс, свидетельствующий о низкой квалификации. Имя не допускает null. Другие текстовые поля — тоже. Явное отсутсвие единого стандарта. Так что нефиг

S>>А не загнёцца ли товарищ выставлять отдельно разрешения на каждое необходимое действие?
Z>Товарищ явно умеет автоматизировать свою деятельность, не загнется.

Администрирование на уровне атомарных операций — моветон. Равно как и использование операций для описания несвязанных действий. Надо заводить что-то типа пресетов операций и назначать уже их. Почему — тоже надо расписывать в отдельном посте.

Z>Именно к мелочам я и увидел придирки. В основном к схеме базы, она тут второстепенная вещь, это vision архитектурного решения, как персистить его данные дело десятое.

ы Не, ребят. Для быдлобизнеса такая безответственность может и пойдёт. Для Security критична любая мелочь. У товарища security не только персистится, оно ещё и считается на сервере. Так что как отмазка не катит.

S>>P.S. Я кажется наврал — для авторизации есть accounts. Правда, почему они не связаны с пользователями —

Z>Нет, аккаунты там как пример бизнес сущности.
О. Т.е. товарищ вводит общего предка (EntitySecurityKey) только ради назначения разрешений????
И как же тогда у него работает связь пользователь-контекст выполнения???

Здравствуйте, Sinix, Вы писали:

S>Эммм... Вы знаете, здесь два варианта. Либо мы под естественными ключами понимаем две разные вещи, либо товарищ в принципе не знает азов реляционной теории. Суррогатный ключ вводится для того, чтобы не шарить естественный ключ между сущностями.
Продолжаю не понимать претензий к отсутствию естественных ключей. Суррогатный ключ вводится для того, чтобы не мешать реляционную структуру и бизнес-логику. Естественный ключ имеет свою семантику в бизнес-логике и нужен суррогат, чтобы при изменении бизнес-правил или объективной реальности реляционная структура не страдала. Чтобы не гадать каждый раз возможно или нет подобное изменение — "азы реляционной теории" говорят нам, что проще всегда использовать суррогат и не болеть головой по этому поводу.

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

S> Или вы считаете что пользователь может 2 раза входить в 1 и ту же группу?
Это ты про [Id, GroupId, UserId] — ? Так [GroupId, UserId] — не естественный ключ, а составной и проблема решается констрейнтом уникальности.
Ничего фатального я тут не вижу.

Здравствуйте, IB, Вы писали:
Тааак. Давайте придерживаться одной терминологии что ли. Дейта я вам щас не поцитатю, но память (и википедия) выдаёт следующее:
Естественный ключ — ключ-кандидат, что состоит исключительно из user data attributes (columns если больше нравится).
ЕК вполне может быть и составным — в чём проблема?
ЕК — самое обычное ограничение и выполняют ту же роль что и остальные ограничения: описывает предметную область.

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

Здравствуйте, Sinix, Вы писали:

S>Тааак. Давайте придерживаться одной терминологии что ли.
Нивапрос.

S>Дейта я вам щас не поцитатю, но память (и википедия) выдаёт следующее:
S>Естественный ключ — ключ-кандидат, что состоит исключительно из user data attributes (columns если больше нравится).
Ну вот, user data attributes — это что? Правильно — данные имеющие семантику в предметной области. И чтобы не нагружать их еще семантикой в контексте реляционных структур и вводят суррогаты.

S>ЕК вполне может быть и составным — в чём проблема?
Может, но в данном случае составной ключ состоит из 2х суррогатов.

S>Кстати это самая популярная ошибка: вводить суррогатный ключ, выкидывать UQ и утверждать что всё ок.
Что такое UQ?

Здравствуйте, Sinix, Вы писали:

S>Кстати это самая популярная ошибка: вводить суррогатный ключ, выкидывать UQ и утверждать что всё ок. Эквивалентное типа преобразование Претензии именно к тому, что товарищ не задал UQ на естественные ключи.
Самая ошибка (хотя не могу сказать что популярная) привязывать предметную логику к primary ключам. При развитии системы может меняться система уникальности. И как результат — большие траблы граничищие с сипукой у всей схемы. А если еще данные нужно импортить/экспортить в какие-то другие хранилища — то веревку и мыло. Поэтому правилом хорошего тона является делать суррогаты на primary key.
Дейт — конечно мужик головастый(грешен, уважаю его), однако он теоретик работающий только в парадигме реляционки(в отличие от нас). Поэтому не советую побуквенно следовать его советам.

Тэкс,ребят, а ничего что мы о разных вещах в принципе говорим, а? Мне очень интересно как из

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

можно сделать вывод, что естественные ключи должны быть primary??? Для мну это настолько бредовая идея, что я как-то даже забыл это чётко выделить. Виноват%)

Давайте уж напишу сейчас.

PK должен быть суррогатным. То что у нас есть PK, вовсе не значит что мы можем не включать информацию об остальных ключах в БД. Именно к отсутсвию UQ (ака unique constraint) и были все претензии.

Так лучше?

Здравствуйте, IB!

См мой ответ Glebz (постом выше).

На всякий коротко: если вы считаете, что я считаю, что PK должен быть естественным — я здесь ни при чём
UQ = unique constraint.

А есть ли готовые уже библиотеки, которые позволяют минимальными усилиями добавить такой или подобный функционал в уже готовое приложение? двухзвенное? энзвенное?

Здравствуйте, _k_, Вы писали:

_k_>А есть ли готовые уже библиотеки, которые позволяют минимальными усилиями добавить такой или подобный функционал в уже готовое приложение? двухзвенное? энзвенное?

А попробуйте погуглить компонент TDeveloper, и интероп врапперы к dev/head, dev/hands.

Если не стебаться, то система безопасности — это настолько интимная тема, что пускать туда абы кого ну совершенно не следует. Последствия в принципе по аналогии можно вывести

Здравствуйте, Sinix, Вы писали:

S>А попробуйте погуглить компонент TDeveloper, и интероп врапперы к dev/head, dev/hands.
А точно не кривые нагуглить можно? Мне бы ещё время нагуглить да побольше

S>Если не стебаться, то система безопасности — это настолько интимная тема, что пускать туда абы кого ну совершенно не следует. Последствия в принципе по аналогии можно вывести
Ну, например, есть промышленные решения для защиты от тиражирования.
У форумных движком и CMS системы безопасности вполне даже открытые -- можно выдрать и скопировать.
Можно же сделать готовое решение для "внутреннего" ПО хотя бы, никто никогда его взламывать не будет и исходники анализировать, а разделение пользователей, прав доступа и ролей требуется. Задача то хорошо ведь формализуется.

_k_>Можно же сделать готовое решение для "внутреннего" ПО хотя бы, никто никогда его взламывать не будет и исходники анализировать, а разделение пользователей, прав доступа и ролей требуется. Задача то хорошо ведь формализуется.

Улыбнуло. Огрёбся немало с "хорошо ведь формализуется". Причём и как кодер, и как админ, и как саппорт. Спасибо, не надо

Свою точку зрения где-то в начале топика расписывал.

Ваша позиция понятна... То есть "коробчатых" решений не видели?

Здравствуйте, _k_, Вы писали:

_k_>Ваша позиция понятна... То есть "коробчатых" решений не видели?

Ну как вам сказать-то
Вот AD — коробчатое решение? Или безопасность в SQL Server'e? Или шарпойнт? Или (не к ночи будь помянут) 1С?
А я могу ещё кучу страшных буковок повспоминать

Так что примерно представляю когда удобней будет rbac, а когда acl (или вы претендуете на изобретение более оригинальных концепций? ).

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

Отдельные детали конструктора есть. Остальное — ваши проблемы

Здравствуйте, _k_, Вы писали:

_k_>А есть ли готовые уже библиотеки, которые позволяют минимальными усилиями добавить такой или подобный функционал в уже готовое приложение? двухзвенное? энзвенное?
Net Framework. Особенно если в качестве сервера присутсвует ASP.NET.

Здравствуйте, _k_, Вы писали:

_k_>А есть ли готовые уже библиотеки, которые позволяют минимальными усилиями добавить такой или подобный функционал в уже готовое приложение? двухзвенное? энзвенное?

Мы используем Spring Security. Но, естественно, конкретная релизация лежит на нас. Из либы, если не ошибаюсь, берем только самые общие вещи: Principal, интерфейс аутентификации, контекст безопасности.