Недавно занялся изучением ASP.NET столкнулся с тем что не хватает функционала стандартного api MemberShip/Roles.
Самое насущное — это отсутствие групп пользователей. Можете ли посоветовать материалы или просто дать советы по проектированию/реализации собственных система, а в идеале доработке/расширению существующей. Увы пока ничего толкового не нашел.
Здравствуйте, Axis, Вы писали:
A>Недавно занялся изучением ASP.NET столкнулся с тем что не хватает функционала стандартного api MemberShip/Roles. A>Самое насущное — это отсутствие групп пользователей. Можете ли посоветовать материалы или просто дать советы по проектированию/реализации собственных система, а в идеале доработке/расширению существующей. Увы пока ничего толкового не нашел.
Ролевой доступ в ASP.NET реализован в полной мере. Посмотрите документы:
Не хватает именно объединения пользователей в группы. Либо я не до конца представляю способы использования данных механизмов.
Попробую описать поподробнее:
Необходимо пользователей определять в группы например : Админы, Менеджеры, Логистики, Работяги.
Необходимо раздавать права на какие либо объекты например : топики/разделы форума, страницы, прочие объекты.
В принципе это можно реализовать расширением стандартных механизмов, но тут проблема в том что я только начал изучать asp.net и у меня проблема с реализацией (раньше сидел на Delphi и Fox Pro опыт около 10 лет.)
Поэтому идеально было бы найти какой нибудь пример, открытый проект с пояснениями. ( не судите строго за такую наглость)
A>Не хватает именно объединения пользователей в группы. Либо я не до конца представляю способы использования данных механизмов. A>Попробую описать поподробнее: A> Необходимо пользователей определять в группы например : Админы, Менеджеры, Логистики, Работяги. A> Необходимо раздавать права на какие либо объекты например : топики/разделы форума, страницы, прочие объекты.
A>В принципе это можно реализовать расширением стандартных механизмов, но тут проблема в том что я только начал изучать asp.net и у меня проблема с реализацией (раньше сидел на Delphi и Fox Pro опыт около 10 лет.) A>Поэтому идеально было бы найти какой нибудь пример, открытый проект с пояснениями. ( не судите строго за такую наглость)
Не смотрите на названия — старайтесь понять суть вещей Роль — это некий флаг, разрешающий или запрещающий некую(-ие) операцию(-и). С другой стороны, совокупность всех пользователей с некой ролью можно рассматривать как группу пользователей, имеющих разрешение на что-либо.
Здравствуйте, koandrew, Вы писали:
K>Не смотрите на названия — старайтесь понять суть вещей Роль — это некий флаг, разрешающий или запрещающий некую(-ие) операцию(-и). С другой стороны, совокупность всех пользователей с некой ролью можно рассматривать как группу пользователей, имеющих разрешение на что-либо.
Вы правы, но тогда есть необходимость реализовать свою базу разрешений на определённые объекты, и реализовать класс проверки доступности этих объектов для групп.
.
A>Не хватает именно объединения пользователей в группы.
"Роль", в данном контексте является почти синонимом термина "Группа".
A>Поэтому идеально было бы найти какой нибудь пример, открытый проект с пояснениями. ( не судите строго за такую наглость)
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Axis, Вы писали: KV>>>Более гибкую схему, нежели ролевой доступ, буквально на днях описывал здесь
. A>>Не хватает именно объединения пользователей в группы. KV>"Роль", в данном контексте является почти синонимом термина "Группа"
Почти да не совсем, вот в чем разница есть роль "Доступ к объекту ХХХ"
Есть группа "Менеджеры" есть пользователь "Вася" в итоге
Вася входит в "Менеджеры", а "Менеджеры" имеют "Доступ к объекту ХХХ"
в итоге получается трехуровневая система "пользователь" -> "группа" -> "роль"
а стандартная система поддерживает 2 уровня "пользователь" -> "группа/роль"
Блог интересный, спасибо! Книга на очереди к прочтению, но мне кажется ничего там нового я не узнаю, со стандартным механизмом я более менее разобрался и меня интересуют именно примеры применения, а лучше его расширения.
Здравствуйте, Axis, Вы писали:
A>Почти да не совсем, вот в чем разница есть роль "Доступ к объекту ХХХ" A>Есть группа "Менеджеры" есть пользователь "Вася" в итоге A>Вася входит в "Менеджеры", а "Менеджеры" имеют "Доступ к объекту ХХХ" A>в итоге получается трехуровневая система "пользователь" -> "группа" -> "роль" A>а стандартная система поддерживает 2 уровня "пользователь" -> "группа/роль"
Ну так бы сразу и сказали
Имеет место путаница в терминах. Та схема, которая вам нужна (если я правильно понял) выглядит так: "пользователь -> роль -> именованные списки разрешений" и из коробки в ASP.NET не поддерживается. Этого можно добиться либо нашаманив с azman (http://msdn.microsoft.com/en-us/library/ms998336.aspx — я давал эту ссылку выше, он умеет работать с группами списков разрешений, но также имеет ряд недостатков), либо реализовав необходимый функционал руками, например так:
Роли используете по назначению, т.е. "Employee", "Manager" и т.п.
1. Заводите таблицу разрешений (типа "ReadDocument", "WriteDocument", "EditDocument" и т.п.)
2. Заводите таблицу роли-разрешения
3. Реализуете собственный IPrincipal и в добавок к его членам реализуете метод HasPermission получающий имя разрешения и возвращающий истину, если одна из ролей текущего пользователя имеет это разрешение.
и далее используете в коде вместо IsInRole свой HasPermission. Еще можно пойти путем автора вот этого: http://permissionmanager.codeplex.com/
A>Блог интересный, спасибо! Книга на очереди к прочтению, но мне кажется ничего там нового я не узнаю, со стандартным механизмом я более менее разобрался и меня интересуют именно примеры применения, а лучше его расширения.
Там не только и не столько про контроль доступа, сколько про обеспечение безопасности ASP.NET приложений в целом.
Здравствуйте, Axis, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Здравствуйте, Axis, Вы писали: KV>>>>Более гибкую схему, нежели ролевой доступ, буквально на днях описывал здесь
. A>>>Не хватает именно объединения пользователей в группы. KV>>"Роль", в данном контексте является почти синонимом термина "Группа"
A>Почти да не совсем, вот в чем разница есть роль "Доступ к объекту ХХХ" A>Есть группа "Менеджеры" есть пользователь "Вася" в итоге A>Вася входит в "Менеджеры", а "Менеджеры" имеют "Доступ к объекту ХХХ" A>в итоге получается трехуровневая система "пользователь" -> "группа" -> "роль" A>а стандартная система поддерживает 2 уровня "пользователь" -> "группа/роль"
"Доступ к объекту ХХХ" — это не роль, а permisiion.
Про виды разграничения прав:
1)Классическая rbs (role-based security):
Есть Роли, Пользователи могут иметь несколько ролей, Роли имеют несколько Разрешений.
То есть между Пользователями и Ролями связь многие-ко-многим, и между Ролями и Разрешениями многие-ко-многим.
Такая модель эффективна для небольших приложений, где роли определены и зачастую совпадают с ролями в процессе, а разрешения выдаются на некоторые действия.
Фактически Роль определяет как группу пользователей, так и что они могут делать.
2)Настраиваемая RBS.
Тут роли разделяются на группы пользователей и наборы разрешений. Пользователи связаны многие-ко-многим с группами, группы — многие-ко-многим с наборами разрешений, наборы разрешений — многие-ко-многим разрешениями.
Разрешения также выдаются на некоторые действия, но при большом количестве удобнее управлять согласованными наборами разрешений, а не отдельными разрешениями. Наборы разрешений можно изменять в процессе работы программы, как и группы пользователей.
По опыту такая система сложнее классической раз в пять. Поэтому без необходимости городить не стоит.
3)Claims-based security
Почти тоже самое что и предыдущий пункт, только вместо групп пользователей используются claim_ы которые могу иметь разный тип (имеется ввиду бизнес-тип), типичные claims это имя пользователя, группы (может быть несколько), email, в бизнес-приложениях это также может быть имя менеджера, отдел итп.
Таким образом пользователи имеет много claim_ов, каждый claim определяется парой (тип, значение), набор разрешений привязывается к набору claim_ов.
А теперь самое интересное. Система разграничения прав в приложениях с CBS часто оказывается проще, чем RBS в настраиваемом вида. RBS заставляет плодить много групп, в том числе автоматически. При использовании CBS от этого можно совсем отказаться, а сам механизм получения claim_ов вынести отдельно, что уменьшит сложность самого приложения (например Windows Identity Foundation так и работает, и позволяет сделать claims-provider, работающий с AD).
Кроме того возможен fallback к RBS — достаточно один из типов claim_ов объявить группой\ролью.
Это не полный список, всегда можно придумать вариации.
Все выше касалось ограничения на выполнение функций системы, теперь если мы хотим защищать доступ к объектам в системе.
Поначалу все просто : связь роль-разрешения, группа-группа разрешений, набор claim_ов — группа разрешений становится тренарной, то есть к каждой связи добавляет атрибут — ссылка на объект. Тогда сама связь, указывающая что для данного объекта данная роль имеет указанные разрешения становится неким ACE (Access Control Entry из терминологии Windows), множество ACE, сгруппированных по ссылке на объект, называются ACL (Access Control List).
Вроде все просто, но при построении такой системы надо решить несколько принципиальных вопросов:
1)Вычисление "эффективных разрешений". При наличии иерархии защищаемых объектов надо уметь однозначно получать разрешения которые действуют для данного объекта, с учетом разрешений вышестоящих объектов. Прием если связи между объектами имеют циклы, то однозначность становится проблемой.
2)Владение объектом. Зачастую при вычислении возможности доступа нужно учитывать кто создал этот объект и как авторство объекта влияет на эффективные разрешения.
3)Как с учетом вышесказанного сделать чтобы это быстро работало. Проверка разрешений и так усложняет выборки данных, а если еще требуется вычислять эффективные разрешения с учетом иерархии, то это может очень сильно сказаться на производительности.
Поэтому часто такую систему называют Row-Level Securty, потому что проверки реализуются на уровне строк БД, иначе очень медленно будет.
Здравствуйте, Axis, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>"Доступ к объекту ХХХ" — это не роль, а permisiion.
G>>Про виды разграничения прав: A>.....
A>Спасибо за небольшой экскурс, почитал ваш блог, посмотрел на ваши сертификаты A>Хочется спросить, где и что можно почитать по интересующей меня теме?
В первую очередь хочу порекомендовать изучение WIF (Windows Identity Foundation), это большой комплекс средств для claims-based security и federation. Много документации, объясняющей не только техническую сторону вопроса, но и концепции, потребности пользователей итп.
А также стоит более детально изучить вопросы безопасности в .NET и ASP.NET, я это все банально по документации на msdn изучал + гуглил примеры.
на этом сайте. Можно посмотреть реализацию MS Repository из комплекта SQL Server Modeling Services (бывший Oslo), а также смотреть как реализовано разграничение доступа в флагманских продуктах, типа Sharepoint и Dynamics CRM (документации полно).
Роль — это некий флаг, разрешающий или запрещающий некую(-ие) операцию(-и). С другой стороны, совокупность всех пользователей с некой ролью можно рассматривать как группу пользователей, имеющих разрешение на что-либо. 
