Всем привет!

Возникла задача создания системы разграничения доступа к компонентам приложения.

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

Интересно было бы узнать, может у кого есть идеи по поводу удачной реализации подобной вещи на .NET (WinForms)?

Здравствуйте, Аноним, Вы писали:

А>Всем привет!

А>Возникла задача создания системы разграничения доступа к компонентам приложения.

А>Есть список функций, которые может выполнять пользователь, и есть список пользователей.
А>Необходимо реализовать систему, которая позволяла бы ограничить доступ пользователю к формам и отдельным функциям формы (все определяется списком доступных функций).

А>Интересно было бы узнать, может у кого есть идеи по поводу удачной реализации подобной вещи на .NET (WinForms)?

Role based security. Каждому методу, операции, кнопке наконец соотносится роль. Роли назначаются пользователям или гуппам. А дальше, если у текущего пользователя не в роли:
— в методе брость исключение,
— кнопку не рисовать,
— операцию не выполнять.

В этом духе...

Если пользователи доменные можно воспользоваться Authorization Manager-ом.

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

А>>Возникла задача создания системы разграничения доступа к компонентам приложения.

А>>Есть список функций, которые может выполнять пользователь, и есть список пользователей.
А>>Необходимо реализовать систему, которая позволяла бы ограничить доступ пользователю к формам и отдельным функциям формы (все определяется списком доступных функций).

А>>Интересно было бы узнать, может у кого есть идеи по поводу удачной реализации подобной вещи на .NET (WinForms)?

ZS>Role based security. Каждому методу, операции, кнопке наконец соотносится роль. Роли назначаются пользователям или гуппам.

Это нонятно, но возможен вариант, когда будет большое количество групп, а админы не разрешат создавать их. Как тогда быть?

ZS>А дальше, если у текущего пользователя не в роли:
ZS>- в методе брость исключение,
ZS>- кнопку не рисовать,
ZS>- операцию не выполнять.

А как не разрешать открывать форму, если она может быть вызвана из "большого" количества мест? Проверять в каждом месте вызова не рационально.

ZS>В этом духе...

ZS>Если пользователи доменные можно воспользоваться Authorization Manager-ом.

Здравствуйте, Аноним, Вы писали:

ZS>>Role based security. Каждому методу, операции, кнопке наконец соотносится роль. Роли назначаются пользователям или гуппам.

А>Это нонятно, но возможен вариант, когда будет большое количество групп, а админы не разрешат создавать их. Как тогда быть?

Authorization Manager как раз для этого)

А>А как не разрешать открывать форму, если она может быть вызвана из "большого" количества мест? Проверять в каждом месте вызова не рационально.

Не, ну я понимаю — оптимизация и т.д... Но не надо до крайностей) Ну реализуйте в классах интерфейс навроде:

interface NamedEntityAccessor
{
   bool CanAccess(string entityName); //entityName - имя метода, свойства....
}

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

А>>А как не разрешать открывать форму, если она может быть вызвана из "большого" количества мест? Проверять в каждом месте вызова не рационально.

ZS>Не, ну я понимаю — оптимизация и т.д... Но не надо до крайностей) Ну реализуйте в классах интерфейс навроде:


А вызов форм каким образом осуществлять? Можно через Factory, но тогда получится не совсем гибкое решение. Есть идеи?

class FormFactory
{
   Form OpenForm1(User, Params)
   {
      Form1 f = new Form1(Params);

      if(f.CanAccess(UserToken))
      {
         return f;
      }
      else
      {
         return null;
      }
   }
   ...
}

Здравствуйте, Аноним, Вы писали:

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

А>>>А как не разрешать открывать форму, если она может быть вызвана из "большого" количества мест? Проверять в каждом месте вызова не рационально.

ZS>>Не, ну я понимаю — оптимизация и т.д... Но не надо до крайностей) Ну реализуйте в классах интерфейс навроде:


А>А вызов форм каким образом осуществлять? Можно через Factory, но тогда получится не совсем гибкое решение. Есть идеи?

Тут наверо более подойдет комбинация Mediator + AbstractFactory. Вот Mediator то за всеми этими завязками следить и может...

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

ZS>Тут наверо более подойдет комбинация Mediator + AbstractFactory. Вот Mediator то за всеми этими завязками следить и может...

А примером не поможете?

Здравствуйте, Аноним, Вы писали:

А>Это нонятно, но возможен вариант, когда будет большое количество групп, а админы не разрешат создавать их. Как тогда быть?

тогда использовать CustomIdentity & CustomPrincipal (авторизовывать можно используя свои собственные данные из своей базы) и продолжать использовать всю ту же RoleBasedSecurity.
Проверка доступа к форме... ну например декларативной rolebasedsecurity или к примеру в конструкторе форму императивно... попробуйте.
При использовании атрибутов (declarative security checks) в случае отсутсвия прав (не та группа у вызывающего этот код пользователя) наверх будет улетать exception который надо будет ловить.
При использовании imperative security checks можете сами просто разветвить например исполнение в зависимости от группы вызывающего код пользователя.